All Collections
Gearset Pipelines
Getting Started
Setting up your first Gearset Pipeline
Setting up your first Gearset Pipeline

Create your first Pipeline: A guided walk-through the Pipeline settings

Valerio Chang avatar
Written by Valerio Chang
Updated over a week ago

This article will run through the steps to set up a Pipeline in Gearset.

Note: For Gearset’s pipelines to work as expected, make sure to set the branch synced to prod (in this example main) as the Default base branch for new feature branches.

To set up a Gearset Pipeline, first go to the side menu on the top left corner in our app, and select Continuous integration:

From there you will be taken into the Continuous Integration dashboard, where you will need to select the Pipelines icon in the top right corner:

From this screen you click on the blue button Create Pipeline:

Then below pop-up window will appear. Here you will need to fill in the following information:

A quick video to guide you through the process described in the screenshots above:


When creating your Pipeline, the settings you'll need to configure are:

  1. The Name of the pipeline.

  2. The Repository type (GitHub, GitLab, Bitbucket, Azure DevOps etc) as well as the repository that the pipeline will be based on.
    On below example we've selected GitHub because it's the only repository type connected on the Gearset account (that's why it shows up under Connected Git Providers)

    Note: Once a repository is selected, it is locked into your pipeline. Renaming that repository later in Git will not be recognized and you will need to recreate the pipeline from scratch.

  3. The Default branch for new feature branches. Gearset recommends using Main as the default branch, so that features are always created from a copy of your Production org. This is because Gearset uses the pipelines branching model.

  4. Create back propagation pull requests - here you can choose the behaviour of back propagation.

    You have two options to choose from:

    1. Only when changes are promoted into the final environment

    2. When changes are promoted into any adjacent environment

  5. Run validations on final environment: You can configure validations on final static environments to run automatically for releases only, or for both releases and individual feature pull requests (which essentially means: for all pull requests).

    1. Note: If the Validate pull requests targeting the source branch setting (screenshot below) on a static environment is unticked, then no automatic validations will be ran for that environment no matter which option is selected for your Pipeline setting: Run validations on final environment.

  6. Choose whether or not to automatically delete feature branches.
    Note: This option will automatically delete all feature branches that no longer have any pull requests coming from them.

  7. As a Pipeline owner you can choose whether to Require pull request descriptions for all the PRs (pull requests) created in the Pipeline by other team members.

  8. Choose whether or not the Pipeline can only be edited by the owner, or any user in the team (if you leave the option unticked).
    Note: Functionality of this setting depends on whether it's a team-shared Pipeline or not. This setting only applies to user-owned Pipelines that have an individual owner.
    Team-shared Pipelines are by default owned by the team, and not by an individual owner. Find out more about team-shared Pipelines.

Once you have configure all the above settings and selected Save, which would created the Pipeline, in the next step Gearset will ask you to set up a webhook.

It is recommended to click the Add webhook button and Gearset will automatically create the webhook for you:

After selecting Add webhook, Gearset would notify you once the webhook is set up correctly:

You can also manually set up a webhook by following the instructions in the dropdown menu.
In this example we can see the instruction for webhook set up in GitHub):

Setting up your first Static Environments

Within Gearset pipelines, a static environment is the continuous integration job that is running from the long lived branch (also referred to as an 'environment branch') to the org, syncing those features into your org.

Once this setup has been completed, then on the dropdown menu in the top left corner you can see your, currently empty, user-owned Pipeline (blue arrow on image below). And you can proceed to create your fist environment.

To do so, select Create environment...

You will then be able to create a new environment from scratch. To do so, select Create new environment/job:

Hitting this button will take you to our Continuous Integration (CI) job wizard, where you will be able to easily create CI jobs.
Find out more about how to set up your first CI job in Gearset - this article will lead you through the set up and job configuration settings.

Once the first CI job has been created, new jobs can be created by clicking the Add environment button in the top right corner of the screen, and then selecting Add static environment:

In this example CI jobs for INT, UAT, Hotfix and Prod will be created (these are your static environments with long-lived Git branches):

Currently, there are no links between these environments. We will add those links later.

Adding Developer Sandboxes

Next, we will add developer sandboxes into the Pipeline (if needed).

You can add these by clicking the Add environment button and selecting Add developer sandbox:

You will be given a new wizard, here you need to:

  1. Name this sandbox environment.

  2. Check that the Git provider and source repository are correct.

  3. Choose whether you want to enable back propagation (we do not recommend having this enabled on the dev sandboxes - we explain why in the referenced article).

  4. Choose which sandbox you want to use.

In this example 2 developer sandboxes (Dev1 and Dev2) have been added. We now have 4 static environments (CI jobs) + 2 Dev environments:

Linking Environments together to form the pipeline

To turn these environments into a pipeline, on your Deployment pipelines page use the Edit environments button and link the environments using Gearset’s simple drag and drop system:

Once you've connected all the environment and designed your Pipeline, select Save changes:

On clicking Save changes, Gearset will automatically arrange the pipeline display in the order of flow from left to right and you can begin to use it to push new exciting features to your users.

Setting up Jira/Azure work items

To be able to use the pipeline to its full potential, we recommend adding in a ticketing system. Within the pipeline we support Jira and Azure work items. We have documents outlining how to set up these connections to automatically update ticket status when reaching certain environments.

For more information, check the following articles:

Now that you’ve set up a pipeline, the next document in the series will show you how to promote changes through this pipeline:

Did this answer your question?