Promoting your first features

Getting your features from your dev sandbox into Gearset Pipelines and getting them propagated through your environments.

Quinn Kuiper avatar
Written by Quinn Kuiper
Updated over a week ago

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 features from a dev sandbox

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.


PR description

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.

Promoting a change through your pipeline

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

  1. You can see the name of the branch that the PR is coming from.

  2. You can see if there are any merge conflicts between the branches

  3. You can see if the pull request has been validated against the target org. With options to view the validation details as well as re-running the validation.

  4. If you have any other checks running on PRs you can see them here.

  5. You can see the assigned reviewers of the PR

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:

  • Merge the pull request to take the feature into the next environment branch (i.e. the UAT branch in this case).

  • Start the CI job to deploy this feature into the next org (i.e. the UAT org in this case), indicated by the spinning circle.

  • Open a pull request of this feature against the next environment (i.e. the Main branch in this case) in the pipeline.

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.

Promoting features from a static environment

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:

  • Hotfix environment to main, then

  • Back propagate the feature from main to UAT

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.

Using JIRA with pipelines

Jira integrates seamlessly with pipelines.

When creating a new feature, you can select a ticket that will be linked to the feature in the pipeline. Following on all promotions until it has reached the final environment.

Gearset can also update the status of a Jira ticket, details on how to configure this can be found here.

Using Azure work items with pipelines

Azure work items integrates seamlessly with pipelines.

When creating a new feature, you can select a ticket that will be linked to the feature in the pipeline. Following on all promotions until it has reached the final environment. We can also update the status of a Azure item, details on how to configure this can be found here.

Did this answer your question?