When we release software into the world, whether it’s internal software or software that is used by the customers, it usually goes through a process called release management. I covered the reasons this is done in a recent post, but there is a process that is followed by many companies. Let’s take a look at how software releases are usually done.
Now, to clarify, I’m talking about software releases done by businesses which you would be working on when you’re out in the work force. This means:
- The software is either already live (being used), or the first iteration is about to be used
- There may be other systems that are impacted
- The software can either be internal (not customer-facing, such as an upgrade to an accounting package) or external (customer facing, such as a shopping cart enhancement)
The process for doing this varies widely between companies, but it generally follows the steps below.
1. Plan The Release
The first steps that a company usually takes is to plan for the release.
This is where they work out what should actually be done in the release, and when the software will be released. It’s important to know this up-front, so that the relevant people and teams are aware of any impact it may have to them.
When planning a release, several things are taken into consideration:
- What is going to be released – is it a small patch, a large change, a new application, or something else? Details are also needed at this point about what the change actually is.
- When will it be ready – Is there a date that the team will have the software ready by? It’s no use planning a release date for one month away if it will take three months to get ready for.
- Who is involved – different people need to be involved for a release, depending on the company. A lot of the time the senior managers need to be aware of it, and the technical teams need to know what to do.
The plan can either be done at the company level (common for smaller companies) or at a business unit or team level (which may be the case for larger companies).
2. Development of Software For The Release
Once the planning has been done, the development of the software in preparation for the release is done. This exact process would be different for each company.
This step doesn’t actually mean that they start the coding. What I’m referring to in this step is the bulk of the work done by the project development team in preparation for the release. This would involve analysis of the requirements, solution design, and development.
The time taken for this step could be anywhere from a couple of weeks up to a year, sometimes even longer, depending on the work required. However, what I’m seeing with the increase in Agile adoption in the industry, this timeframe is much shorter.
3. Testing For The Release
Now, once the development has been done, it’s time for testing. This was also outlined in the previous post, and there are usually several phases of testing:
- Unit testing – this is where individual modules of code are tested to ensure they do what they are supposed to.
- System testing – this is where the entire system is tested, to ensure it works and that it meets the requirements.
- Integration testing – this is where the system is tested on how it communicates with other systems, to make sure that it doesn’t break anything else.
4. Release Approval
Once the testing has been done, and passed (hopefully), it’s time to get the approval for release. Basically, what we’re asking now is, “Here’s the new software, it meets the requirements, we’re pretty certain it won’t break based on these tests. Can we go ahead with the release?”
The ones asking this question are the project team, specifically the project manager or the people responsible for the project. They ask the question to the senior managers or the ones who give the OK for the change to go ahead. They are often the head of the release, or an IT general manager, but this depends on the company setup.
A proposal would be put to these people, to demonstrate to them what is being released, when the planned release date is, what’s being impacted, how it’s tested and what the results where. It’s all the information they need to make a decision. Hopefully they say yes and give the approval for the release.
If not, actions would be taken to resolve the concerns they have.
5. Software Release Setup
After the approval is received, it’s time to set up the release. This involves getting people, systems and processes ready for the software release. The kinds of things that need to be prepared are:
- Responsible people – a list of who is involved in the release, with contact details. This would be the project team, those involved in the release, as well as any emergency contacts (for example, if the server crashes or the power goes out during the release).
- Release steps – a step-by-step guide of what needs to happen for the release to go ahead. This involves running scripts, transferring files, testing, running programs.
- The timeline for the release – at what point the steps are planned for, who performs them, and how long is allowed.
- Decision points – moments in the timeline where a decision is made to continue with the release process, or to stop the process and reverse the changes.
Doing these tasks ahead of time will help the release go smoothly. Everyone knows what needs to be done, and at what time, and who to call if things go wrong.
6. The Actual Software Release
Once the setup is done, and the release day arrives, it’s time to get to work!
This is where it all happens!
The teams get prepared and start doing whatever they need to do. Files are copied. Scripts are run. Code is compiled and tested. Interfaces are connected and verified. User interfaces are updated. Software is used to check that everything looks and works OK. Logs are examined. Systems are monitored. Decisions are made
Once all the required work is done, the software will be live in the system. This is still before the announcement is made to the wider community that the release is OK. We can do all the testing we want in the testing environments, but there’s one step that still remains.
7. Post Release Testing
At this point in the software release management process, the code has been deployed into the live systems. It now needs to be tested. Testing in a test environment isn’t quite the same as the live environment.
A series of tests are run at this point on the live systems, to ensure that they are OK. They aren’t as comprehensive as the unit tests run earlier. The aim of the tests are just to ensure that everything in the system works as expected, and that no other related systems are broken or overloaded.
Once this is done, the release is over!
8. Completion
The software has now been released into the company’s systems, it has been tested, and is ready for use. This is where the celebrations of months or years of hard work happen. The project has finally released what it needs to, with minimal or no issues. A few things happen now:
- Communication – a communication is sent out advising the relevant people and the wider community that the release was a success, and how it will help the business. It will usually include recognition of the project team for their hard work.
- Team celebration – a team lunch or dinner or some kind of small event is commonly held to celebrate. This depends on the size of the project and the length of the release. Releases every two weeks may not have this, but a yearly release may have a larger celebration.
- Resource allocation – once the project team has finished the release, the managers need to work out how to reallocate those who worked on the project.
The completion of the software release is a great achievement. An improvement to the company is made, experience for the team is gained, and the project delivers what it set out to.
Summary
So, in summary, this process involves:
- Planning of the release
- Development
- Testing
- Approval
- Setup
- Actual release or deployment
- Post-release testing
- Completion
Well, that about covers the software release management process. How does your company do this process? Post your comments in the section below!