
GitHub Flow - schacon
http://scottchacon.com/2011/08/31/github-flow.html
======
jerhinesmith
"Every branch we push has tests run on it and reported into the chat room, so
if you haven’t run them locally, you can simply push to a topic branch (even a
branch with a single commit) on the server and wait for Jenkins to tell you if
it passes everything."

From this, it sounds like Jenkins is automatically picking up new topic
branches, running the tests, and reporting on the results. Any suggestions on
how to set something like this up? In my (very limited) experience with
Hudson/Jenkins, this sounds like it wouldn't be possible without manually
setting up a project for each branch.

~~~
xbryanx
Exactly! I'd love to see a post with this much detail talking about the
technicals of their deploy process. Using this free-wheeling branching model,
requires some very flexible deploy tools, which I don't think(?) exist in the
wild. Please school me...

~~~
rsanheim
You use the github plugin with Jenkins, and tell Jenkins to build all
branches. That's about it.

edit: more details here -- this is what Relevance uses for our CI:
<https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin>

------
Aqua_Geek
I wasn't aware that you can open pull requests from within the same project
(i.e. not from a fork). The idea of using this for quick code reviews before
merging code into the production branch is really interesting to me...

~~~
nosequel
Most people using github for their everyday work do it the way Scott
mentioned. Github's pull request system is fundamental to its success and
everyone I know's workflow.

~~~
Aqua_Geek
I'm familiar with the Pull Request system. I've just only ever used it to pull
changes back into the main repo from other forks; I didn't know you _could_
use them from within the same repo.

------
blackRust
Well written and presented. Important not to miss out his closing comment:

"For teams that have to do formal releases on a longer term interval (a few
weeks to a few months between releases), and be able to do hot-fixes and
maintenance branches and other things that arise from shipping so
infrequently, git-flow makes sense and I would highly advocate it’s use.

For teams that have set up a culture of shipping, who push to production every
day, who are constantly testing and deploying, I would advocate picking
something simpler like GitHub Flow."

So if you fall in the second category, this is a read for you.

------
simonw
Question about the chat deploy bot: there are a few lines in there that look
like this:

    
    
        hubot deploy github/ghost-down to production
    

Is that deploying a branch directly to production, or does that cause a branch
to be merged with master and then master deployed to production? If the
former, why deploy a branch directly rather than sticking to the "master is
production" idea?

~~~
kneath
It's deploying a branch to production.

If you think about it, this is completely the example of "master is
production-ready" idea. We care so much about keeping master deployable, that
if we have code that may have issues and need to be rolled back, we deploy
just the branch. That way if things break, you can "roll back" to master and
everything is good again.

~~~
scorpion032
In any case, you can always do a `git co hash`.

------
Pewpewarrows
Very good comparison between workflows of deploying several times per day
versus much less often. While it might not be obvious to some, the exact same
git "flow" won't work for both. Your tools should complement your corporate
culture, not the other way around.

I think the most important thing to note from either method, though, is not to
develop on master/trunk. Have a separate branch, or further branches off an
entire "develop" branch. The tip of master should always be a stable build.

~~~
dasil003
Yes, however the only factor here that implies _never_ working off master is
the peer review. If one dev can take responsibility for the stability of a
patch, then it's perfectly okay to work off of master locally and push when
it's stable. If you need to put this work on hold or it grows into something
requiring a topic branch, at any time you can simply do:

git branch new_topic_branch && git reset --hard origin/master

------
tednaleid
This sounds like a feature branch strategy, which I've only used in 1 or 2
person teams, never on projects that big.

There have been some articles recently on the downsides of feature branching
that my experience agrees with ([http://continuousdelivery.com/2011/07/on-
dvcs-continuous-int...](http://continuousdelivery.com/2011/07/on-dvcs-
continuous-integration-and-feature-branches/)). I'm curious if the GitHub
people have hit the same issues.

So if 2 people are working on the same feature, they're probably working off
the same named branch.

Are there any race conditions with merging to master? I'm assuming that only
one head is allowed in master, correct? So that before a pull request is
accepted and merged into master, the latest master must first be merged into
the feature branch and have CI run all tests successfully on it before the
pull request can go. Does GitHub stop you from merging into master if someone
else just merged into master and you're about to create a new head?

