Your codebase likely has a lot of busy hands. Imagine if every single developer cloned the entire master branch and merged their changes without any testing: the quality and maintenance of code would be a disaster. This is where continuous integration (CI) and continuous delivery (CD) come in.
Continuous integration and continuous delivery force your team to commit and test smaller increments using automated processes and testing. This ultimately allows them to iterate and deploy faster.
Today, we’re going to go through some CI/CD best practices.
Rule 1: Use Version Control
Keep track of your CI/CD pipeline using tracking and version control tools. This makes it easier to collaborate with your team and maintain visibility into the progress of your software.
Make sure that everyone on your team is trained in your approval process for changes, and try to have a manual approval step before anything is changed in production. It’s always safer to avoid automatic changes in production. As an extra safety measure, a tool like Github will check with your CI tool and show failed checks before merging pull-requests to a master branch. In the same vein, everyone on your team should also be trained in performing a rollback for a bad release.
Rule 2: Keep it Separate and Simple
The objective of CI/CD is to simplify your deployment pipeline. As such, you want to keep things fast and lean. If something takes hours to run, it could slow down the entire team. In order to do so, you could:
Make it easy to troubleshoot. Keep the CI/CD configuration simple and easy to understand, and add comments wherever you can. In addition, although this is not always possible, try separating your CI/CD pipeline into stages to help with visibility and troubleshooting if part of the pipeline fails.
Limit deployment to production. Isolate your deployment to production to only one branch. This helps avoid a situation where you deployed the wrong code to production because of a misconfiguration.
Use what’s already available. Research and make use of the tools and special environment variables available from your CI/CD provider. They can simplify your work and improve your build quality. When it comes to CI/CD, the less you do, the better. For example, do not build your own container images if you don’t have to. If you just need a public tool like Nginx to serve your own custom assets, it’s better to reuse the public Nginx image and mount your assets as a volume as opposed to building your assets into a container image during CI. This way, you don’t have to pay to store the custom Nginx image and you can update it independently of the assets.
Rule 3: Set up with Testing in Mind
It’s a good idea to set up CI/CD even if you do not currently have any tests available. It is nonetheless a good practice to use as a deployment tool.
Once you have tests in place, use your CI/CD pipeline to deploy to staging and test before production. During this stage, if your CI/CD script fails, fail the entire build pipeline. You want to clearly see where the problem lies without accidentally overriding the current stable state.
Rule 4: Stay Secure
As always, take security into account. Never store your credentials directly in your Git repository. Enforce the ‘principle of least privilege’ (PoLP) and restrict exposure to threats by using VPNs, strong two-factor authentication, as well as identity and access management.
Rule 5: Implement Monitoring
No matter how well-tested your code and environment is, your CI/CD pipeline is also vulnerable to issues in production. What we’ve learned over the years is that troubleshooting production in a CI/CD pipeline is difficult, and sometimes even impossible.
In cases like this, a strong monitoring system will help you detect issues like faulty algorithms and overdependence on services/system resources.
Conclusion
By using all of these best practices, you will have the ability to iterate and deploy faster by implementing a Continuous Integration and Continuous Delivery pipeline.
What stage of your CI/CD pipeline creation are you at? Let us know.