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 choose the tickets for my feature. I select my ticket system in Provider, then narrow the list with the filters or type in Search for a ticket. My own tickets show under Tickets assigned to me. (You can select up to 10 tickets from the same ticket system), then I click Continue.
You can't select a ticket until you enable ticket tracking in your pipeline's settings. Gearset Pipelines works with Jira issues, Azure DevOps work items, Salesforce tickets, and Linear issues, and you select and link them all the same way.
To make sure your team always links a ticket, turn on Require issue tracking in the Deployment settings on your My account page. Each pull request and Compare and Deploy deployment then needs a linked ticket. When you create a feature, Skip to creating a branch is hidden, and you can't continue without a ticket. This setting currently works for Jira issues, Azure DevOps work items, and Asana tasks. Asana tasks are available in Compare and Deploy only.
Gearset names the new branch from the selected tickets, using the feature branch format in our pipeline settings. If needed, I can edit the branch name to follow our naming conventions.
The selected tickets show under Tickets. I can remove a ticket with its x, or click Choose different ticket(s) to go back to the ticket list.
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 UAT 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.