IBM provides a DevSecOps reference implementation which is especially useful for regulated industries to adhere to policies. This article describes the CI pipeline which provides in addition to the usual CI functionality change, evidence and issue management capabilities.
This article is part of a mini series:
- DevSecOps for SaaS Reference Architecture on OpenShift
- Shift-Left Continuous Integration with DevSecOps Pipelines
- This article: Change, Evidence and Issue Management with DevSecOps
- Continuous Delivery with DevSecOps Reference Architecture
- Tekton without Tekton in DevSecOps Pipelines
The CI pipeline template that is part of IBM’s DevSecOps reference implementation builds and pushes images and runs various security and code tests. Only if all checks pass, the application can be deployed to production via the CD pipelines. This assures that new versions can be deployed at any time based on business (not technical) decisions.
Functionality of the (second) CI pipeline:
- Build and push images
- Run various security checks (secret detection, image vulnerabilities, compliance)
- Run various code tests (unit tests, acceptance tests)
- Deploy services to integration/testing Kubernetes namespaces or OpenShift projects
- Manage changes, evidence and issues
I’ve documented all steps of the pipeline on GitHub. Let’s take a look at the most important steps.
The CI pipeline is triggered automatically after the pull request has been merged (see previous article).
The CI pipeline reads both global and tenant specific configuration from a Git repo. In the CI pipeline the tenant configuration is not from an actual tenant, but a dummy/test tenant used to run the CI tests.
The image is built and pushed.
Next various security, vulnerability and compliance checks are run. Then the container is deployed to an integration/testing Kubernetes namespace or OpenShift project to run more tests.
The status can be monitored in IBM DevOps Insights.
The latest successful version is stored in the inventory repo.
Evidence is collected in the evidence repo.
If the pipeline run has been successful, no issues are created in the compliance issues repo.
After a successful run of the CI pipeline, the CD pipeline can be run. I’ll blog about this soon. Check out the IBM Toolchains documentation and the SaaS reference architecture to find out more.