Continuous delivery best practices are all about thoroughness and detail. CI/CD best practices must be thorough because they should span the entirety of your development activities, from a minor configuration change all the way to version release. Continuous delivery best practices must also adhere to detail because, for example, if you fail to check even one box while building binaries, that mistake will inevitably come back to haunt you. In short, effective continuous delivery best practices occur both horizontally and vertically within the organization.
To give you an idea of how far CI/CD best practices need to go, let’s look at some of the disciplines that should be followed for every coding change.
Build Once, Deploy Many
Compiling code should only happen once under a CI/CD best practices regime. This eliminates the risk of introducing differences due to environments, third-party libraries, different compilation contexts, and configuration differences.
Same Deployment for all Environments
When operating with continuous delivery best practices, you should use the same automated release mechanism for each environment and make sure that the deployment process itself is not a source of potential issues. Although you probably deploy many times to lower environments (integration, QA, etc.) and fewer times to higher environments (pre-production and production), you can’t afford to fail deployment to production because you are using the least frequent deployment process.
Frequently execute non-exhaustive software tests that skip some of the finer details (like services, database, messaging bus, external services) but still ensure that the most crucial functions of a program work. This will give you the confidence that your application actually runs and passes basic diagnostics, which is yet another advantage of continuous delivery best practices.
Deploy into a Copy of Production
Create a production-like or pre-production environment, identical to production, to validate changes before pushing them to production. This will eliminate mismatches and last-minute surprises. A copy of production should be as close to production as possible with regards to infrastructure, operating system, databases, patches, network topology, firewalls, and configuration.
The first stage should be triggered upon every check-in, and each stage should trigger the next one immediately upon successful completion. If you only build code on an hourly basis, or only run acceptance tests nightly, or only load tests over the weekend, you will prevent the achievement of an efficient CI/CD best practice process and not acquire a reliable feedback loop.
Stop the Line
When a stage in the pipeline fails, you should automatically stop the process. Fix whatever broke and start again from scratch before doing anything else. Continuous delivery best practices help to establish a release mechanism that will reduce development costs, minimize risk of release failures, and allow you to practice your production releases many times before actually pushing the “release to production” button. Similarly, CI/CD best practices ensure that fewer gaps remain between development and production while guaranteeing quality and making sure that you always retain visibility of production readiness.
Once you have implemented continuous delivery best practices, you will have established an efficient deployment pipeline where any changes proceed through the following steps:
- Process initiation (triggered by a code check-in or configuration change)
- Unit tests and static code analyses
- Application and regression tests
After the flow is complete, the change can be either ready for production use or go through additional manual and user-acceptance tests before hitting production.
As a final note: databases are an essential aspect of continuous delivery best practices, but they come with a different set of challenges than application code. However, implementing continuous delivery for the database is a challenge that we can help you with.
Want to learn more about CI/CD best practices and the database? Click here for more information.