Select the Base Branch on a User Story

Updated 3 weeks ago by Copado Solutions

Overview

It is observed that Git can struggle to merge the metadata if you create and deploy new user stories when your pipeline has work in-flight that is yet to reach production. This happens because the new user stories contain the same work as earlier user stories, but are stored in separate commits. This usually happens with page layouts and Apex, but can affect any metadata in your pipeline. This document uses a use case to explain how to avoid this situation.

Use Case

Steps

In the given diagram:

  • User story 1 contains a new field (A) on the page layout.
  • User story 2 contains field (A) plus an additional field (B) on the page layout
  • Deploy user story 2 to INT. 

Result

Let’s compare the expected result and the actual result:

Expected Result

Actual Result

<Layout>

-Field A

-Field B

</Layout>

<Layout>

-Field A

-Field B

-Field A

</Layout>

In the actual result, you can see that there is duplication of a change.

Resolution

There are three strategies to deal with this.

  1. Promote the code to the Master Branch early.
    1. Release the work to production as soon as it’s ready and not when the release is scheduled. 
    2. Promote the code to the master branch early on to put changes in the new base branches, thereby stacking commits appropriately. 
    3. Remember that Copado was built with Agile practices in mind.
  2. Make the feature branch of user story 1 as the base branch of user story 2. (Preferred one)
    1. In the diagram above, user story 1 and user story 2 are committing the same work (field A on the layout), but in two different commits. This results in a duplicate when you merge. 
    2. If you set the base branch of user story 2 to be the feature branch of user story 1, you have the incremental history now in user story 2. 
    3. When user stories 1 and 2 collide in your pipeline, Git can merge the contents of user stories 1 and 2 without duplicates.
      Perform these steps to create user story2:
      1. Create a user story.
      2. Commit items.
      3. Go to the commit screen and select Advanced.
        1. Select the first story as the base branch (user story 1 in the given diagram).
        2. Commit your components as normal.
        3. Deploy user story up the pipeline.
          If you deploy user story 2 past user story 1, you are effectively deploying the work of both stories.
  3. If you can’t find the original story, or there are multiple stories, you can set an environment branch to be the base branch for your user story.
    Perform these steps to create user story 2:
    1. Create user story.
    2. Commit items.
      1. Go to the commit screen select Advanced.
      2. Select destination as the base branch (SIT in the diagram above).
      3. Commit your components as normal.
    3. Deploy user story up pipeline until it reaches the base branch environment.
Warning: Do not deploy past base branch environment. For example, if your base is QA org don’t deploy past QA. You will wreck your pipeline if you deploy a story past its base branch.

FAQs

What to do if the Destination Branch and the Base Branch are the same?

If the user story has deployed to the same environment as its base branch, you must recommit and recreate the story at this destination with the production branch (default) as your base. For example,  if your base is UAT, don't deploy past UAT. Recommit and recreate the story at the UAT org.

  1. Open User Story and click Commit Changes.
  2. Change operation from Commit files to Recommit files.
  3. Select Recreate Feature Branch.
  4. Select Advanced and select Master as the base branch.
  5. User story components must be already selected. Click Commit Changes.
  6. User story is now ready to deploy through the remaining pipeline.

Know that you may have to do this repeatedly for environments up your pipeline.

See Also


How did we do?