Overview

This pipeline is designed to enhance your development workflow by enabling early feedback through preview environments. It adds custom stages to the base PR pipeline, such as deployment and acceptance testing, which are useful for functional validation before code is merged.

The App-Preview pipeline is used to:

• Build and containerize the application
• Perform artifact scanning
• Deploy the application to a preview environment
• Run acceptance tests to validate functionality

App - Preview PR Pipeline Stages

Comparison: PR Pipeline vs App Preview PR Pipeline

The App Preview PR Pipeline is an extension of the regular PR pipeline, it builds by adding stages for building, scanning, deploying, and previewing the application.

The App Preview PR pipeline helps catch issues early and ensures that changes behave as expected in a simulated production-like setup.

These additional stages allow:

• Static code scanning (code-static-scan)
• Building deployable artifacts (build-artifact)
• Scanning artifacts for vulnerabilities (build-scan-artifact)
• Deploying to a preview environment (deploy-app-preview)
• Running acceptance tests (deploy-acceptance-tests)

Customising pipeline stages and tasks

The table below lists the tasks run in a App-Preview PR Pipeline. In addition the table also provides an overview of each of these stages:

• Task or Stage: This refers to the name of the stage as defined within the .pipeline-config.yaml configuration file.

• Short description: This provides a concise explanation of the actions performed during the execution of the stage.

• Customisation permissible: This indicates whether users have the flexibility to modify or replace the default behavior of the stage by inserting a custom script in the .pipeline-config.yaml file.

• Default Reference Implementation: This indicates whether the DevSecOps pipelines come with a pre-defined or default implementation for the stage. Notably, for certain stages like unit-tests or setup, the DevSecOps pipeline doesn’t offer any out-of-the-box implementation. Instead, users are required to provide custom scripts or code tailored to their application’s requirements.

• Evidence Collection: This indicates whether the stage performs the collection of standard evidence. When DevSecOps Pipeline provide a reference implementation for a stage, evidence collection is performed out-of-the-box. However, if User choose to modify or replace these predefined stages, they must ensure that their custom implementations include appropriate evidence collection. The same responsibility falls on users for stages where the DevSecOps pipeline doesn’t provide an out-of-the-box implementation, necessitating them to perform evidence collection. The column indicates the entity (User/Pipeline) responsible for carrying out the evidence collection.

• Skip permissible (applicable to version >= v10): This indicates whether users can opt out of running this stage by setting the skip property to true in the .pipeline-config.yaml. However, caution is advised when using this feature, especially for stages designed to collect evidence. Skipping such stages might lead to missing essential evidences for the build.

For more information about how to customize stages by using the .pipeline-config.yaml file, see Custom scripts and Pipeline parameters lists.

Collecting evidences in the pipeline stages

For more information about how to collect evidences within the customizable user stages by using the collect-evidence script, see collect-evidence script.

Prerequisites

Ensure that:

• A CI toolchain is created using the “Create Toolchain” option.

• The CI pipeline has a working Git PR trigger.

• Required environment variables and permissions are correctly configured for image registry and deployment.

Setting up App-Preview PR Pipeline

Detect Secrets Scan

The IBM Detect Secrets tool identifies where secrets are visible in app code. More information on setting up your repo for the scan is available here

Static Code Scan

The static code scan stage runs a number of static code analyzer tools on the specified app repositories.
The repos provided by the pipelinectl save_repo command and the default app repo are scanned.

You can use any of the following methods to add static code to your pipeline:

• Provide an already running SonarQube instance name, URL, and credentials by adding the SonarQube tool to your toolchain. The static-scan task runs a scan on the specified repos.

• If you don't have your own SonarQube instance, the pipeline creates a SonarQube instance during the pipeline run. You can access this instance after the static-scan stage successfully runs.

• By using the opt-in-gosec parameter to run the gosec scan for golang security checks.

• Add your own static scan code to the static-scan custom stage in your .pipeline-config.yaml file for a custom implementation.

Adding SonarQube Scan to Your Pipelines

For more information about integrating SonarQube with the continuous integration pipeline, see Configuring SonarQube.

Adding GoSec Scan Integration to Your Pipelines

Use gosec to inspect Golang source code in your scanned repositories.

To enable the GoSec scan, provide the following parameter:

For more information, see Configuring GoSec.

Scans and Checks in Compliance Checks

These scans are run on all application repositories that the pipeline is aware of.
To add repositories to these scans, use the pipelinectl interface during the setup stage.

For more information about the expected output from user script stages, see Custom Scripts.

Build Stage

In the Build stage, you can build your own artifacts.
While the pipeline provides default features for Docker image artifacts, you can build any type of artifact.

Use environment variables configured in the Pipeline UI to provide credentials, secrets, and parameters for your build.

These variables are accessible in this and all custom stages.
For more details on how to access parameters and secrets in custom scripts, see Custom Scripts.

Artifact Scan

In the App-Preview PR pipeline:

• Only the artifact scan happens.
• The scan checks for vulnerabilities in the built Docker images using the Container Registry Vulnerability Advisor.

You can customize the scan behavior by modifying the .pipeline-config.yaml file if needed.

Deploy

The Deploy stage deploys built artifacts into a environment.