This topic tells you how to use Tanzu Build Service (commonly known as TBS) in a continuous integration context to build applications and keep them up-to-date at scale.

Example: Using Tanzu Build Service in CI/CD

Diagram of an example CI workflow. This topic describes this example in full.

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 diagram is described in the following text.

    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:

    This diagram is described in the following text.

    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:

    This diagram is described in the following text.

    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:

    This diagram is described in the following text.

    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>

    or

    kp build status <image-name> -b <build-number>

  5. Using CI/CD, deploy the built image to a Dev/QA Kubernetes cluster:

    This diagram is described in the following text.

    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:

    This diagram is described in the following text.

    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:

    This diagram is described in the following text.

    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