To Feature Branch Or Not To Feature Branch

From CitconWiki
Revision as of 02:21, 5 February 2012 by Zsoldosp (Talk | contribs) (Feature Branching vs. Feature Toggles)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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!

Video Recording of the Session