search

holman / ama

Ask @holman anything!
732 stars 278 forks source link

Branch deploy strategy #772

Closed damien-list closed 8 years ago

damien-list commented 8 years ago

Hi,

Just read your great article on How to deploy Software and one thing is not very clear to me about the branch deploy strategy.

This is why it's important that your deploy tooling allows you to deploy your branch to production first. Once you're sure that your performance hasn't suffered, there's no stability issues, and your feature is working as intended, then you can merge it. The whole point of having this process is not for when things work, it's when things don't work. And when things don't work, the solution is boring, straightforward, and stress-free: you redeploy master. That's it. You're back to your known "good" state.

Can you explain a little bit more this strategy ? I'm wondering how do you handle people working on different branches at the same time. Is it handle by the queue, you explain later in your article ? Otherwise, pushing a branch into production means you need to merge all diffs between the moment you branch and the master branch which is in prod. Don't you think it's counter-productive to merge all these diffs on our own branch and then push it to prod, knowing that there there will be a merge of our own branch later in the master branch ?

Not sure if I've made myself clear enough, but let's discuss it. :)

damien-list commented 8 years ago

Seems to be related to this #771.

holman commented 8 years ago

I'm wondering how do you handle people working on different branches at the same time. Is it handle by the queue, you explain later in your article ?

Yeah, basically. Most branches will probably only go through this check period for a couple minutes to ten minutes, so there's not going to be a lot of hold up involved when others are waiting to deploy.

Otherwise, pushing a branch into production means you need to merge all diffs between the moment you branch and the master branch which is in prod

Something I left out is that master should be merged into the branch you're deploying prior to deploying it to production. That way you know that your branch is a superset of all commits rather than a subset.

mcfiredrill commented 8 years ago

Do you deploy the branch to all servers with the new feature behind feature flags ? Or do you deploy to a subset of servers, and is there any interesting tooling around that?

holman commented 8 years ago

Could be either, really. I think usually you'll just want to deploy it to all of production at once... if it's properly behind a feature flag then it should be cordoned off anyway. Sometimes it's worthwhile to feature flag just on particular servers, though, if you're slowly rolling it out to everyone in general or if you're worried about byproducts of that code that might get run.