As an industry when we talk about DevOps we tend to lump together the terms CI and CD as if they are exactly the same thing. Looking back on our blogs and collateral, we are certainly guilty of that, but there are a number of differences between CI and CD and the implications of these differences are significant, so in this blog, we wanted to set the record straight and discuss the differences and talk about an interesting new project that promises to simplify CI and CD for Kubernetes environments.
There are three terms that we will cover:
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
While each of these practices shares common practices but differs in terms of scope – how far they go in terms of automation and release.
Continuous Integration (CI)
Over recent years continuous Integration has become the norm for engineering teams, where every merge to a source control repository such as git triggers and automatic build of the application which then passes through automated testing. If the build fails or if the automated testing shows regressions the commit does not get accepted into the master branch. This methodology improves the overall quality of a product by finding problems early in the cycle.
For CI to work you need extensive and robust automated testing, the successful compilation is not enough, your application needs to be run through an extensive set of automated tests to ensure that each small, incremental change does not break existing functionality. This model requires more upfront work in writing tests alongside your code, often writing tests before code is implemented but this investment pays off in terms of quality, velocity and resources as the need for long manual QA cycles is drastically reduced. Automated testing should be quick so a developer can address issues rapidly and then get to work on the next test, bugfix or feature.
In most of our users’ deployments we see the Anchore scan happening after a container is built and before automated testing. This allows any security and compliance issues to be flagged before automated testing to save time and resources – there is no point testing an application that will be failed due to security and compliance issues later. Some users run Anchore after automated testing as they argue that there’s no point running a security and compliance test on broken code. Anchore is flexible to be run in either model, we would recommend that you run the shortest tests first, whether that is Anchore or your automated test suite.
Continuous Delivery (CD)
Continuous Delivery builds on top of the CI process.
There is no deliverable produced as part of the CI process, the result of CI is a well-tested codebase in your source control system. CD goes a step further by automating the next steps in the release process by taking all the steps necessary to prepare for a deployment such as building and packaging the application. While no code is deployed to production all the steps necessary have been performed and so the software can be released or deployed as required however the next step, the actual deployment, is manual.
When running with a CD model there is no need to deploy every build, you make the business decision when you release or promote your software. The beauty of this model is that you can deploy at any time.
Continuous Deployment
Continuous Deployment goes one step further: every commit to the source code repository for a given project is built, tested, packaged and deployed into production automatically. There are no manual steps, no final approval. If the software passes all testing then it is deployed.
While the move step from continuous delivery to continuous deployment may only involve a single click there is are huge organizational implications not least of which is the need for robust operational, monitoring and support practices. For this reason, most organizations stop at continuous delivery until they have the confidence in their infrastructure, testing and procedures.
Jenkins X
The name Jenkins is synonymous with CI/CD and in survey after survey we see their continued domination of the space. But the industry is changing rapidly with cloud deployments being the norm, organizations now deploying microservices, implementing DevOps practices and generally moving to a ‘cloud native’ philosophy. It’s fair to say that even with recent updates Jenkins is showing its age (or perhaps it’s maturity).
Recently the Jenkins community announced Jenkins X which represents the next generation of Jenkins which focuses on the cloud, more specifically on Kubernetes with built-in DevOps best practices, extensive automation and tooling. Over the years we have become used to building Dockerfiles, Jenkins files and now Helm charts and then piecing together tools to automate builds and deployment. The goal of Jenkins X is to automate this work and let developers concentrate on building applications and not infrastructure. You can read more about Jenkins X in their project announcement blog.
This week the Jenkins X team announced the release of their add-on for the Anchore Engine.
With a single command: jx create addon anchore Anchore scanning is automatically added to your Jenkins X pipelines allowing every image built to be scanned for security vulnerabilities. You can now simply call jx get cve to produce a security vulnerability report showing the vulnerabilities in your environments.
This is just the first step in integrating security and compliance more deeply into Jenkins X, there are a number of interesting possibilities that are opened up by integrating two open source projects:
- Policy-based scanning:
Looking at more than just CVEs – adding support for policy checks that can include checks for secrets (keys, passwords), required packages, blacklisted packages, dockerfile best practices, etc.
- Automating remediation
Once Anchore has scanned an image it can continually track the policy and security status of the image. For example, if a new vulnerability has been discovered in an application that has already been built and deployed in your Kubernetes infrastructure. Anchore can send a webhook to notify Jenkins X that a vulnerability has been discovered and that a fix has been published by the operating system or library vendor. What if Jenkins X then automatically triggered a rebuild and test cycle to remediate this issue?
We’re excited to work with the Jenkins X team and encourage you to check out Jenkins X and the Anchore integration. But you don’t need to be running Jenkins X to take advantage of Anchore’s security and compliance scanning, you can add Anchore to your existing Jenkins projects today whether you are using freestyle or pipeline syntax using our free Jenkins plugin.