Skip to main content
All CollectionsAutomationPipelinesGetting started with Gearset Pipelines
Starting with your user story and creating feature branches in Pipelines
Starting with your user story and creating feature branches in Pipelines

This article describes how to use pipelines and start your work with a user story.

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

This document will walk through the steps of promoting a feature through a pipeline, starting from a ticketing software.

Creating the feature

In this example I'm using Jira as my ticketing software and GitHub as my version control system (VCS), however, you could use any of our supported VCS or ticketing tools.

We can see in our ticket that we need to create a new Permission Set, to give our users permissions to a custom field named Called on the Account object.

In our Dev Sandbox, we create this Permission Set with all the correct changes.

Now in Gearset, I go to my pipeline and click on my personal Dev sandbox environment, and click + New feature.

Next, I find the ticket that was linked to my current feature that I have been working on. Gearset will automatically name the newly created branch based on the Jira ticket. If needed I can edit the branch name to follow naming conventions.

Note: You will not be able to select a Jira Issue if you have not enabled the Jira Integration in your pipeline's settings.

Alternatively, you could create a feature branch via the Compare & deploy page by selecting the option to Create new branch from main, then name your new feature branch, and confirm by selecting Create branch:


Next I hit Compare now and the comparison window will be generated and in the comparison grid we select the changes that are needed.

I’ll go through the next steps and check that the changes are expected. Then I click Commit changes.

Once this is done, the change is successfully in the feature branch and can be moved to the next environment in the pipeline.

Promoting the change to the next environment

Now that the change is in the newly created feature branch, I’ll Create the pull request to the next environment.

I’ll fill in the description of the PR based on what my team needs and what is contained in the pull request (PR) then click Create pull request.

I’ll click the next environment in the pipeline, select my PR, checking to see if there are any merge conflicts and if it has been validated correctly.

Here I can also check the validation to see if all the changes are there as expected.

If it has all been validated successfully and all the checks are complete then we can click the PR and select promote changes.

Once it has been successfully promoted, Gearset will run the CI job, pushing those changes from the branch into the org.

Now it's in the INT org, I can see that the PR has been automatically created to the next environment, ready to be promoted when it's ready to go.

Note: If multiple PR’s are ready, you can select them all at once and promote them in one go.

I have now pushed my changes through the orgs, starting with my user story.

Once the feature has made it all the way to production, to keep all of the branches in sync. I'll hit the sync branches button on all the environments in the pipeline.

Did this answer your question?