Then you have to merge the latest master into your feature branch, run CI on
it again and then merge to master after CI is successful (assuming someone
else didn't beat you to merging to master again).

(I've got a lot more experience with Mercurial than Git so my mental model
could be a little off)

~~~
pgr0ss
I actually just wrote up a blog post as well about why I don't like feature
branches: [http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-
branc...](http://www.pgrs.net/2011/08/29/why-i-dont-like-feature-branches/)

My main reasons are that git history gets messy, builds don't run on feature
branches (although github seems to have a work around here), and refactoring
is harder.

My opinions are largely based on working on larger projects (more than 10 devs
working in the same codebase).

~~~
freedrull
Learn to use rebase and squash commits! It solves a lot of the issues you
talked about.

~~~
pgr0ss
Squashing commits can fix up git history, but it does not address the bigger
issues: refactoring, lack of builds, and having to deploy multiple branches to
test features. The first two make it very hard to do any significant code
reworking on a feature branch.

~~~
tpz
I intend no ill will with this response, but it is worth pointing out that
"the first two" "bigger issues" have nothing to do with your revision control
system.

Lack of builds is something about which you and your CI server need to have a
chat, and refactoring is something about which you and your people need to
have numerous chats before, during, and afterwards.

------
freedrull
Is it really zero-downtime deployment? I've read about Passenger 3's zero-
downtime deployment strategy, but on my Passenger 3 setup, the server is still
always a little unresponsive for a few seconds after a restart.

~~~
kyleslattery
As far as I know, they're using Unicorn: <https://github.com/blog/517-unicorn>

They spin up new instances of the app and let the old instances finish serving
requests before killing them.

------
gnufied
Its interesting that they abandoned CI Joe. I wouldn't say, I saw this coming.
But, unless they wanted to maintain/write a full blown CI server themselves,
it would have got harder for multiple projects.

~~~
cmer
Indeed. I'd love to hear the details on this. I was considering CI Joe for a
project.

~~~
rsanheim
This isn't surprising to me. While CI Joe was decent and simple, its really
extremely limiting once you want to do anything moderately complicated.

Jenkins has a crummy UI, but it is very powerful and has a lot of useful
plugins. If you are moving to any sort of continuous deployment setup, as
Github is close to, you really need something as powerful as Jenkins.

------
geeksam
For those who enjoyed this talk, Corey Donohoe gave an awesome presentation at
Cascadia RubyConf that goes into more detail about what they use Hubot for,
and also mentions deploying branches to a subset of their boxes. It was one of
the best talks of the conference:
[http://confreaks.net/videos/608-cascadiaruby2011-shipping-
at...](http://confreaks.net/videos/608-cascadiaruby2011-shipping-at-the-speed-
of-life)

------
dave1010uk
In a small web agency, mainly creating sites for clients, we find a mix of
"git-flow"-style and continious deployment works best.

In the weeks before a new site is launched, we work to our own feature
branches and merge into master when a feature is complete. In the run up to
the site launch, when there's just CSS tweaks and the odd bug fix, people
start working on directly master and deploying straight to staging servers.

When a site has been launched we normally keep working just on master, though
occasionally creating feature branches for bigger changes.

This seems to work well for us as our DVCS needs change over time. I'd be
interested to hear how other web agencies manage the different stages of
developing clients' websites.

------
randall
One question i've always had: How often do "regular" people commit? Should I
be committing every time I hit save... or should I wait? (I don't work in a
dev team, so I'm looking for the wisdom of developers who have to work in
teams.)

~~~
DamagedProperty
I like to think about my commits as units of work that I can pull back or
cherry pick if I want to. It doesn't always work out that way.

Make sure your commits are cohesive to the change you are making. I think that
is a good rule of thumb.

~~~
dasil003
Yes, definitely nice if you can make your commits atomic changes. The more
easily able to right a nice summary line (50 chars please!) the better.

On the other hand, some changes are big and messy. In this case I sometimes do
intermediate commits, especially if it's at the end of a day just so I can
keep yesterdays changes conceptually separate from todays. In the end I may
rebase -i the whole thing and clean things up before pushing, but only if
there are some obvious and quick ways to split it up.

------
dasil003
Here's what I'm curious about that is not mentioned at all:

How do they manage deployment to staging? At my company we typically deploy
topic branches directly to staging, but we have fewer developers and slower
pace. If multiple people need to deploy topic branches we set up an ephemeral
staging branch that merges the multiple topic branches together, but I can
imagine that getting super hairy on a team the size of GitHub's.

Do they just mostly deploy directly to production, thus severely minimizing
staging contention?

~~~
schacon
it depends. when staging is in a good state we'll simply ask if anyone is
using it. you can see a few deployments to staging in that screenshot i posted
i believe. however, if the developer judges that a ci pass is good enough, a
deployment directly to prod after they get the ci green light is also common.

this is also one of the benefits of deploying via a chat room - you can ask if
you're going to be stepping on anyone before you do it.

------
lylo
How do you handle branches which require DB migrations?

~~~
scottschulthess
I'm assuming they build a new db per branch on the ci server and auto run
migrations on them. pretty typical

------
terinjokes
For reasons decided long ago, the company I'm at uses Mercurial, and I don't
think we're in a position to retrain everyone and move to a private GitHub
repo.

Anyone know of ideas for doing code reviews for the whole pull request,
commit, or a single line like GitHub? This is probably the most beneficial
part for us.

~~~
tednaleid
Could you use a private BitBucket repo for this? BitBucket has the same kind
of pull request functionality that I'd think you could use to emulate this
continuous delivery style.

~~~
terinjokes
To be completely honest, I've never been satisfied with using BitBucket, doing
anything is comparitively harder, and honestly it just feels like I'm using an
incomplete GitHub clone. (and I really don't like support teams that are
"creatively bankrupt")

I'll look into if the issues feature works for us, but me might have to roll
something of our own.

Doesn't mean I won't make the pitch for Git yet again.

------
puredanger
I'm curious how CI is done on branches. It's mentioned but not elaborated on
in the article.

~~~
technoweenie
Every branch is scheduled to build in Jenkins as soon as it gets pushed. We
get success/failure notifications in Campfire.

~~~
technomancy
So is there a separate Jenkins job per feature branch? How are these created?

~~~
justinweiss
I'm not sure it's how GitHub does it, but we use the jenkins gem to do pretty
much the same thing: <https://github.com/cowboyd/jenkins.rb>

------
ethank
I wish they'd post a guide on how to do a separate CI job per feature branch.
That'd make this approach really scalable.

~~~
justinweiss
Using something like the Jenkins gem
(<https://github.com/cowboyd/jenkins.rb>), it's pretty easy to script. The
hardest part is setting up the job configuration the branches will use.

