When initially setting up a pipeline, one major consideration is in-progress or in-flight work in your org environments. There are a couple of methods to resolve this and this article is to explore each of them, so you can understand which best applies to you.

As an example, lets say that you have three environments in your upcoming pipeline; Dev, UAT, Production. These environments aren't currently in sync, and there are a bunch of user story components at the central environment, UAT. They're yet to make their way to Production and you're curious how these components will be affected after setting up a pipeline.

A Gearset Pipeline is an automated workflow. It's designed to be an end-to-end solution for getting metadata all the way from Dev to Production. Each user story is split into its own feature branch, and promoted through each environment in turn. Considering our example above, if you're mid-sprint, and there are metadata changes at UAT, these won't be segregated into their own feature branches, nor will they be considered by the pipeline.

To add to this, once a pipeline is setup, we'd recommend that no changes happen outside of it (no more org to org deployments), as they would push your environments out of sync with your repository. Due to this, we need to pay careful attention to those user story components and consider how we can incorporate them into the upcoming pipeline.

This is the recommended method for a successful pipeline setup. It effectively removes the need for you to consider in-progress changes as there won't be any remaining. Everything has been released already, and lower environments have been refreshed. So everything is in sync, which is an ideal position for pipeline implementation.

This method isn't recommended as depending on the amount of in-progress work, it can become a significant effort for your team to follow. If you're currently not in a position to follow method 1, our initial suggestion would be to push back your pipeline implementation until you are. But if you're looking to get your pipeline setup, and aren't in any position to wait for method 1 to become available, then you can consider this method.

Essentially, we need to get ourselves into a place where every in-progress feature is contained within a separate feature branch. To that end, you'll need a repository in place in order to follow these steps highlighted below. This document walks you through the creation of a repository, with supplemental information in this document specifically for pipelines.

If you're using a ticketing system to track individual user stories, you should already have a pretty clear picture as to how many features are currently sitting in UAT and what components make up each feature. If you don't, then you'll need to examine your UAT environment and determine this manually. Once you have a good idea about how many features there are and what components make up each feature, you're ready to follow this process:

Now you have a number of feature branches ready with separated user stories. Once you've created your pipeline in Gearset, you should be in a position to open a pull request from each feature branch to your first environment (UAT in our example). The opening of this pull request brings that feature into the pipeline, ready for promotion throughout.

Important to keep in mind:
When opening that PR against the first environment, you may see that your pull request validation contains 0 components. That's because these components originated from that environment or simply already exist there, so there are no differences to deploy. This exercise is to bring the environment branch into sync, and to enter these features into the pipeline for further propagation.

We hope this article helps you to understand the considerations involved with in-progress work, in relation to setting up a pipeline. But if you have any questions, please get in touch via the in-app chat.