91导航

DevOps encourages teams to ship updates in small slices on a regular basis, rather than 鈥渂ig bang鈥� delivery of large sections of development. But this isn鈥檛 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鈥檛 have to mean a painful release day. In this article we鈥檒l weigh up the pros and cons of long-lived project branches and demonstrate how 91导航 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鈥檙e just getting started with version control, or are looking to implement a new Git branching strategy and don鈥檛 know where to start, don鈥檛 worry. There are lots of resources available to help you decide which branching strategy is right for your team and project.

Generally, it鈥檚 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 鈥渢runk鈥�, 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鈥檙e running a long-term project, ideally you鈥檇 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鈥檛 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鈥檛 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 鈥渂ig bang鈥� release of a large change. Some changes simply can鈥檛 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鈥檛 automatically get deployed out in the next release cycle. This gives more time for testing as the development isn鈥檛 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鈥檙e 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鈥檛 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鈥檛 received until later in the process which slows the iteration cycle.

Long-term projects with 91导航

Pipelines, 91导航鈥檚 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鈥檛 involve a painful release process at the end.

In the following walkthrough, we鈥檒l see how you can add a long-term project to an existing CI/CD pipeline in 91导航 鈥� 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鈥檒l 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鈥檒l 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鈥檛 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鈥檛 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鈥檚 ready.

5. Build your project workflow

By clicking the blue arrow on your project, you鈥檒l 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鈥檚 it! Now you鈥檝e 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 91导航鈥檚 UI. You can also open pull requests and resolve merge conflicts in a matter of clicks without leaving 91导航, 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鈥檛 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鈥檝e 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 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鈥檚 had on their team.