Skip to content

Instantly share code, notes, and snippets.

@RyanAtViceSoftware

RyanAtViceSoftware/readme.md

Created January 18, 2019 13:01
Show Gist options
  • Save RyanAtViceSoftware/725060a4e5e9691e629ec50fedc92571 to your computer and use it in GitHub Desktop.
Save RyanAtViceSoftware/725060a4e5e9691e629ec50fedc92571 to your computer and use it in GitHub Desktop.
Download ZIP
Branching Strategy
Raw
readme.md

Our branching strategy is going to be GitFlow with some modifications to accommodate demo and testing.

Note we will be renaming dev to master by Monday (1/21)

Challenges

We are trying to solve these current challenges which we will likely not have in the future as our testing and dev ops improve

  1. Allow stability in the demo branches while working with small timezone overlaps. By the time the offshore team is done for the day the US team is just getting started and so we need to have a way that we can get demo stable the day before Friday demos but continue work on Fridays.
  2. Where can code be tested?
  3. The frequency of demos being weekly is causing us to to have to demo code that hasn't been fully reviewed and merged.

Note: We are looking to move to bimonthly demos after getting stable demo branching implemented as described below

Longer Term Mitigations

The factors that follow are all contributing to the challenges described above. Once these factors are addressed we can move to a more simplified branching strategy.

  1. Weekly demos are causing us to not have enough time to complete work with reviews and we are having to figure out how to merge code for demo without using dev as demo.
  2. Not having good automated testing coverage or a CD pipeline makes achieve stability difficult as we have to manually smoke test and fix things as we are rushing code into demos. Having isolated demo branch helps us add stability.
  3. Testing needs to happen in some kind of stable environment to avoid having churn around feature-branch-1 breaking feature-branch-2s code (or maybe breaking the whole branch). This can cause bugs to be incorrectly assigned to feature-branch-2's developer and other sorts of chaos and waste. To avoid this I've proposed that we look to deploy feature branches for testing so that each feature can be tested in isolation and then safely merged. However, there's a dev ops road to get there to having features in isolated testing environments.

I think once we get the above factors to a better place then we will be able to simplify the proposed branching approach that follows below.

Short Term Branching Approach

To accomplish this we are going to treat demo branches like transient release branches in GitFlow. What this means is that for each demo we will create a branch with the date of the demo in the name demo-jan-18. These branches will be deployed for testing.

Note this will result in sub-optimal testing release cycle at first but see Longer Term Mitigations above for suggestions on how to improve this

These demo branches will be kept alive until the next demo branch is created. At that time the previous demo branch will be deleted and the new demo branch will be deployed and used for testing and demo going forward.

To make this work we will need to follow a slightly awkward approach when it comes to merging\rebasing. I'm proposing that we:

  1. Never rebase feature branches on to demo branches
    • allows merging features into demo in isolation
  2. Always rebase feature branches on dev before review
    • allow for clean reviews

The problem we are trying solve is having a "dirty" feature branch sneak into dev via a rebase on demo. If we do the following

  1. Rebase feature-1 onto demo-xyz
  2. Merge feature-1 into demo-xyz
  3. Rebase feature-2 onto demo-xyz
  4. Merge feature-2 into demo-xyz

At this point feature-2 has the changes from feature-1 via rebasing onto demo-xyz after feature-1 merged into demo-xyz. Let's assume that feature-2 is reviewed, tested and ready to be merged to dev but let's also assume that feature-1 isn't ready and has bugs or needs refactoring from review. How do we proceed? If we make feature-2 wait for feature one we will have to pay a merge tax on feature-2 unnecessarily.

So to avoid this we can instead do

  1. Merge feature-1 into demo-xyz
  2. Merge feature-2 into demo-xyz

This will create two new "merge" commits on demo-xyz for feature-1 merge and feature-2 merge. Now if we feature-2 is ready to be merged into dev before feature-1 we can

  1. Rebase feature-2 on to dev
  2. Merge feature-2 into dev

And we no longer after to worry about feature-1 as it can autonomously go through it's lifecycle in isolation without worrying about breaking feature-2.

Note: We can delete merge commits off dev to quickly and easily remove feature that are breaking demo (we can also do this on dev)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment