When you are managing potentially hundreds of applications across different environments, developing a rhythm for releasing code at the right times is a challenge. Technical Delivery Manager Colleen Stock has gone down the road of trying to smooth out a bumpy deployment process before. In an article for AgileConnection, she shares four steps that have worked for her in creating improvement:
- Find the bottleneck.
- Don’t get in the way of development.
- Automate testing with useful outputs.
- Educate the organization.
To locate where things are bottlenecking, just look for which work is taking teams the longest to complete. In Stock’s case, she found that one person was responsible for organizing deployments for 120 different applications, all of which were manually configured. As a result, deployments to production happened at best on a biweekly basis, which is a whopper of a bottleneck in an agile environment:
At this point, we had a good sense of where we needed to focus. It made sense to take all those application configurations, figure out what the similarities are, define a standard format, and automatically parse through them. In this way, we automatically configured the applications in each environment instead of having some unfortunate individual do this by hand. Automating our application configuration process both accelerated our deployments and reduced the number of bugs in the deployment process.
In order to not get in the way of development teams completing their work, Stock and her team went so far as to move over other teams’ applications for them into the new standardized format. It took a considerable amount of time, but it was ultimately still faster than teaching all of the development teams the process that they had developed. The final result of that work was an “ability to automatically deploy applications to an environment.” They also built automated tests to determine if developers were correctly using the automated deployment process.
The final step of an improved deployment process is ensuring everyone understands where it came from and why it is better. Start with one team, where you can work out kinks in your tooling. When the team has questions, include answers in a Readme, and apply the experience you had with this first team with the next team you see. Allow the education to proliferate across teams and management as it becomes more robust and reliable. Then your new deployment process is fully fit for operations.
For a more detailed explanation, you can view the original article here: https://www.agileconnection.com/article/fixing-broken-deployment-process