Software release management is something that many companies follow. As a junior IT professional, this process can be hard to understand. Why do we need releases? What happens in a release? Learn more about this process in this article.
Releases Happen in Regular Cycles
The main idea behind software release management is that it is better to implement software in groups of related features at regular intervals, than to release each of them when they are completed. There are many reasons for this:
Less work involved
The main reason why software releases are done in cycles is because, overall, there is less work involved. There is a lot of work that is done to prepare for a release of a piece of software, and if it’s grouped with other software improvements, it removes a lot of the overhead work.
Less risk of failure
If there are regular releases of multiple items, there is usually a testing and verification step that happens. If it’s done less frequently, it’s easier to prepare for worst case scenarios and to remove any changes that have caused problems.
Quicker releases
While it might seem strange that having release management means that there are quicker releases, I think this is true. Companies can group things together and improve processes and steps to ensure software gets deployed efficiently and with minimal impact.
Easier to plan
A lot of planning goes into each release. If items are grouped together and released at the same time, then it’s easier to plan – for the upcoming release and any systems impacted or problems that may arise.
Different Environments Are Used
In your university days, or maybe on a side project you’ve been working on, you have probably developed some code and made improvements to it. When we developed the code, we most likely only had one area or environment that we worked on. Perhaps we had a second one – one area that was our “live” version, and another which was the development version. This would have been done so we don’t make any mistakes in the live version that we can’t undo. We had our own version of software release management!
The same concept is used in companies for software release management. When you develop or test code, you need access to a server, database, related application code and even other systems. It’s critical that this is done in different areas, so that the work you’re doing doesn’t impact work that other people are doing, or the live systems.
Companies set up copies of the main environment for software developers and other IT professionals to do their work in without impacting live systems. Some examples of these environments include:
- Development. This would be the area that developers work in to write and test their code. Making mistakes in here has minimal impact, as it’s usually pretty messy anyway.
- Testing. This environment is used by the test team to perform their tests on the system. Code from the development system is moved into this environment when it is stable.
- Pre-Production. This is where code goes that is tested, finished, and ready to be implemented into production. It sits here until the release is done.
- Production. This is the live environment for the system. This is the area that the customers, employees or other systems use, with live data and interactions.
Each company has its own rules and standards for software release management, so you might find that the specifics for your company might not match these, but this is the general process.
Preparation Is Key
When you need to release some software into the system, whether it is a new application, a feature, or a bug fix, it’s important to be prepared.
A lot of work goes into a release, and anything that is included in the release needs to be ready. The main reason for this is to minimize risk to the company. If you release something into the production environment with bugs or if it causes more issues, it can be a disaster to the company. This is what they try to avoid, and to avoid it, preparation is needed.
The kind of preparation involved includes:
- Information about impacted systems
- Steps to implement the change or installation
- Steps to reverse the change or installation
- What testing has been done to ensure it works
- What testing will be done to ensure it hasn’t broken anything else
This information is usually provided by the project team to the implementation team or managers, so they can assess the changes and make any decisions needed. They can also decide when the deployment happens, which can be during the day, at night, or even a weekend deployment.
Different Deadlines Exist
The planning and release of software into a company’s IT environment doesn’t just come down to one date. If I develop software in my own time, I might set myself a target date, so that when everything is ready I can release it.
However, for software release management in companies, there are different stages along the way. A change or new application needs to be ready some time before the actual release date, for several reasons:
- Resource planning. If changes or new applications are just able to be added to a release last minute, then this can cause issues for the release team. It’s good for them to know what’s being changed and what the effects are in advance, so there is a period before the release date that no new changes are accepted.
- Risk reduction. If everyone knows what is being implemented for a particular release, then work can be done to prepare other systems and teams for any impact they may have. If a new change is introduced late, it can cause this assessment to change and could cause more problems.
- Project planning. Deadlines for releases help with the project teams too – the ones that are actually developing and testing the software. They can plan the release of their software around the release cycle, and know they have to meet certain deadlines along the way.
As mentioned before, each company has their own standards that they follow, but some of the common software release management deadlines include:
- Submission. There is often a deadline for a particular release that items need to be included by. For example, there could be a deadline of four weeks before the release date that changes need to be submitted, so if the next release is on May 30th, then all changes for that release need to be submitted by May 1st,
- Internal Testing. There can also be a deadline that means all software needs to be developed and have passed internal testing by. This could be, say, two weeks before the release date. This ensures that testing isn’t happening last minute for some changes.
- Integration Testing. This is often where changes are tested against other systems also being released, and this also needs to be done before the release. It’s often closer to a release date.
If a change does not meet a certain deadline, it can be moved to a later release, depending on the company’s policy.
I hope that answers your questions on software release management. Coming up soon is a post on what the release management process is – all the way from planning to completion, and everything in between.
Do you have any other questions on software release management? Post them in the section below!