This topic describes how to best leverage Tanzu Build Service in a continuous integration context to build applications and keep them up to date at scale.

Using Tanzu Build Service in CI/CD

This example shows using an image resource with Git source in a development-to-production continuous integration/continuous delivery (CI/CD) pipeline flow.

Let's split this up into each step.

  1. Run unit tests & merge to branch:

    This step shows a typical initial unit testing CI flow.

    1. Developer pushes code to feature branch.
    2. CI/CD runs unit tests on that branch.
    3. Once tests have passed, the feature branch is merged to release branch (Git Branch A).
  2. Update Tanzu Build Service Image Configuration in CI/CD:

    After unit tests pass, CI/CD must tell Tanzu Build Service to build the registry image using the Git commit that passed tests.

    For example:

    Jenkins job that runs the following after unit tests with the successful <git-commit>:

    kp image save my-image --git-revision <git-commit>
  3. Tanzu Build Service builds the OCI registry image using the Git commit:

    Here Tanzu Build Service works its magic and builds a new registry image using the Git commit set in the previous step and the latest app dependencies (stacks and buildpacks).

  4. Tanzu Build Service pushes the built image to your registry:

    After the build finishes, Tanzu Build Service writes the resulting image to a container registry such as Harbor.

    This image reference can be found with:

    kp image status <image-name>


    kp build status <image-name> -b <build-number>
  5. Using CI/CD, deploy the built image to a Dev/QA Kubernetes cluster:

    Now that the image is available in your registry, it can be deployed to any Kubernetes cluster. In this example, it is deployed to a Dev cluster for acceptance testing and QA/manual approval.

    There are a couple of ways to trigger this job:

    • Using registry webhooks (such as Harbor's) to trigger a CI/CD job.
    • If you are using Concourse CI: the Concourse kpack Resource.
    • Write your own polling mechanism to check for new images in your registry.
  6. Once the app has been vetted, deploy to production:

    The same way the image was deployed to the Dev cluster, the image can be pushed to production.

  7. Bonus: dependencies are kept up to date for secure app images:

    Images are kept up to date with the latest dependencies provided through stacks and buildpacks from the Cloud Native Buildpacks community, which are released for Tanzu Build Service as Tanzu Buildpacks on Tanzu Network.

    As of Tanzu Build Service 1.2, these dependencies are automatically updated. You can also update these dependencies with the kp cli in CI/CD by running:

    kp import -f descriptor.yaml

When dependencies are updated, affected apps are rebuilt to be promoted by using steps 5 and 6.

check-circle-line exclamation-circle-line close-line
Scroll to top icon