Many software development teams are now working in Agile/Scrum way and that’s great! One of the cornerstones of Agile way of working is “Deliver value fast and often”. Real value is delivered only when software is running in production (not Dev, not QA J).
Having right deployment principles and practices in place is all the more important in Agile environments because new increments are produced by scrum teams at the end of each sprint. A right deployment strategy is a key factor to have faster and effective feedback loops from each environment. Below are some of the best practices for application deployments.
Build once deploy anywhere
Do you run into situations such as “Hey! It works on QA but not UAT or Prod”. One of the root cause of such situations is creating build artifacts for each environment. It is key to promote same package which was tested in lower environments (Dev/QA) to later environments (UAT/Prod). You will introduce unwanted risk if you build codebase everytime to deploy to different environments as there is always a hidden danger of introducing unwanted changes. Automated deployments are very effective only when a same deployment package goes through different quality gates. If you change/ build deployment package for each environment, you are bypassing lower environment quality gates.
Hint: Use same build package and promote it through all environments.
It should be a people first process
Using right tools for application deployments is important. However, focusing on tools alone will not help. Deployments are smooth when there is a better collaboration between people who build the software and people who deploy the software. When work is done in silos, focus is narrowed which leads to expensive and time consuming handoffs. Improving the speed of the slowest member of a convoy increase the speed of whole convoy. In the same way, having better collaboration and elimination of waste during handover improves over deployment process.
Hint: Improve collaboration between Dev and Ops to minimize handovers.
Make deployments boring
Deploying to production need not to be a ceremony. Production deployments need to be routine, boring events because same process is used all along for each environment. New features you deploy to production should give you excitement but not the deployment process J. You will add unnecessary complexity if you customize deployment process for each environment.
Hint: Use same repeatable and reliable way of deployments to each environments.
Automate, automate, automate
Automate your build process, automate your application/component configuration (configuration as code), automate your infrastructure (infrastructure as code), automate your deployment process. A good rule of thumb: “Everything that does not require human judgment/intervention is a candidate for automation”
Hint: Visualize your current end to end deployment process and identify quick wins and low hanging fruits to automation or to identify bottlenecks
The Architecture Drives the Build
Batch size has great deal of influence on flow and architecture influences batch size. If you modify or add one line of code, how big is the impact on testing, building and deploying the package? Follow standard design principles such as separation of concerns, Single Responsibility principle, Principle of Least Knowledge, Don’t repeat yourself and minimizing upfront design. As depicted below, if you have a spaghetti architecture deploying a change is expensive and time consuming, so choose Ravioli 😉
Hint: Choose a loosely couple architecture and focus continuously on architecture refactoring
Manage your dependencies
One of the key challenge working in distributed, multi team environment is dependency management. There is a high need to ensure easy distribution of artifacts produced by different teams as they share dependencies between them. Using a repository manager comes in handy in this situation. It is also useful to define access rules for users and groups that consume artifacts so the consumer uses right artifacts/version. Other benefits of using a repository manager includes reduction of build time as significantly reduced number of downloads off remote repositories. You can also use a repository manager in case you want to roll back to a previous version.
Hint: Always use repository manager to manage your dependencies and version control your build artifacts.