Configuration as Code Overview

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 manage Harness User permissions using Account and Application permissions in Harness User Groups.

The same Account and Application permissions apply to both the Harness Manager UI and Configure as Code YAML files.

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

Harness User Group Account Permissions

To manage Configuration as Code, a Harness User must be a member of a User Group with the following Account Permissions enabled:

  • Manage Config as Code
  • Manage Applications

See Managing Users and Groups (RBAC).

Harness Entity YAML Files

Harness entities such as Cloud Providers, Connectors, Delegates, etc, have their own Account Permissions.

These Account Permissions apply equally to the Harness Manager UI and YAML files.

Update a File Using Git and Harness Manager UI at the Same Time

If a Git push and Harness Manager UI change to the same file happen in parallel, the Harness Manager UI change takes precedence over the Git change.

Harness rejects pull requests with timestamps that conflict with updates from its database.

Limitations

  • If you rename a Pipeline in Git and sync that change with Harness, any Triggers using that Pipeline are deleted.
  • If you rename a Workflow in Git and sync that change with Harness, Triggers are maintained because a duplicate that Pipeline are deleted.

Next Steps


How did we do?