Skip to main contentIBM Garage Event-Driven Reference Architecture - Reefer Container Shipment reference implementation

Continuous Delivery

The implemented DevOps pipelines for the Reefer Container Shipment solution reference implementation of the Event-Driven Reference Architecture. This chapter focuses on the Continuous Delivery capability implemented in the reference implementation.


Our Continuous Integration (CI) approach is one of “zero-infrastructure overhead”. To accomplish this goal, we utilize GitHub Actions to build and push a microservice’s associated container images to Docker Hub for public consumption. The GitHub Actions workflows are defined in the owning repository’s .github/workflows/dockerbuild.yaml file.

Our GitOps approach focuses on a single-repository, environment-per-subdirectory model which can be forked and cloned to replicate deployments to other clusters and environments. The reference implementation utilizes Kustomize as its templating technology to utilize the app-deploy.yaml files, provided by each individual microservice, as a base and then layer in environment-specific configuration and credentials as needed.

Our Continuous Delivery (CD) approach, the topic of this chapter, focuses on a GitOps-based delivery model, using a GitHub repository as a single source of truth for the deployment, management, and operations of our running application components. In this model, we have the flexibility to use multiple open-source technologies to apply the single source of truth from a given GitHub repository onto a desired cluster environment.

Continuous delivery

One of the main tools used in this space is a GitOps-focused continuous delivery project named ArgoCD. As documented by the IBM Garage for Cloud team, ArgoCD can monitor GitHub-based projects and apply changes stored in that repository’s YAML files to a running Kubernetes-based cluster.

We have documented our general GitOps strategy & methodology for generation of deployment source configuration files in the GitOps chapter of this manual, while the details of our ArgoCD-based deployments of those GitOps-based artifacts are covered in the ArgoCD deployments section below.

ArgoCD deployments

Our main continuous delivery pattern operates on the same principle of “zero-infrastructure overhead” as our continuous integration implementations. This allows us to be agile, adaptable, and efficient in what we deploy where. ArgoCD is a perfect companion to this principle, as we do not need additional long-running CD infrastructure to monitor either a source environment or a target deployment environment. Our CI process sits with our code (on the same hosted infrastructure), while our CD process sits with the target deployment environment (on the same Kubernetes-based cluster).

Argo CD

To utilize ArgoCD in this manner, we leverage the Appsody-based, Kustomize-extended Kubernetes YAML files that define the necessary AppsodyApplication and OpenLibertyApplication custom resources our application’s microservices require. ArgoCD will handle deploying the entirety of a single environment subdirectory, as defined in the GitOps repository. For details on how the environments subdirectory and its component files are structured, refer to the peer GitOps Environments chapter of this manual.

An ArgoCD application is created on the ArgoCD server inside the target environment that can read from the GitOps repository. ArgoCD can also deploy between clusters, which does come in handy in certain use cases, but remember our squad’s goal of “zero-infrastructure overhead”, so we deploy from ArgoCD into the same cluster it is deployed on the majority of the time. The ArgoCD application is a Custom Resource Definition, comprising of the details necessary to determine the remote code repository URL, the branch of the code to use, the target namespace, and any formatting capabilities that are necessary.

Argo CD - Application Topology

ArgoCD then handles automatically (or manually) syncing and applying the deployments into the target namespace with the state that is described in the Kustomized YAMLs from the desired environment’s subdirectory in the remote GitOps repository.

Deploying a microservice with ArgoCD


  1. Ensure all necessary Kubernetes ConfigMaps and Secrets have been created in the namespace in which the application will be running. This may vary depending upon your level of exposure to the public Internet, as well as cluster tenancy.
  2. Ensure ArgoCD has been deployed to the local cluster with connectivity to the Internet. Reference: ArgoCD Operator Documentation

Using the ArgoCD dashboard

Argo CD - Create Application
  1. Access the ArgoCD Dashboard via it’s exposed Route in the argocd namespace. This should be in the form of https://argocd-server-[namespace].apps.[cluster-based-route].
  2. Depending upon your cluster and ArgoCD, you will have specific login credentials. Login as directed and click NEW APPLICATION.
  3. Enter the following parameters for the dev environment of the reference implementation and click CREATE.
    • Application Name: refarch-kc-dev
    • Project: Select default from the drop-down
    • Sync Policy: Select Automatic from the drop-down
    • Repository URL:
    • Path: environments/dev
    • Cluster: Select in-cluster (https://kubernetes.default.svc) (this is our local cluster)
    • Namespace: Your desired target namespace
    • Click the Directory section label and select Kustomize
  4. Once the application is successfully created inside ArgoCD, you can click the application tile to see the latest status of the ArgoCD-managed, GitOps-deployed microservice instances. It should begin synchronizing immediately upon creation.
  5. As ArgoCD applies the desired configuration to the cluster, you should see the pods of the microservices being created:
kubectl get Pods

Using the command-line interface

ArgoCD provides a command-line interface as well, however we are not covering that in this reference implementation. Once you are satisfied with the ArgoCD dashboard-based deployment pattern, you can reference the ArgoCD Getting Started docs for further details on using the ArgoCD CLI and CRD YAMLs for programmatic interaction.

Next steps

Once your ArgoCD-deployed application instances are deployed, synchronized, and running, you are ready to run the Integration Tests to validate your environment!