Handling branch deploys

[adrianmoisey]

How do you handle the case of a branch not being up to date with master when deploying that branch? Does the deploy process merge it with master before deploying? Or is it up to the developer to make sure that it's up to date?

[holman]

Yeah, neglected to include that in the post!

I'd suggest you have your deploy process auto-merge master into every branch going out into production. If there's a merge conflict, just bubble it up to the deployer and block deploys of that branch until the merge is manually handled.

[joeyguerra]

Did you have any experience with just creating a tag in master to solve the problem of "we need to deploy that last good known state"?

[holman]

I just think it's way more effort than what's needed. Git's UI for tagging is stupid, and there's no real standard consistency involved with tagging (so if you're doing incremented versions you have to do a bit of legwork to determine the current version, tag your code, push the tag, etc.). It's just a lot easier to deploy the branch and then merge it; then you're done.

[viniciusban]

But when the branch used to deploy will be merged into master to reflect the "new production code"?

[holman]

Really depends! For small changes, it'll likely be in the realm of minutes — is the site still running? cool then it's probably fine. For large changes, or for changes that impact a lot of code, it could take hours, particularly if you need to wait until you see heavy usage of the feature (say you deployed at 10am but you experience the high point of traffic during the day at 1pm... might make sense to lock production until you can be sure the high end is performing correctly).

In either case, it's worth codifying this internally as to what this means. Are there error limits you should look towards not exceeding? Performance metrics? etc.

[viniciusban]

Thank you. It's clear, now. :-)