This document will run through how to get your first features from your dev sandbox into your pipeline and then get those features through your pipeline environments.

Promoting work from a dev sandbox into your pipeline is easily done through Gearset. While you can manually compare and deploy from your dev org to your source branch, we helpfully provide this functionality within the Pipelines UI.

We’ve created a custom field within our dev org that looks like this:

In the deployment pipelines view, we can click on the dev sandbox environment. This is the blue environment that we set up in the previous step.

This will open the following window, where you will be able to create your feature branch. Click + Create new branch from main and create a new feature branch.

If you are using Jira or Azure Work Items then we recommend including the ticket ID in your branch name. In this example my Jira ticket is AL-100.

Click Create branch.

Once you have created your branch click on the Compare and commit option within the sidebar view:

This will start a comparison between the dev sandbox org and our new feature branch and allow us to choose the new custom field to commit:

After you have selected your custom field, click next - this will take you through to the Problem Analysis stage. Here you can review the Problem Analyzers, Warnings, Code Analysis and Environment Variables.

After you have reviewed these click Pre-deployment summary.

On this screen you can review your changes, add a commit message, and connect your Jira ticket, Azure Work Item or Asana task.

Once you've made any notes, you can click Commit changes.

Once the commit to the feature branch is complete, click View in Pipelines to return to the Pipelines view.

Once you have returned to the Pipelines view, click on your dev sandbox again to see all of the components you've added to your feature branch so far. You can continue to run comparisons and add components to your feature branch, or you can move on to the next step.

We’ve now successfully committed the feature from the dev sandbox environment to the feature branch, and are ready to target our first environment, i.e. the INT environment.

Click Create pull request in the pipeline environment view to start the feature’s journey through the pipeline:

You can see the target environment is pre-populated with the next integration (INT) environment:

Once this pull request is open, the pipeline view is updated with the indication that a new feature is ready for promotion into the next environment:

Once a pull request is open and displayed in front of an environment, we can select the environment to see the pull request and feature ready for promotion:

We can select the pull request (or multiple pull requests) and click Promote changes to promote into each of the subsequent environments in the pipeline:

Clicking the Promote changes button will then start the CI job on the Gearset side, to:

When the CI job to promote the feature into the INT org is complete, this is what we’ll see:

You can now continue to move the changes down the pipeline and towards production.

If your first feature is starting not in a dev sandbox, but in a static environment, you can promote as well. Imagine the scenario where you have a hotfix feature in this pipeline; you can promote the feature from

In your git provider, start by creating a pull request targeting the static environment branch (from hotfix_feature_1 to hotfix branch).

Gearset will close the PR and create a promotion PR (from gs-pipeline/hotfix_feature_1_-_hotfix to hotfix).

In the pipeline UI, this will be shown as a feature before the hotfix static environment, which you can promote into the next environment.

Once it is promoted you should see a icon in front of the main environment to merge into the main branch.

Once you promote the feature into main you will see a back-propagation icon to move the feature backwards into the uat environment.

That's how you can promote a feature from a static environment and subsequently back propagate it to other environments in the pipeline.