Continuous Integration (CI) is the process of automating the building and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the trunk or main).
Continuous Delivery (CD) is a software development practice where code changes are automatically prepared for a release to production. Continuous delivery expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment after the build stage. When properly implemented, developers will always have a deployment-ready build artifact that has passed through a standardized test process.
Continuous integration and delivery require continuous testing. Continuous testing is often implemented as a set of tests (unit, regression, performance, etc.) that are executed in the CI/CD pipeline. Setting up a CI / CD pipeline is easier than ever before for small teams. In this example, we quickly set up a CI/CD project on AWS:
Your CI / CD pipeline has been set up and your project is configured to automatically build, test, and deploy to a staging environment. So what are some immediate benefits?
Faster Feedback – Because continuous integration provides teams with an automated way to build, package, and test applications, you get quick answers to the question “did I break something?” for each commit.
Problem Identification – If a something DOES break after a commit, CICD helps quickly track down the source of the error. If various types of automated tests are executed in your CICD pipeline, you will be able to identify the issue as soon as a specific test fails.
Increased Transparency – Your entire team can track the live status of builds and can also access the most recent test reports. In the video above, we show where management can administer access to the CI / CD pipeline on AWS.
Code Coverage – Code coverage is a measurement of how many lines of your code are executed while the CICD automated tests are running. Your CI can be configured to capture this measurement. If a change is committed without any new tests, your coverage percentage metric will drop as a result of your changes.
Easier Integration – Often times a piece of code is fine on its own, however you will still need to make sure the change functions once integrated with everything else. With an automated CICD pipeline, code commits are connected to all components of your software.
Improved Code Quality – The easier it is to test code, the easier it is to determine its quality. With CICD, code tests are continuously executed, resulting in robust software that is developed to accommodate non-stop testing.
You’ve got the basics. Now, let’s walk through a more sophisticated CI/CD example using the very popular automation server, Jenkins:
Scaling CI / CD Throughout your Org
Slow Organic Growth is Key
Too many CICD process changes at once can prove overwhelming for even the most agile organizations. Not ALL “best practices” and popular automation tools are a fit for every environment. Qualitics recommends asking the following questions before adopting any process changes:
Does this best practice improve my processes?
Does this best practice help me balance company culture and agility?
Does this best practice improve the quality of my service?
Environments – The number of environments (Dev, Staging, Prod, etc.) will impact your CI / CD configuration. Each environment will require a different set of validations.
Team Size – Developers are most impacted by branch management (the more developers, the more code merge implications & complexity). Don’t forget to consider your team’s size and setup (Agile, Scrum, Waterfall, SAFe etc.) when implementing CI/CD.
Other Agile Nuances – Every agile environment is different and faces different sets of constraints. Your organization’s budget, tool stack, release planning, and compliance requirements need to be accounted for when developing your CICD processes.
Interested in taking the next step in CICD? Qualitics can help. Below we share a final example of a Jenkins CI/CD environment that is configured to run smoke tests bi-hourly and report the results to our Slack channel.