Use this article to decide which Salesforce environments to include in your Gearset Pipeline. Your Pipeline can reflect the release process you want your team to follow going forward, rather than your existing process. Consider what each environment contributes and whether every stage is still necessary.
Developer sandbox > QA > UAT > Production
The right structure will vary between teams. What matters is that each environment has a clear purpose.
Start with Production and work backwards
Production is the final destination for changes moving through your Pipeline.
From there, work backwards and ask what needs to happen before a change is ready for Production.
For each shared environment, consider:
What is this environment used for?
What testing or validation happens here?
Who uses it?
Does it provide something the previous stage doesn't?
Does a change need to pass through it before reaching Production?
These questions help you identify which environments form part of your release process.
Implementing a Pipeline can also be a good opportunity to review your existing structure. If two environments perform effectively the same role, consider whether both are still required.
Think about where development starts
Development should begin in individual or shared developer environments, rather than in central testing environments such as QA or UAT. For example:
Developer sandbox > QA > UAT > Production
In this structure, developers build and test their changes in their own developer sandboxes before promoting them into QA. QA then becomes the first shared environment where independently developed changes are brought together and tested alongside one another.
Keeping development out of central environments:
Maintains a clear separation between building changes and validating them.
Keeps shared environments as stages in your release process, rather than places where development work is created directly.
Developer sandboxes can be connected to your Pipeline and assigned to individual team members. For details, see How to add a Developer Sandbox to your Pipeline.
Consider how work will move through your environments
Once you've defined the environments in your Pipeline, consider how you want development work to move through them. Your branching strategy determines how individual features are developed, integrated, tested, and ultimately released to Production. It's worth agreeing on this process before configuring your Pipeline so that the Pipeline reflects how your team intends to work.
Gearset supports the following two branching strategies natively, plus Long term projects for teams that need to manage a separate stream of longer-running work:
The Expanded branching model: designed around feature independence. Each piece of work is developed on its own short-lived feature branch and can progress independently through the environment branches in your Pipeline. Features can be released individually or grouped together later in the process.
Gitflow: designed for teams that integrate work earlier and release on a defined cadence. Feature work is brought together in a long-lived
developbranch, with release branches used to stabilize and test a combined release before it's ultimately merged intomainand deployed to Production.Long term projects: designed for work that needs to remain separate from your day-to-day release process for an extended period. A project acts as a sub-pipeline, with its own environments and workflow, allowing the work to progress independently before feeding back into your main Pipeline when it's ready.
Long term projects are available with Automation Enterprise. For help choosing between long term projects and other supporting workflows, see How to choose between early bundles, release candidates and long-term projects. We recommend discussing your requirements with your Gearset team before finalizing your setup.
Think about your final testing environment
Consider what role the environment immediately before Production plays in your release process. Depending on your team, this environment is one of the following:
A standard UAT environment, where individual features are still being tested and changes to the final release are expected.
A production-like environment, used to validate the complete release before it reaches Production.
If you use a production-like environment for final release testing, release candidates let you group and test the complete release there before promoting it to Production. Release candidates are available with Automation Enterprise. For more information, see Releases and release candidates in Pipelines (expanded branching model).
Before you finalize your Pipeline
You should be able to explain the purpose of every environment in your proposed Pipeline, including:
What happens there?
Who uses it?
What testing or approval takes place?
Why do changes need to pass through it?
Once you're happy with the structure, review Pipeline setup - key prerequisites to make sure your environments, repository, access, and team are ready for implementation.
Any questions?
If you're unsure how your existing environment structure should translate into a Gearset Pipeline, send a message to our support team. They can help you work through your release process and decide on the right structure.