Continuous Delivery – Is it right for you?
This post is provided by App Dev Manager John Tran who explores the question: Is continuous delivery right for you?
Coming from the operations world, I can’t count the number of times someone has come to me asking for a production deployment on a Friday afternoon. This would always give me chills, thinking of all the late nights that I’ve been up fixing production issues, thinking of all the news articles about someone making a change over the long weekend and causing a nationwide outage, dreading the day after when I had to explain what went wrong…
Taking a step back and looking at the situation from the business point of view; a deployment can mean the success or failure of a major marketing campaign or a missed opportunity to beat a competitor to market. Why can’t we release whenever we need to?
“Continuous delivery is a DevOps software development practice where code changes are automatically built, tested, and prepared for a release to production”
The idea of continuous delivery (CD) can be a scary thought. The deployment tasks can be some of the most stressful steps in the development process but this doesn’t have to be the case. CD is an achievable goal, but it takes a lot of hard work and discipline to implement correctly. Below are a few of the checks and balances that need to be in place to successfully create a CD pipeline.
Smaller deployments = smaller risk.
Reduce the risk of deployment by reducing the size and complexity of your releases. The large “big bang” type of release brings with it uncertainty and added effort to deploy and validate. The deployment tasks themselves can be incredibly complex and stressful. The uncertainty around any deployment needs to be reduced until the task itself is predictable, repeatable, and reliable. When the size of the release is small and manageable, you can release more often and with more confidence in your delivery.
Source control – gated check-in
In order to support CD your source control strategy must be simplified and optimized. The branching modal should strive to eliminate deep branch hierarchy’s, reduce merge and integration debt, remove restrictions in code flow, and remove complex build logistics that operations must understand.
Checks and balances need to be put in place in order to maintain quality. Practices such as gated check-ins, peer code reviews, automated unit and regression testing must be completed before code is allowed to be checked in.
Feature Flags
Implementing feature flags into your code allows you to decouple the deployment from exposing your code to users. This gives you the ability to deploy new features to production without allowing user access until you are able to fully validate. Feature flags provide runtime control of your code with granularity down to individual users, change without redeployment, control via PowerShell or web UI, supports early feedback and experimentation and a quick on/off switch if things do go wrong.
Safe-Deployments – Deployment rings
A “Safe Deployment” utilizing deployment rings allows you to release changes to risk tolerant customers first, progressively roll out to larger and larger sets of users. Safe deployments allow you to deploy more often delivering more value to your customers. The deployment tasks must use a consistent deployment tool in Dev, Test and Production. Using release management tools to automate and orchestrate your deployments and enable the development team to trigger builds automatically.
Shift left testing
Common complaints with testing are the tests take too long to run, the tests fail frequently, the quality signal from the tests are unreliable and testing is always left until the end. “Shift left testing” tries to address each of these concerns. The principles of shift left testing are:
- Test should be written at the lowest level possible
- Write once, run anywhere including production systems
- Product is designed for testability
- Test code is product code, only reliable tests survive
- Test infrastructure is a shared service
- Test ownership follows product ownership
Deploy anyway, fix forward
Knowing that perfection is not achievable, you should release early and often. Understanding that bugs will be introduced; deploying early and fixing forward allows you to deliver more value faster. Because you have reduced the risk around deployments it makes the process of fixing bugs a lot easier and faster.
Conclusion
The value of continuous deployment is obvious. Lower risk releases, faster time to market, higher quality, and lower costs; however, CD is not something that you can rush into. Checks and balances must be in place so that you can accelerate the delivery of value to your customers and still guarantee a high level of quality.
This is an iterative process of learning and improvement. Eventually you can take away the stress of deploy night and reduce the risk enough that you can confidently rely on your deployment pipelines.
Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.
Light
Dark
0 comments