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.

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.

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).

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.

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.

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.

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