How to manage long-term projects within your Salesforce CI/CD pipeline

DevOps encourages teams to ship updates in small slices on a regular basis, rather than “big bang” delivery of large sections of development. But this isn’t always possible — sometimes long-term projects need to be kept back and worked on for longer periods of time in a dedicated branch before release.

Long-lived feature branch management doesn’t have to mean a painful release day. In this article we’ll weigh up the pros and cons of long-lived project branches and demonstrate how Gearset makes that process as seamless as possible.

What is a long-lived feature branch?

Continuous integration and continuous delivery (CI/CD) are key to DevOps, with CI promoting the automatic progression of new development along the release pipeline for testing and validation. Meanwhile, CD focuses on automatically deploying work items to later environments once approved and merged. This is a rapid way to get feedback and iterate on new development, delivering value to end users quickly.

If you’re just getting started with version control, or are looking to implement a new Git branching strategy and don’t know where to start, don’t worry. There are lots of resources available to help you decide which branching strategy is right for your team and project.

Generally, it’s best practice to have short-lived feature branches, especially for teams practicing CI/CD. Popular branching strategies include trunk-based development (merging feature branches to a shared “trunk”, usually main) and release branch models (where short-lived branches are merged into a shared release branch before being shipped in regular release cycles).

But what if you have a project that needs to be built and shipped in one large release? A long-lived project branch is one that runs in parallel to the regular, short-lived feature branches that carry small slices of development work. A long-term branch will typically hold an isolated project that needs to be kept separate from BAU development and released in one go or larger sections.

If you’re running a long-term project, ideally you’d only keep the branch open as long as is strictly necessary for the project. The main thing is to prevent the project branch getting wildly out of sync with the main branch of development. Otherwise, you can guarantee a whole set of pains on release day.

Pros of long-lived project branches

While this approach doesn’t follow DevOps principles of shipping small and often, long-lived branches are sometimes necessary and do have advantages in certain scenarios.

• Parallel development. By having isolated development in its own long-lived project branch, it doesn’t hold up other updates that users need. Other work can be merged and released on a much shorter cadence, without getting stuck in the project branch. This means value is still being delivered to end users throughout the project.
• One “big bang” release of a large change. Some changes simply can’t be broken into small slices. For example, if you were changing to a completely new sales process it might not always make sense to ship that update in small slices — users could end up in limbo using both old and new processes that were being incrementally released. Releasing in one go can create a definitive start date for a new way of working, which can also make onboarding more straightforward for users.
• More time for quality control. Keeping the project development in a specific branch for a longer development cycle means it won’t automatically get deployed out in the next release cycle. This gives more time for testing as the development isn’t tied to the release cadence of BAU work — thorough testing is especially crucial for large projects that will change a significant portion of the code-base.

Cons of long-lived project branches

When considering whether a long-lived branch is the right approach for your project, there are challenges to keep in mind during your evaluation too.

• Merge conflicts. The more changes that are contained within a single branch, and the larger the impact on the overall code-base, the more likely you are to hit merge conflicts when a pull request is opened. It can be a huge headache to sift through and decide how to handle each conflict.
• Out-of-sync environments. Unless you’re regularly back propagating changes to your long-lived branch, it will quickly become out of sync with the main branch and orgs. This can cause issues with your Salesforce deployments if the changes from the project branch don’t integrate successfully with other development in your Salesforce org, or could even overwrite critical hotfixes that have been made in your production environment.
• Reduced feedback. Shipping small slices of development regularly allows for tight feedback loops and quick iteration. If development is being held back for long periods, that feedback isn’t received until later in the process which slows the iteration cycle.

Long-term projects with Gearset

Pipelines, Gearset’s Salesforce CI/CD solution, helps you to manage long-term projects. It has functionality specifically designed to keep projects separate from the BAU pipeline, while also letting you sync from the main pipeline to the project. All of this helps you to make sure projects run as smoothly as possible, and don’t involve a painful release process at the end.

In the following walkthrough, we’ll see how you can add a long-term project to an existing CI/CD pipeline in Gearset — you can follow along with your own free account too.

1. Spin up a project in your Pipeline

From your existing pipeline, click Add then Create project.

2. Name the project and select a base branch

At this point you’ll be prompted to give the project a name as well as selecting or creating the base branch for the project.

By creating a new project branch from main, your team can work from that branch for any project-related development — rather than the main branch.

3. Decide whether to allow back propagation

On the same screen, you’ll be given the option to allow back-propagation of changes in the main pipeline to the project pipeline. By toggling this setting on, it means you can push changes from your BAU pipeline to your project pipeline in a matter of clicks, to ensure your project environments aren’t getting out of sync.

Then click Create project.

4. Connect your project to your pipeline

Your project will now show on your pipeline page but won’t yet be connected to your existing pipeline. Click Edit pipeline then drag and drop the pipeline connection to where you want your completed project to merge when it’s ready.

5. Build your project workflow

By clicking the blue arrow on your project, you’ll be taken to a configuration page for your project. Add environments to your project in the same way as with Pipelines and make sure your final job in the project links back to the main pipeline.

And that’s it! Now you’ve set up a long-term project.

6. Commit and merge declaratively

Salesforce development from your sandboxes can be declaratively committed to project feature branches through Gearset’s UI. You can also open pull requests and resolve merge conflicts in a matter of clicks without leaving Gearset, making projects and Pipelines easy to use for any member of your team.

When the time comes to merge your project to the main pipeline, the code review process doesn’t need to be daunting — your development team can go in with the peace of mind that Gearest will intelligently resolve conflicts from reordered code and allow you to resolve any other conflicts without leaving the app.

Ready for easy project management?

If you’ve got a long-term project on the horizon and are worried about how to manage it alongside your usual release pipeline, book a consultation with one of our DevOps experts or start a trial today to try out Pipelines for free.

Keen to find out more about projects in Pipelines? See how global insurance company Zurich got up and running with projects and the impact it’s had on their team.