To Feature Branch Or Not To Feature Branch

From CitconWiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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