Develop and deploy an app by using IBM Cloud Satellite

Related content

• Getting started with Continuous Delivery
• Getting started with clusters
• Getting started with toolchains

Configure the toolchain name and region

Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud. Make sure that the toolchain's name is unique within your toolchains for the same region and resource group in IBM Cloud.

The toolchain region can differ from the cluster and registry region.

Select the deployment strategy

The toolchain creates a Continuous Deployment Pipeline to deploy the application Docker image on the cluster group that is defined in Satellite.

1. Click Multiple clusters via Satellite to deploy your app by using Satellite.

   

2. Click Continue.

Configure the application source code repo

In the Application step, the recommended options for the application source code repo are displayed by default. To view all of the available options for the underlying Git integration, click Advanced Options. By default, the toolchain uses the default sample that clones the sample app as an IBM-hosted Git Repos and Issue Tracking repo.

You can change the name of the app repo. The region of the repo remains the same as the region of the toolchain.

The toolchain template provides a Hello Containers Application app. If you want to link an existing Application repo for the toolchain, select Bring your own app and specify the URL for the repo. The toolchain supports linking only to existing Git Repos and Issue Tracking repos.

By default, the application repo template is cloned to your Git Repos and Issue Tracking org. To change the org, enable Advanced options and specify the repo owner.

Configure the inventory repo

The inventory repo records the details of the artifacts that are built by the continuous integration toolchains. You can either create a new inventory repo that is a clone of the inventory repo template or use an existing inventory repo that you share between toolchains.

By default, the inventory repo template is cloned to your Git Repos and Issue Tracking org. To change the org, select Advanced options and specify the repo owner.

Securely store secrets

Several tools within this toolchain require secrets, such as an IBM Cloud API key. You must securely store all secrets in a secrets vault and reference them as required by the toolchain.

Using IBM Cloud, you can choose from various secrets management and data protection offerings that help you to protect your sensitive data and centralize your secret. In the Secrets step, you can specify which secret vault integrations to add or remove from your toolchain. For more information about adding and removing vault integrations, including prerequisites and by using hints, see Managing IBM Cloud secrets.

By using hints within a template, a toolchain is automatically populated with preconfigured secrets; you don't need to manually select secrets from vault integrations that are attached to the toolchain.

This tutorial uses the IBM Secrets Manager as the secrets vault.

IBM Secrets Manager securely stores and applies secrets such as API keys, Image Signature, or HashiCorp credentials that are part of your toolchain.

For more information about managing your secrets in IBM Key Protect or HashiCorp, see IBM Key Protect or HashiCorp.

Explore the pipelines

You can explore the pipelines to understand the toolchain flow and the different operations that run within each pipeline. The toolchain that you just created contains three pipelines:

• Pull request pipeline: Runs when a developer merges changes from their development branch to the master branch, or to any other branch in the repo. The pull request pipeline runs the Unit Test and Static Scans on the Application Source Code.
• Continuous integration pipeline: Runs when you merge a change into the master branch of the Application Source Code repo. The continuous integration pipeline runs the Unit Test, Code Coverage, and Static Scans on the Application Source Code, CIS check, and Bill Of Materials (BOM) check. The continuous delivery pipeline also generates the binary build artifacts and uploads them to the IBM Cloud® Kubernetes Service, as configured in the toolchain. And the continuous integration pipeline generates the metadata of the build artifacts and stores it in the Inventory repo.
• Continuous deployment pipeline: Deploys build artifacts to the deployment environment. The pipeline verifies the successful deployment of the app by running the health check. You must manually trigger this pipeline after the continuous integration pipeline successfully completes. Depending on the deployment strategy that you selected, more triggers are added to the continuous delivery pipeline.

Run the pull request and continuous integration pipelines

To start the pull request pipeline, create a merge request in your app repo:

1. On the Toolchain's Overview page, on the Repositories card, click the compliance-app-<timestamp> app repo.
2. From the master repo, create a branch.
3. Update some code in the sample node app or readme file and save these changes.
4. Submit the merge request.
5. On the Toolchain's Overview page, on the Repositories card, click the pr-pipeline repo to start the pull request pipeline. The corresponding merge request in your app repo remains in the pending state until all of the stages of the pull request pipeline successfully complete.
6. After the pull request pipeline run succeeds, you can select it to explore the completed steps.

To start the continuous integration pipeline, merge the continuous integration merge request in your app repo:

1. Go to the merge request.
2. Merge the request so that your changes are copied to the master branch of your app repo. The continuous integration pipeline is automatically triggered.
3. On the continuous integration Toolchain Overview page, on the Repositories card, click the ci-pipeline repo to start the continuous integration pipeline.
4. After the continuous integration pipeline run succeeds, you can click the pipeline run to explore the completed steps.

Explore the continuous delivery pipeline

The pull request and continuous integration pipelines are common across all of the deployment strategies. The continuous delivery pipeline design and implementation changes are based on the deployment strategy that you previously selected in this tutorial.

You can start a continuous delivery pipeline in either of the following ways:

• Trigger the continuous delivery pipeline manually.
• Automatically trigger the continuous delivery pipeline after each Merge action in the Inventory repo. After the merge, you must manually trigger the continuous deliver pipeline run.

A Git Repos and Issue Tracking trigger is set up to trigger an automatic continuous delivery pipeline, but it is disabled by default. You can enable this trigger after the first time that you promote a change.