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
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:
Promoting a change through your pipeline
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:
merge the pull request to take the feature into the next git branch (i.e. the
int
branch)start the CI job to deploy this feature into the next org (i.e. the INT org), indicated by the spinning circle
open a pull request of this feature against the next environment (i.e. the UAT environment) in the pipeline.
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.
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 tomain
, thenback propagate the feature from
main
touat
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.
Using JIRA with pipelines
Using JIRA with pipelines
If we want to associate each promotion of changes with a Jira ticket, Gearset can attach comments to the selected Jira ticket to update your ticket tracking software.
We can also update the status of a Jira ticket, details on how to configure this can be found here.
Using Azure Boards with pipelines
Using Azure Boards with pipelines
If we want to associate each promotion of changes with a Azure DevOps Work Item, Gearset can attach comments to the selected Azure item to update your ticket tracking software.
We can also update the status of a Azure item, details on how to configure this can be found here.