To Feature Branch Or Not To Feature Branch
Revision as of 12:37, 16 November 2011 by Zsoldosp (Peter Zsoldos's Notes)
Topic proposals that were merged into this sesion
- What makes a build a release?
- How does Continuous Delivery effect the rest of the organization (sales, marketing, etc.), especially for a product, and not a SaaS company?
- there weren't many people with such experience
- hallway conversation suggested to check how fast existing customers react to updates - no point releasing if they don't use it
- Feature Branching vs. Feature Toggles
Feature Branching vs. Feature Toggles
- we thought the branching discussion was resolved years ago, but now they are back with git! (any links to the old discussions?)
- long lived branches cause problems
- tools are better than they used to be
- long live feature branches can cause problems - nested if hell if not removed quickly after the release
- both require a lot of discipline
- any practice that prevents you from refactoring is inherently a bad practice
- both of these practices only seem to cause problems on larger teams
- only try any of the approaches if you really have to!
- CI tools would be great if they could handle multiple versions of dependencies, and should use their IDLE time to build these
- what if I merged this branch to this other branch? would all tests pass?
- warn if violating backwards compatibility - e.g.: in a large team, with an eclipse like plugin architecture, if I built my plugin against an older release, it should work with all releases since, so when I go to work on this plugin again, I can be assured that I can upgrade my dependency to the latest without worrying about potential issues, so that I don't have an excuse to stick with the old version
A release is a build with confidence!