Continuous Delivery with DevSecOps Reference Architecture

IBM provides a DevSecOps reference implementation which is especially useful for regulated industries to adhere to policies. This article describes the CD pipeline to deploy software using a GitOps approach.

Here is the definition of DevSecOps from IBM:

DevSecOps is an evolution of Agile and DevOps, integrating secure development best practices as early as possible in the software delivery lifecycle (also known as “shift left”). This approach prevents security problems from reaching production systems and failing corporate audits. DevSecOps requires automating security and compliance controls as part of continuous integration and continuous delivery processes. Evidence of these controls is also collected to demonstrate to auditors that every change in history meets the necessary controls.

This article is part of a mini series:

In my previous blog I explained the CI pipeline. 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 pipeline. This assures that new versions can be deployed at any time based on business (not technical) decisions.

The CD (continuous delivery) pipeline generates all of the evidence and change request summary content. The pipeline deploys the build artifacts to a specific environment and collects, creates, and uploads all existing log files, evidence, and artifacts to the evidence locker. Here is an overview of the functionality provided by the CD pipeline:

Determine deployment delta
Calculate deployment BOM
Collect evidence summary
Prepare and create change request
Check change request approval
Perform deployment
Run acceptance test

Let’s take a look at a concrete sample. My team has developed a SaaS reference architecture that shows how our clients and partners can build software as a service. While the compute components are identical for multiple platforms like Kubernetes, OpenShift and Serverless, the way these components are deployed is specific to the platforms.

Here is how the CD pipeline is used for Kubernetes and OpenShift deployments. In order to deploy a new application version for a specific tenant, a pull request has to be created and merged. The pull request asks to merge the latest version from the main branch of the inventory to the tenant specific branches in the inventory. After the latest version has been merged into the branch of a specific tenant, the deployment functionality of the DevSecOps reference implementation uses GitOps to deploy the application to the production environment of the tenant. This is done by comparing the actual ‘as is’ state in the cluster with the ‘to be’ state in the tenant branch.

Here are the key steps performed in the CD pipelines. For the complete flow read the documentation.

Promotion pipeline: The first CD pipeline is a very simple ‘pipeline’ which only creates a pull request.
CD pipeline: The second CD pipeline is the actual CD pipeline.

Create the pull request to deploy the latest version for a specific tenant.

After defining all data, the pull request can be merged.

The actual CD pipeline (the second one) can be started in either of the following ways:

Preferred: Trigger the CD pipeline manually.
Optional: Automatically after every merge action in the inventory repository

Global and tenant specific configuration is read. Either Kubernetes or OpenShift can be used; in a shared cluster or isolated clusters for tentants.

The delta is calculated, since only changes are deployed. Additionally security checks are performed again.

After the actual deployment has been performed, data is collected.

Check out the IBM Toolchains documentation and the SaaS reference architecture to find out more.