Advanced DevSecOps pipeline customization

Toolchains and pipelines considerations

Most applications are made of multiple microservices with different source repositories. Usually, a single toolchain is used to host microservices that are logically grouped. In general, use one toolchain and one pipeline, or as few pipelines as possible, but multiple triggers. Within each pipeline, you can duplicate and configure as many triggers as you need, up to 1024 triggers per pipeline. This strategy helps enforce common processes, scripts, and configuration files. For more information, see configuring multiple apps on one CI toolchain.

This approach has the following advantages:

• Using fewer pipelines avoids duplication and decreases errors. Updates are also easier to maintain, for example, when an environment property or secret is added, edited, or deleted.
• Onboarding a service is quicker with this approach. Add a Git integration for your microservice, duplicate the Git and manual triggers and modify them as needed. Then, make sure your .pipeline-config.yaml file and scripts are implemented for your microservice.

This approach has the following drawbacks:

• One edit can impact every team that is using the same pipeline.
• User access is managed by using Identity and Access Management (IAM) and is set at the toolchain level, not the pipeline level. So, if you are using a single toolchain for multiple services, every member of the team can view other teams' pipelines. Depending on the user's access in IAM, they might be able to edit, delete, or trigger a pipeline.

Billing considerations

The Continuous Delivery service determines billing based on the number of authorized users per CD instance, and how many resource groups you use for your toolchains. Users who have access to your repositories are also considered authorized users. For more information, see authorized users. To reduce costs, make sure that all of your toolchains are in the same resource group. Doing so does not affect a toolchain's ability to deploy into other resource groups that contain application environments.

DevSecOps repositories considerations

If you are creating an application that is composed of multiple microservices, most DevSecOps repositories - except the evidence repository - can be shared across the microservices.

For more information, see how DevSecOps pipelines use repositories.

IBM Cloud Object Storage considerations

If you are using a shared inventory repository and a shared issues repository, you can use a shared instance of IBM Cloud® Object Storage as well. Complete the following steps:

1. Create an instance of IBM Cloud Object Storage to use across toolchains and pipelines.
2. Within that shared IBM Cloud Object Storage instance, create one Object Storage bucket per microservice.
3. Set up pipelines and triggers, if applicable, to use the IBM Cloud Object Storage bucket by setting the cos-bucket-name environment property.

All microservices within the same CI, CD, and CC pipelines share one Object Storage bucket, regardless of the deployment environment. The Object Storage bucket functions similarly to the evidence repository, but without the performance issues that can occur with a large evidence repository. Because performance issues don't occur with a large Object Storage bucket, you don't need to prune evidence from Object Storage buckets.

Deploying to multiple environments

Deploying to multiple target environments with the CD pipeline can be achieved in several ways.

Each targeted environment should have a corresponding branch in the inventory repository, where changes are promoted from a source to a target branch.

The following optional designs might fit your architecture:

• Use one manual trigger per target environment. Duplicate a trigger, then edit the environment properties to fit the new environment.
• Use a Git configuration repository with one folder per target environment, where specific configuration settings are stored in files.

Identify which script is run

To identify which script is run for a stage, open the pipeline run (preferably a CI pipeline). Expand a task, then click run-stage to open the logs. The beginning of the run-stage logs provides information about the scripts that were used in the stage, including which repository the script is located in. In the logs, you can scroll to find more details about the scripts that were run. For example, the code-compliance-checks task might have the following information in the run-stage log, which includes environment properties for the stage:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

In that example, the script that is run is /opt/commons/compliance-checks/run.sh, which is located in the commons library. Use this commons library as a source to copy code that can be customized for specific edge cases. In the example, compliance-checks/run.sh is located in the compliance-commons library.

Overriding default scripts

To override default scripts, complete the following steps:

1. In the stage log, copy the snippet that identifies a default script:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

1. Paste the snippet into your .pipeline-config.yaml file.
2. Add your custom code before or after the script is called.
3. Edit, delete, or add properties as needed.

The following example shows the updated script in your .pipeline-config.yaml file:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

For more information, see custom scripts.