The end goal of any software development is a successful release of the ready made solution. The release is one of the most important and anticipated events in the software development lifecycle. Preparing for release can take a lot of time and effort, involving the entire team and stakeholders. So the question is – can you make a release preparation easier? We are sure that it is possible if you manage the whole process properly and cooperate with the experienced team of professionals.
Managing release helps to plan the work efficiently and, therefore, prepare for the expected result. For product users, it is a kind of quality support and guarantee of receiving further improvements. Furthermore, to prevent costly delays, sudden bugs or errors and keep your organization’s processes running smoothly, you need to invest in an efficient release management.
In this article we would like to discuss what effective release management is and where it fits into the development cycle. We will also descrive who is involved in the release process, and to what metrics your should pay attention. So, without further ado, let’s get started!
What does release management stand for?
The Release is a complex process of delivering the scope of a new product, planned changes, or a particular feature that brings value to the clients and, as a result, to the business. The overall purpose is to carry out the idea from its inception to the moment of its full implementation and release to the market. For a manager, the task is similar to a quest: to pass the necessary changes through all stages, bypassing possible pitfalls, adhering to the stated time frame and budget.
It is worth considering that release management in a broader sense may include additional activities for announcing an updated product, launching advertising campaigns, as well as training of support specialists and so on.
We have prepared a visual scheme demonstrating the main steps of software development cycle and describing the main activities that take place on each of them. As you can see it takes a lot of work to develop any solution, even the basic one, and without the right management this task gets even harder.
How the software release management cycle is organized
As it was mentioned earlier, software release management is a complex process that combines planning, implementation, testing, and deployment of software changes, as well as control of their quality during further use. Take a look at the picture below to understand the whole cycle a little bit better.
Every step of release management is crucial and it has certain so-called rules that you should follow. Without knowing them you may face numerous challenges on you way to app release. So to avoid them, let’s take a closer look at each step and actions that it requires.
Although Deployment (Release) is the final part of the software development life cycle, release management is a process that starts from the very beginning – with planning. Release planning is the process of determining the desired outcome of one or more releases and maximizing the chances of achieving it. Specific, realistic, achievable, and measurable goals are established while planning.
At this stage, the necessary efforts are being analyzed, the available resources are taken into account, as well as competencies, and time necessary for implementation. The compatibility of the required changes with the existing functionality should also be checked. The outcome of the planning will be a release plan or product roadmap with the scope of work to be done till specified delivery dates, taking into account the optimistic and pessimistic forecast, as well as possible risks and mitigation plan to address them.
The plans should be updated and disseminated regularly to create the right expectations for all stakeholders in the project. Here is how releases can be planned:
- By feature (each feature is released separately as soon as it is ready);
- By sprints (by the end of each sprint a sprint increment is planned to be released);
- By Agile release train that is used usually by several teams who work together and synchronize during all release process. Let’s take Spotify as an example. It performs releases quite often, based on the practice of release train. As the name of this practice suggests, a release is very much like a train: those who haven’t finished their work are waiting for the next release. The advantages of this approach are that a team that is not doing well does not delay the delivery of the product and does not try to push unfinished tasks.
Usually, it depends on the project (its particular needs and requirements), when and how to release features. Releases can also be performed on-demand or separately. So it is better to discuss with your team which strategy you are going to use to avoid any futher misunderstandings.
The development team works on building the software based on user stories and acceptance criteria. In Scrum, release planning is carried out iteratively, often at the end of a sprint when it’s clear how much progress was made.
A particular release which contains changes/features/bug fixes will not be deployed until all comments and testing criteria are taken into account. A release with concrete version number passes through several steps starting from unit testing, integration testing, and finishing with system testing, focusing on functional and non-functional needs, performing both positive and negative test cases.
This implies all actions that make the software system ready to use. In general, the deployment process consists of several interrelated actions with possible transitions between them. This activity can occur from both the developer or the end-user. When a user deploys a release, it is generally described as an installation of the software. “Deployment” generally can be interpreted as pushing and organizing code work in a particular environment.
At this point, the changes are committed to production. Any issues or defects found on the production environment also need to be reported to the stakeholders and fixed accordingly in the next release.
How to manage releases in an Agile world
Based on our experience, we can say that it is better to perform project management using Agile methodology. So let’s discuss how the Agile approach to release management works. First of all it is necessary to mention that this approach is called continuous development.
Continuous development is the ability to incorporate all changes (such as new features, configuration changes, bug fixes, experiments) into production rapidly and reliably by process automation. Traditional approach to releases implies that you will do big releases. But in case with Agile you will be working with smal and more frequent releases since they are much safer and better than big releases.
Such approach to releases helps to:
- minimize apps’ bugs and defects;
- easily adapt and respond to all changes;
- provide updates to users earlier;
- receive timely feedback about the quality, satisfaction, and stability of the software.
And now let’s review the CI/CD (continuous integration & delivery) methodology in details. Check out the picture below and detailed explanations of each mentioned process.
#1 Continuous integration means that all changes made to the code are merged into a central repository (the operation is called a “merge”). The merge can happen several times a day, and after each merge in a specific project, a build is created and testing is started automatically.
#2 Continuous delivery aims to ensure that software updates occur in a sustained way. This set of operations guarantee fast deployment in production without changing the existing functionality. Nevertheless, it is always necessary to base on the needs of the business and the processes of implementing new functionality.
An important remark that if the development of the particular feature was not finished or it hasn’t been tested yet, the technique as feature toggling is used. It implies that the developers hide the feature so that it doesn’t appear in the user interface. It can save time in creating and maintaining an additional branch for this feature as well as resolving conflicts after merging. With this practice, we ensure that the code is ready for release almost all the time.
#3 Continuous deployment is responsible for ensuring that all new functionality after successful testing immediately gets to live environment automatically.
In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand.
Erik to Grasshopper, The Phoenix Project © Scaled Agile, Inc.
#4 DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.
The DevOps model ensures a productive work environment by bringing development and operations teams together. Members of both teams can coordinate their work with each other and collaborate, which helps to reduce risks in the overall release process. A properly configured process helps to detect, analyze, and eliminate any errors in time at any particular stage: while planning, developing, building or releasing changes before they deployed to the live environment.
A collaboration between the development teams and IT operations teams provides timely solutions to the issues of updates, changes in operations software settings, security systems, or infrastructure. As a result the end-user receives benefits of the updated fine product in a short-time period without any delays or critical issues.
Professionals involved in the release process
Release process requires a constant attention of numerous specialist and among them there are developers, QA engineers, DevOps engineers, and even the product owner. Everyone performs certain set of tasks and thanks to the effective cooperation everything is done right on time and every issues is fixed easily. So let’s discover what every specialist does and how this influences the release process.
This is the main stakeholder on the project, who communicates the main objectives, the product vision, and the delivered value. He participates in the entire process in order to ensure consistency in achieving the result, ensure a correct and unambiguous understanding of the ultimate goal, anticipate and eliminate any obstacles, and reduce risks. He also ensures that the final product meets business requirements and helps to organize acceptance testing.
An Acceptance testing is a level of software testing the purpose of which is to determine whether the made changes met business requirements and brought value for the end-users. Acceptance Testing is the fourth and last level of software testing performed after System Testing and before making the system available for actual use. It can be performed by the members of the organization that developed the software or end-users known as beta-testers.
The development team is a key player in release management as they participate in most of the processes in the product life cycle. They estimate the initial cost and time, define the baseline requirements, create documentation, and develop functionality. They also fix all issues on the go and make sure that the solution functions just as it is supposed to.
When we talk about Agile methodologies, usually we use the term DevOps engineer. DevOps uses a set of practices that combine software development and IT operations, which aims are to shorten the systems development life cycle and provide continuous delivery with high software quality.
In other words, DevOps specialist optimizes processes by automating and integrating with the development team to build, test, and deliver software reliably and at a high velocity.
Their main task is to ensure the release meets the established criteria and specified requirements. There are automate and manual QA engineers that perfomr all necessary checks in different ways (by using a written scenarios or checking the connectivity, functionality, etc. manually).
There is also a set of crucial tasks that the manager considers during the release process. He is responsible for:
- Monitoring the speed and quality of deployment;
- Being pro-active, not reactive and managing possible risks;
- Not “breaking” the existing functionality;
- Having a roll-back plan set up;
- Being flexible for new changes;
- Aligning the product delivery deadline with the duration of the release process;
- Finalizing stable versions and thus reducing the number of unstable git branches and versions.
Main release management metrics
As any other development stage, release managements has its challenges too. So it is important to know the key metrics that define whether everything is going fine or you need to perform extra actions to put everything in order. We have collected some main release management metrics that every manager should know about.
Bugs vs Features
It is necessary to always keep track of where the team spends its efforts. Usually, there shouldn’t be a situation where several releases in a row contain only bug fixes, configuration updates, and didn’t bring any new features or functionality. Nevertheless, the team needs to adjust to a golden mean, respecting agile value – responding to change over following the plan, when sometimes valuable changes needed to be delivered as soon as possible instead of planned features.
Additionally, it is important to track the number and severity of bugs in a particular component of the software each release. This will let us know that this functionality requires additional testing and/or certain changes. This can affect another metric, the estimate of the release cost.
Estimated vs Actual release downtime
Discrepancies between the estimated release downtime and the actual release downtime over several releases can help identify bottlenecks and optimize them by making future release plans more accurate.
Number of releases delivered on schedule
If the software changes are delivered not as it was expected, a cause should be identified, assessed, and addressed. This is an important part of continuous improvement. The following questions must be answered:
- For how long the release was delayed?
- At what stage is the release now?
- What is the reason for the delay? (Ideally, the reason for the delay should be identified in advance in order to have time to react, notify the stakeholders, and take the necessary measures.)
- What does the team need to get back on track?
Each stage of project release management is very important. Well-established processes, a collaboration between the teams and stakeholders, attention to results at each stage of the development cycle provide timely and high-quality delivery of software changes.
Every detail should be taken into account, becuse if risks were not counted at the planning stage or requirements were formulated incorrectly – the delivery of the solution and its release can be delayed. It is important to consider all aspects of the release process and communicate it to each member of the team. And that is exactly what project release management is for.