Releases are risky and painful without doubt. Not only there is the user side of things but also the scripts, manual steps, orchestrations which add another layer of complexity. IT managers struggle with all these while also thinking about the increasing demands. But does it have to be that hopeless? Isn’t there anything we can do to ease the pain? There sure is and I will be discussing it thoroughly.
In order to meet the customers’ needs, developers turned to Agile development methodologies which introduced rapid releases, aiming to solve the needs as they arise. However, Agile methodologies are inherently incompatible with the traditional release processes; traditional release procedures are designed for the infrequent release cycles. This incompatibility meant, release and deployment cycles are stuck somewhere down the line, even when the developers perfected their Agile practices.
The solution to this problem is analyzing the current processes and modifying them to make sure that they are in-line with the current rapid releases. It is best to think to release cycle from the development stage, not just the frame between the finished, release-ready application to deployment. When considering the release process, there should be two goals in mind: protect critical business data and create a reusable process that can deliver value to the business.
The first thing to do is to establish a single point of communication. A release cycle involves development, infrastructure, testing and customer teams and they could be working in different locations. To complicate even further, they could have their own set of tools, processes, management styles and cultures. Therefore it is best to consolidate all information in one place, clarify any questions and then make the announcements. Doing this will ensure that the entire release is transparent, visible and traceable free from any personal interpretation.
Next comes the automation. Many IT departments are in the process of automating their tasks but there is still a large number of companies whose IT departments rely on manual tasks. There are two downsides to keeping manual steps. The first one is it is prone to human error. If it is not documented properly or if any step is missed, it can easily cause failure in the overall release cycle. Second, manual processes are hard to track and manage. To eliminate the manual step risks, automating where possible is essential. In addition, automation has the added benefit of freeing IT staffs’ time, allowing them to focus on what’s important, therefore enabling them delivering more value.
During the release, any dependencies within and between the applications have to be carefully studied and laid out. If the application depends on a particular component, whether in its previous/legacy release or some other component like .NET Framework or Java or any other component, it should be clearly documented. Since failing to take these dependencies can make the deployment fail, make sure that the components and compatibilities are thoroughly tested and only those components that are known and tested to be compatible are released. Do not rely on oral “compatibility” manifests by the developers.
Establishing checkpoints and approvals ensure that the release cycle is proceeding as intended. It is important to define the attributes necessary for the application/release to pass to next stage and test the application/release inside out when one stage is claimed to be completed. This approach, establishing gates and keeping them, ensure that applications and deployments with bugs and incompatibilities do not pass on the next stages and introduce further complexities in the overall infrastructure. In addition, such controls ensure that the requirements are visible to everyone and the cycle does not proceed until it meets a certain status.
Finally, make sure that the procedures are simple and is a single process in each stage of the release. Resist the urge to fully automate and design complex, technically beautiful, automated processes. Rather, it is best to keep things simple, easily understood and obvious. This approach does not only reduce the number of mistakes but also ensures that it is easily carried out, modified and the impacts of the modifications are easier to guess. A large, complex release plan is more likely to be ignored.
When these points are carefully considered and carried out, the release process becomes understandable and manageable. From a larger perspective, the release process becomes standard throughout the environment, from a smaller perspective, the release comes from a known source, from known controls, to a known environment in a known way.
References
- Featured image: http://mukundtechie.com/
1 Comment
Thank you