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.

Once you have completed the feature in a Dev Sandbox, go to your Dev sandbox in the pipeline and select + New feature.

If you have Jira or Azure work items linked then you can select a ticket.

Gearset will automatically fill in the name of the feature branch, you can edit this to fit any naming convention needed.

If you have no ticketing system linked then you can then you create and name the branch. Here you can change the metadata filter and then start the comparison between the org and the branch.

In the comparison find the feature that you have created and go through the compare and deploy steps.

Commit those changes to the feature branch using the commit changes button.

The changes are now in the feature branch and you will be taken back to the pipeline screen.

Here you (1) can see the changes in the branch (2)the commits in this branch and (3) you can also commit more changes into the feature branch

Once you are happy with the changes in the feature branch you can create a pull request to the next environment in the pipeline.

A popup will appear next, here you can choose a template (if applicable) (1), and then fill in a description of the changes that have been made (2). Once that has been filled in you can Create pull request and see it appears in the next environment.

Important to note: The Description for your PR is a mandatory field that needs to be filled in before Pipelines UI allows you to select Create pull request.

Click on the PR button and you can see it auto populate on the side bar.

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:

Once the CI job has successfully completed, you can see that the CI job will go from blue to green.

You can now continue to move the changes down the pipeline and towards/into 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 an 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.