Tedder - a scrum git branch manager

[headwindz]

Tedder - a scrum git branch manager

Background

In my team we have been adopting scrum to manage work items. We set a sprint to be one week length and we have a git sprint branch which is used to release the work done in the sprint.

Why

• We do have a naming standard for the sprint branch but it's sometimes violated for some reasons, leading to inconsistent branches. Our naming standard is feature/[yyyy][mm][dd], therefore the branch should be feature/20180809 for the sprint ending in 9th Aug 2018. I do see these kinds of violations:

  • feature/0809 - missing year
  • feature/180809 - short year
  • featuer/20180809 - tries to follow the standard but makes a typo

• If more than one developer participates in the sprint, they usually need to hang around asking whether the branch has been created since only one branch needs creating, leading to unnecessary communication and development interruption.

How

• For detail usage, refers to the docs
• Basically you would want to setup a config file in your git repo:

// .tedderrc
{
    "day": "Thu",
    "template": "feat/[yyyy][mm][dd]"
}

Then when you run tedder command in your repo, it will compute the branch name based on your specificed template and day. In our exmaple above, it will be feat/[yyyy][mm][dd] with yyyy,
mm and dd being substituted with the full year, month and date of next Thursday. It will then check the corresponding remote branch exists or not. If the corresponding remote branch exists, meaning others have created the branch before, it will simple fetch the remote branch and switch to the branch. Otherwiese, it will automatically create the branch for you and push it to remote repo.

You can also set a script in your package.json to use it locally.

//package.json

{
    script: {
        "scrum": "tedder"
    }
}

Then you can simply do

npm run scrum

• You can also use it globally from command line with options.

tedder -t 'hotfix-[yy][mm][dd]' -d Mon -n 1

This will setup the hotfix branch for next Monday for you.

[danielepolencic]

While it might sound like a good idea, it has its shortcomings.

1. You wait a week to release features completed at the beginning of the sprint
2. You deploy features in batches. This is overall riskier because you have more than one feature that could fail. Debugging is harder too, which one of the three features caused the bug?
3. Reverting back is a pain because everything happens together in the same sprint branch. You want to revert code for story A but it's intertwined with code for story B and C.
4. Stories could span multiple sprints. Do you skip release for this sprint, or do you release half backed stories?

Said that, if the above workflow works for you, you should keep using it. You could mitigate some of the above with:

1. feature flag everything
2. hotfixes could apply to the master branch as cherry-picks

[wilkesda11]

Like Daniel said there is still risk here. Feature Switches are great and can be really robust and handy. Another option is to use feature branches. Each Feature has its own branch and merges into the sprint branch when the team deems it ready. It should have been tested successfully before going into the sprint branch possibly by being deployed into some development environment to be tested.

[danielepolencic]

Feature branches don't promote early integration. You end up having team A working on a feature that doesn't play nicely with what team B is working on. The last who merges has a hard time reconciling the code.

If you decide to go down that route, you should keep your branches small and merge frequently. It requires a lot of discipline.