Trying a long term feature branch approach for something we need to do at work again. I’ve tried this before, with mixed results, and I rather not do it this way. But the alternative is feature flagging a significant part of the system, adding cruft that would never be cleaned up. At least this way, we have a chance to go in with a crowbar and just clear out the code we no longer need.

I’m kinda banking on the system we’re working on not changing from underneath us while we do this, which’ll hopefully make rebasing easier. But I’ll try to put in place some practices that’ll hopefully make the whole approach easier than last time:

  1. Rebase early, rebase often. I’ll try to rebase the epic feature branch from master at least daily, so as to reduce the divergence size from master near the end. It’ll also help with testing: we can be confident that what is being tested is close to what it would be if we were just merging to master as we work through tickets.
  2. No more keeping tickets in “Ready for QA” until others are ready. This was a big source of risk the last time we worked this way. Instead bring the tickets all the way through QA to just before release. We can’t actually release until the epic is done (otherwise, we need an epic feature branch at all), but that doesn’t mean we can’t deploy and test it in the non-prod environments.

Anyway, that’s the idea. Hope I’ll remember all this when I come back from Christmas break.