Harness GitOps PR pipelines basics

This topic introduces you to Harness PR pipelines, which provides a first-class support for modifying existing GitOps Applications, especially for those that are generated by ApplicationSets using the Git Generator.

Often, even though your ApplicationSet syncs one microservice/application to multiple target environments, you might want to change a microservice in just one of the target environments, such as a dev environment. A Harness PR Pipeline enables you to do this.

Important

This topic builds on the ApplicationSet concept discussed in Harness GitOps ApplicationSets. Please review that topic before learning about PR pipeline basics.

A typical GitOps Application syncs a source manifest to a destination cluster. If you have multiple target clusters, you could create separate GitOps Applications for each one, but that makes management more challenging. Also, what if you want to sync an application with 100s of target clusters? Managing 100s of GitOps Applications is not acceptable.

To solve this use case, Harness supports ApplicationSets.

ApplicationSets: A Quick Recap

An ApplicationSet can be thought of as a kind of Application factory. It defines one application template and syncs it to multiple target environments. It is similar to an Application but uses a template to achieve application automation with multiple target environments.

You can add an ApplicationSet manifest to a Harness GitOps Application just like you would add a typical deployment manifest. At runtime, Harness uses the ApplicationSet to deploy the applications generated by the common template to all the target environments' clusters.

ApplicationSets use generators to generate parameters that are substituted into the template: section of the ApplicationSet resource during template rendering.

There are many types of generators, and Harness provides first-class support for the Git Generator with the Update Release Repo, Merge PR, and Revert PR steps in the PR pipeline.

For more information on other Generators, please refer to Generators from Argo CD docs.

Git Generator

At its core, ArgoCD's Git generator allows for dynamic creation of ArgoCD Application resources from templates using parameters sourced from a Git repository. This functionality enables applications to be defined once in a template and instantiated multiple times with different configurations. The Git generator ensures version control and traceability by pulling environment or application-specific configurations directly from a Git repository.

While the Git generator supports various methods, one of its standout features is the file-oriented approach, specifically using config.json files.

Benefits of using a Git Generator

• Arbitrary Key Updates: With the file version of the Git generator, users can define key-value pairs in config.json that directly overrides or supplements values in the target application's configuration. This provides unparalleled flexibility in updating configurations on-the-fly without altering the core template.
• Decoupling Configuration from Template: By using a separate config.json for overrides, the core application template remains untouched. This separation ensures that base configurations are consistent, reducing errors and ensuring that changes are traceable to specific configuration files.
• Version Control and Auditability: Since configurations are stored in Git, every change to config.json is versioned. This provides a clear audit trail, making it easy to track when a configuration change was made and by whom.
• Dynamic Application Generation: The Git generator, especially with config.json files, allows for the dynamic creation of applications based on varying configurations. For instance, one could have a base template for a microservice but instantiate it differently for development, staging, and production environments using different config.json files.
• Centralized Management: Storing all config.json files in a single Git repository or organized structure ensures centralized management. Teams can collaboratively update configurations, propose changes through pull requests, and review configurations collectively.

Harness PR Pipelines

Harness PR Pipelines allow you to manage the configuration of individual applications created by the ApplicationSet. The key differentiator between various config files for the ApplicationSet is the folder structure, which would usually differentiate based on the environment in Harness.

When you deploy a Harness PR Pipeline, you simply indicate what target environment application you want to update and the config.json keys/values you want changed, such as release tags. Harness creates the pull request in your Git repo and merges it for you. Now, the target environment application has the new keys/values, which can then be reviewed and deployed by syncing the ApplicationSet.

note

To create PR pipelines in Harness, please refer to Create Harness GitOps PR pipelines.

Wave deployments

You often hear the term wave deployments used when PR Pipelines are discussed.

A wave deployment is a deployment strategy in Continuous Delivery that involves releasing changes to a portion of users at a time, rather than all users at once. Typically, this is done using separate cloud regions for each target environment.

Wave deployments help reduce the risk of deployment failures and allow for quick recovery. The changes are rolled out in waves, typically starting with a group of users in one region and gradually expanding to the entire user base across all regions. This approach allows for a more controlled and monitored rollout of changes, improving the overall quality and stability of the deployment process.

With Harness GitOps, you can implement wave deployments by creating multiple environments for your application: one environment for each cloud region. Then, gradually promote changes from one environment to the next. This way, you can test changes in a safe and controlled manner before releasing them to the entire user base.

PR Pipelines support the wave deployments practice by allowing you to change a microservice in each target environment as needed.