How do you apply changes to your codebase? When should we merge the JoeBranch?

At our yearly 1 week Zühlke web camp a couple of us took the opportunity to share experiences with branching and release techniques.

TL DR;

Focus on Continuous Integration
Every change that you have locally is a branch (a code version that is different than main)
Every kind of branching delays Continuous Integration
Only a healthy code base with a “green” Build + Automated Tests let you sleep like a baby at night.

Things to think about:

How can you slice your work so that you can commit every 1 hour? (Incremental change)
How can you get faster feedback from your Build Server?
How can you do code reviews and keep quality high?
Why do you need the 1 person code gate keeper that signs off all code?

This is what we found:

2 overall goals

Get features to the user as fast as possible.
Ensure our work is good (quality aka the “the thing right”) and good for the user (“the right thing”)

What is Continuous Integration?

“Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day.”
From http://en.wikipedia.org/wiki/Continuous_integration

If you have shelve-sets (TFS), stashes (git), long lived (>1day) feature branches you are not doing Continuous Integration. You are delaying the Integration work which is waste and a potential risk. Even if you have a sophisticated build system that builds all branches and each distinct tree in a revision list, you still don’t know if all integrates well.

Why Continuous Integration?

Are all our changes healthy? Is our main line healthy? Could we release the code on main line just now to Production? Why not?
We want get fast feedback about our code base.

In an agile context we are very keen on feedback and implement lots of feedback loops. One of those feedback loops is the Build Server feedback as illustrated on Use Continuous Delivery to build the right thing.

Figure: Feedback loops

What techniques for branching exist?

Note: Every change that you make on your local machine is in fact already a branch. That change needs to be merged (commit&push, check-in in TFS terms) back to main

Release Branch: A code version that is released to an environment has its own branch.
Do you create this branch on release time? Or later if you need a bug fix for that environment?
I prefer the latter since you create unneeded complexity in your code base (waste).
“Spike” Branch: A code version that you potentially throw away or just want to share with another smaller group of developers.
Feature Branch: A code version where your work on a feature is isolated from others.

Some more are documented here https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

What does it depend upon which technique you use?

Team size
Available Tooling + Team Skill level
Release procedure
Software Architecture (Web, SmartClient, MobileApp)

What are reasons that you don’t have 1 main branch?

Other interesting branching and releasing models

Branch by Abstraction
http://paulhammant.com/blog/branch_by_abstraction.html

GitFlow Workflow
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

GitHub Flow
“anything in the master branch is always deployable”
https://guides.github.com/introduction/flow/index.html

Other interesting techniques

„Feature Toggling” http://martinfowler.com/bliki/FeatureToggle.html
“Canary Releases” http://martinfowler.com/bliki/CanaryRelease.html
"Dark Launching" https://www.facebook.com/note.php?note_id=96390263919

Feature Toggles

In my experience “Feature Toggles” can lead to similar problems as lots of branches:

What is on and off on this environment / server?
Does Feature X work in conjunction with Y?

But some advantages I found:

Testing gets easier

Either something is stable (no toggle) or not (toggle)

No build needed for special patches
Feature not working OK in Production? Turn it off

How many FeatureToggles do you have in your system?
Do you remove them consistently once they are “done”?

Peter Gfader 's Blog