Configuration as Code

Configuration As Code allows you to configure Pipelines, Triggers, Workflows, Environments, and Services in Harness using YAML. Nearly everything you can do in the Harness platform GUI, you can do in YAML as well.

In an enterprise, you might have hundreds of apps and teams. In such a case, defining all your deployment Pipelines and configurations using Harness GUI can be time-consuming and difficult to use.

Configuration as Code provides the ability to define the whole configuration using YAML syntax. This approach provides the following major benefits:

  • Automation and Consistency (templates)
  • Version Control
  • Scalability
  • Traceability

Using the Harness code editor, you can set up and manage accounts for artifact servers, cloud providers, and verification providers. You can edit Application services, Environments, Workflows, etc. all in YAML. You can sync your Git repo with Harness to simply use YAML files in your source repo to make changes to Harness.

Here is the same Harness Workflow in the Harness GUI, Harness code editor, and a Git repo.

In this topic:

Before You Begin

Sync Scenarios Overview

Here is a visual summary of Git to Harness sync:

Here is a visual summary of Harness to Git sync:

The following table provides an overview of the sync scenarios and how to configure them.

Sync Scenario

Configuration

Sync one-way (unidirectionally) from Harness to your Git repo.

Set up a Source Repo Provider with your repo and do not enable the Generate Webhook URL option or apply the Webhook to the Git repo.

Select this Source Repo Provider for all applications that you want to sync unidirectionally.

Sync two-way (bidirectionally) between Harness and your Git repo.

Set up a Source Repo Provider with your repo and apply the Webhook created by the Generate Webhook URL option to the Git repo.

Ensure that the Content type in your repo Webhook is set to application/json. By default, some repos are set to application/x-www-form-urlencoded.

Select this Source Repo Provider for all applications that you want to sync bidirectionally.

Stop syncing an application with a Git repo, but keep the Source Repo Provider connected for future syncs.

In the Git Sync setting for the application, turn off the Enable/Disable setting. Later, when you want to start syncing again, turn on the Enable/Disable setting.

Stop using a Source Repo provider with an application.

In the Git Sync setting for the application, click DELINK.

Have the Source Repo Provider sync bidirectionally with the Git repo, but have an application using that Source Repo Provider only sync unidirectionally.

This is not available.

Repo and brach names may not contain characters from the Emoticons unicode block.

Rapid Development with Harness and Git

One of the advantages with Harness Git integration is the ability to clone or duplicate a Harness Application entity quickly in the Git repo, and then have the cloned entity show up in the Harness platform. For example, you can clone a Harness Environment in the Harness GUI using the Clone button.

But if you wish to make several copies, this can be time-consuming in the GUI.

With Harness GitOps, you can simply duplicate the environment folder in Git, give the duplicate folder a unique name, and push it to the origin. The new environment will appear in Harness. For more information, see Harness GitOps.

Using RBAC for YAML Files

You can manage user and group permissions for the YAML files using the RBAC settings.

  • The YAML file for Application-level entities is controlled by user group permissions.
  • The YAML file for an account-level entity is controlled by the usage scope.

For more information on how to manage RBAC, see Managing Users and Groups (RBAC).

Next Steps


How did we do?