2016 Saturday Market Place - SoCraTes-FR/socrates-fr.github.io GitHub Wiki

Feature Branching is Evil

The slide deck used during the session can be found here.

There are 3 slides at the end with additional resources on the subject.

Feature Toggles

Most people that have used it, were disappointed and wouldn't use it anymore because it is too complex.

Don't forget to remove unused Feature Toggles.

In a Lean Startup environment you probably won't do this, because this is too much complexity to handle on top of starting a business.

One way to track Feature Toggles is to create a ticket in your ticketing system reminding you to remove it when it is not used anymore.

GitHub Flow

For every feature a branch is created. Deployment to production is done from the Feature Branch (as opposed to deploying from master/trunk).

Works, but changes have to be small.

Code Review

It is difficult to see the big picture when doing code reviews in a Trunk Based Development context. This is where a Feature Branch/Pull Request model helps. Or you can add the ticket number in the commit log to group commits together.

If you don't use the Pull Request model and do after commit code review, you need a commitment of the team that code reviews are important and will be done.

What is the purpose of Code Review? Share practices (when there is too little communication inside the team).

Dead Code

When adopting Trunk Based Development you are in fact introducing dead code until the feature is completely finished. How do you make sure code doesn't stay dead?

There are tools for detecting dead code (in the Java community there is Sonar).

The Definition of Done should make sure there is no dead code.

Kent Beck's rule: "Everything that is not tested is dead code"

Outcome

Both workflows (Feature Branching or Trunk Based Development) have their advantages and pitfalls. Which one to use ? It depends.

Trunk Based Development requires communication, discipline and software craftsmanship.

In the end most of the problems regarding the use of long lived feature branches can be traced back too trying to implement too big features at once. Reducing the size of the features will remove lots of the impediments. And having decoupled code base.

Take a Shortcut II

Notes consolidated with yesterday's session.