Zenergy’s DevOps experts David Dang and Bryson Osborne, and senior test engineer Jonathan Diaz discuss the central CICD pipeline stages for building a mature DevOps pipeline.
“Many companies have built out a DevOps CICD pipeline. But, is it a mature pipeline? When creating your pipeline, there are several stages you will want to include to ensure it is mature. The goal is to automate as much as possible, running from a trigger base all the way to the last stage of your pipeline.” – David Dang, VP of Automation Solutions
Central CICD Pipeline Stages of a Mature DevOps Pipeline
Stage 1: Code Merge
The first step of your CICD pipeline is to merge the code. This will trigger a build which will automatically go through all the steps required to get the code from raw source code into a package that can be delivered to production. Along the way, there are several steps where the code is tested.
Stage 2: Static Code Analysis
The second stage of your pipeline requires the use of a static code analysis tool to scan your project. This scan will ensure that code quality and cyber security standards are being upheld in the project. This also relieves employees from having to schedule code and peer reviews as well as manually having to pore through the code to verify all the things that can be done automatically by a static code analysis tool.
Stage 3: Unit Tests
Unit testing is performed in the static code analysis stage. In this stage you are ultimately testing whether the unit tests within your pipeline have quality and are valid. This is important as it allows you to minimize cost by identifying underlying issues in your code changes, earlier in the process.
Stage 4: Unit-Integration Tests
The next stage, unit-integration testing, integrates multiple units of code together and tests them. Unit and unit-integration testing are fast, lightweight, and quickly provide you with a pass/fail result for your project.
Stage 5: Code Coverage
In this stage you will utilize a code coverage tool to analyze the project to determine the percentage of code being covered by the tests. The results should provide you with a metric (i.e. 60%) that will be recorded for display on the pipeline dashboard. It’s important to note that while this tells you how much of the application code is covered by testing, it does not ensure the quality of the tests that are being written; the tests are only useful if they provide valuable insight. This is something that still needs to be ensured separately.
Stage 6: Package
Once you are satisfied with your code coverage and test results you can then build the package and store it in a retrievable location. You will want to ensure your build process is versioning your packages for easy roll-back should anything break when the package goes to deployment.
Stage 7: Deploy
Once you have built the package you will automate a deployment to your QA or user acceptance environment. With a sufficiently mature pipeline, you should have no fear of (eventually) deploying directly to your production environment.
Stage 8: Post Deploy Testing
After the package has been deployed, post-deployment testing will occur to ensure the product release is working as intended, introduces the expected behavior, doesn’t break existing behavior, and meets the stakeholder’s requirements.
Stage 9: Notify
The notification stage is where your pipeline tools communicate the status of your build or deploy job. We suggest an integration into your real-time communication tool of choice (Slack, Skype, or Teams for instance), because integration with email systems tends to quickly become overwhelming and is eventually ignored entirely, completely defeating the purpose of this step.
Stage 10: Dashboard
The final stage of your pipeline is the dashboard where all your results are collected. While some may not include this stage in their pipeline process, it’s critical to provide visibility and transparency into how your pipeline is performing. This will help align your team by providing them with insight on the trends and failures your pipeline is reporting, and by helping drive to the root cause of failures.
Including these central CICD pipeline stages in your DevOps pipeline should result in a more mature, automated, “no-touch” pipeline that can provide real-time updates on its current status and performance and allow your team(s) to locate underlying issues earlier in the build process.
>> Subscribe to Zenergy on YouTube for more videos.