Best Practices for Continuous Delivery
Is your continuous delivery (CD) pipeline running as smoothly as it should? The best practices below will guide the development and implementation of your CD pipeline and prepare your DevOps teams for success.
Develop a CD Mindset
Continuous delivery is a process, first and foremost, but it’s also a way of thinking. In a CD environment, application builds are always deployment-ready, which means DevOps teams should:
- Set up automated tests for the build (with the code coverage required to be deployment-ready)
- Use the same build of the application through the entire pipeline (i.e. only build the application binaries once, not at every environment!)
- Fix problems in the code, not in place.
- Abandon a build that has problems and is not deemed worthy.
Check the code in, let the pipeline work, and move the new build through the pipeline.
Once everyone is working toward a common vision of CD, you can start taking meaningful steps towards building an effective continuous delivery pipeline.
Securely Migrate to the Cloud
Cloud computing is quickly becoming the standard for modern applications and enterprises. Learn how to securely migrate to the cloud today!
Implement (and Refine) Continuous Integration
You can practice continuous integration without continuous delivery, but you can’t practice continuous delivery without continuous integration. Continuous integration (CI) involves merging software code into an automated build process and running automated tests when updated code is added to the source code depository.
Once CI is in place, continuous delivery (CD) simply extends the integration process to the actual release. When your CD pipeline runs like it should, software products aren’t tied to development timelines or dependencies; instead, they’re delivered based on consumer demand and the state of the market.
Create at Least One Stop Between Development and Production
To get to the point where everyone is comfortable (and releases are so routine that they’re mind-numbingly boring), the pipeline needs at least one stop between development and production. You need at least one completely hands-off environment to validate that the release is production-ready and all the scripts and mechanisms included in the release will build the environment and deploy the application as planned, every time.
Some projects will have five or more environments to stop at along the way, including:
- System testing
- UAT (User Acceptance Testing)
No matter how many environments you’re working with, remember that development to somewhere to production makes everything run more easily.
Deploy to Every Environment the Same Way
The core concept behind continuous delivery is that the entire release package—from the application build to the scripts that build and configure the environment it runs in—is solid and ready for production. Production should simply be another environment to run the same automation through the same steps.
No matter the environment you’re deploying to, use the same automated release mechanism. This helps troubleshoot the deployment process itself and results in fewer issues deploying to both lower environments (integration, QA) and higher environments (pre-production and production).
Fail and Restart Your Pipeline
The true value of a well-running continuous delivery pipeline is how easy it is to start again at the beginning.
Anyone in development or operations remembers how they used to tweak settings in an environment by adding a manual step or two—which compounds as the number of environments increase—to accommodate one little thing “because there isn’t time to fix it right.” This whole manual inefficiency goes away with a pipeline using immutable infrastructure like Docker containers.
If it didn’t work, stop and find out why. Fix it back at the beginning, and then let the automation take over and get you back to the point where you paused.
This may seem obvious, but it’s worth restating: automate everywhere you can.
We see it more times than we care to admit: one or two steps are still manual and it has to be done before/during/after a release is deployed for everything to work. You may not realize it’s manual, but the most common telltale sign is that the pipeline only seems to work as expected when specific staff is involved. This is not malintent—it’s just human nature! If something is routine, you may not even think about it. It might not have even occurred to them to automate that step in the right script.
To run up a successful pipeline, take a good look at your end-to-end process and uncover where you’re doing things manually (and make a plan to automate it).
Version Control for Everything
Use a version control system (like GitHub, SVN, or Team Foundation) for every script, database change, and configuration file that is part of the release package. Binaries can and should be stored in a package repository like Nexus, Artifactory, or Archiva. (Otherwise they just cause trouble if binaries are inside a code version control system.)
For traditional IT operations teams, having a version control system—rather than just having directories renamed with things like “old” or the previous date in the name—may take some getting used to. But once you have a strong version control system (and it saves you from laborious rework a few times), you’ll wonder how you ever lived without it.
Include the Database in the Pipeline
To have a truly automated and repeatable application deployment, you should include all changes to the database as part of releases. This can be done as part of the application itself or by using a third-party tool like FlyWay or Liquibase.
Monitor Your Continuous Delivery Pipeline
No matter how well-tested your code is, a faulty algorithm, dependencies on services and system resources, or failure to account for unforeseen conditions can cause software to behave unpredictably.
Within the CD pipeline, troubleshooting can be difficult—and in cases like debugging in a production environment, it may not even be possible. By proactively monitoring telemetry throughout the pipeline, you’re more likely catch problems before they reach production.
Get Your CD Pipeline Flowing
There’s a lot more to be said for continuous delivery, but following the best practices above is a good way to set up your DevOps teams for success.
- Continuous Delivery
- Continuous Delivery Best Practices
- Next: What is Continuous Integration?
- Continuous Delivery vs. Integration vs. Deployment
- DevOps as a Service: Build Automation in the Cloud
- Agile DevOps
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.