You can use a pipeline to build the application and Docker image from source in a Git repository, publish the image to a Docker registry, run tests, and deploy your application to a Kubernetes-based cluster. By configuring webhooks on your Git repository, your pipeline can be automatically triggered based on certain Git repository events, such as on pushes to the branch or on the creation of pull requests.
To use the pipeline, install Microclimate onto an IBM Cloud Private cluster, or connect a local installation of Microclimate to an installation of Microclimate on an IBM Cloud Private cluster.
Jenkins provides the pipeline capability only when Microclimate is deployed onto IBM Cloud Private by way of the Microclimate Helm chart. The installation instructions for the chart include specifying the Docker registry that the pipeline uses for images, any credentials required to access that registry, and the namespace that the pipeline uses to deploy applications to. Unlike an individual’s Microclimate development workspace, pipeline instances are shared among all users of the Microclimate installation.
Video: Creating a pipeline
Follow these steps to create a pipeline:
.gitsuffix. If you previously imported the repository, this URL might be the same as the one that you used on the import, or it might be the URL of the upstream repository from which you forked.
Video: Pipeline deployments
You can create a pipeline outside of a local project. Instead of creating or cloning a project locally, you can create a pipeline for a project in a Git repository.
After you set up a pipeline to build the application and Docker image, you can deploy applications:
In both cases, the default behavior is to deploy to the target namespace that was specified when Microclimate was installed on the IBM Cloud Private cluster to which Microclimate is deployed. If deploying to IBM Cloud Private, you can modify the target namespace at the point of adding your deployment.
A specific build can also be targeted for deployment to a cluster that is running in the IBM Cloud Kubernetes Service. In this case, you cannot modify the target namespace of your deployment.
These two scenarios can be combined. For example, a branch can be automatically deployed to a testing environment in IBM Cloud Private and then manually promoted to a cluster in the IBM Cloud Kubernetes Service. For more information, see Configuring Microclimate to deploy applications to the IBM Cloud Kubernetes Service.
falsein your Jenkinsfile.
The status of releases is dynamically updated in Microclimate. After a deployment is created, you can see the release status, which includes No build information, Building, Build failed, and Deployment successful.
When you add deployments, you can specify chart override values in the
Create these files in your Git repository on the branch for which you are creating a deployment. Replace the
<target-namespace> variable with the name of the namespace into which your application is deployed. The version of the files that is used is the version that exists at the specific commit level that is deployed.
overrides.yaml file is applied to all deployments, but the
<target-namespace>_overrides.yaml file affects only deployments in the matching namespace. Including these files in the Git repository indicates that you want Microclimate to apply the override.
The settings take effect in the following order:
Any entries that are found in the relevant
<target-namespace>_overrides.yaml file are used in preference to similar entries in the
You cannot override the image repository and tag, which are handled by Microclimate and cannot be modified.
Helm charts can contain resources with names that aren’t scoped by the Helm release, such as the Kubernetes services in Helm charts generated by Microclimate. These Helm charts can be deployed only once to any particular cluster namespace.
Note: Deleting the deployment for a specific build also deletes the corresponding Helm release, allowing another deployment to be made to the same namespace.
Deleting a pipeline deletes all of your deployments that are associated with that pipeline.
Deleting a project does not delete the pipeline. Pipelines are shared by projects that target the same Git repository. If you want to delete the pipeline, you must do so before you delete the project. If you accidentally delete a project before you delete a pipeline, you can reimport the project, delete the pipeline, and then delete the project.
If you encounter problems with using a pipeline, check the Troubleshooting page.