Helm-based GitOps Repository Setup for SmoothGlue Run Deployments

SmoothGlue makes use of Argo CD to allow developers to declaratively create and update their application deployments using the GitOps paradigm. This guide will help developers create and manage a Git repository to store their application's deployment configuration for consumption by Argo CD.

GitOps facilitates continuous deployment of applications by allowing developers to declaratively write the expected state of their application deployments, which Argo CD then reads and executes. This guide focuses on defining the expected state using Helm.

Example Projects

SmoothGlue Cloud users may refer to the java-gradle-example and javascript-npm-example repositories as example projects which have co-located Helm charts within the same repository. These repositories may be cloned or forked to serve as a starting point for users' applications if desired.

For projects that deploy connected applications from multiple repositories, the project's Helm chart should be stored within a dedicated repository separate from existing application repositories.

GitOps Repository Setup

For full-stack applications, SmoothGlue recommends storing the Helm chart within an existing repository under the chart/ top-level directory. Much of the initial boilerplate can created by the helm create command:

# enter the root of the project's repository
cd PROJECT_BASE_DIR
# Helm creates boilerplate using the application's name in a subdirectory
helm create YOUR_APPLICATION_NAME
# rename the created directory to `chart`
mv YOUR_APPLICATION_NAME chart

The completed project should look similar to the following:

chart/
├── templates/
├── values.yaml
├── Chart.yaml
└── README.md
<your project code>
README.md
.gitignore

For microservice applications comprising multiple containers built within SmoothGlue, SmoothGlue recommends splitting the chart into its own repository. Doing so will simplify the development workflow for the chart itself.

For developers new to Helm, refer to the Helm Chart Template Guide for information and best practices on building your Helm chart.

Open Container Initiative Build Artifacts

Regardless of the option selected, if the Pillars of Creation pipeline detects a Helm chart in this directory, it will automatically perform linting for your chart, package your chart into an Open Container Initiative (OCI) artifact, and make the artifact available from the GitLab container registry for consumption during deployment.

An OCI artifact is a standardized format for packaging and distributing content, similar to how Docker images are packaged and distributed. While Docker images are a specific type of OCI artifact used to containerize applications, the OCI artifact specification extends beyond images to support other types of content, such as Helm charts, WASM modules, or even custom-defined objects.

In essence, an OCI artifact is a generic, extensible unit of content stored in an OCI-compliant registry (such as Docker Hub or Azure Container Registry). It uses the same underlying distribution protocol as Docker images, enabling developers to store and retrieve artifacts in a familiar way.

For example:

• A Docker image is an OCI artifact that contains application binaries and dependencies.
• A Helm chart can also be packaged as an OCI artifact for distribution via OCI registries.

This allows developers to use the same tooling and workflows (e.g., docker pull, docker push) to manage various types of content, not just container images.

Tips and Tricks

• Ensure that your Helm chart exposes the image tag as a configurable value.