Deploying branches to GitHub.com
githubengineering.com
Deploying branches to GitHub.com
1–10 of 29 posts
Re: Deploying branches to GitHub.com
#2If one of your developer's Campfire (assuming y'all still use this) accounts gets popped, does the attacker now have the ability to deploy to production, or is there some other mitigating factor not mentioned here?
Re: Deploying branches to GitHub.com
#3We're following github flow and are currently doing these steps manually on deployment (i.e. merge branch with master, check out branch). Then roll back to master if something fails, otherwise merge master with the branch. It would be great with some tooling to help this.
Has someone done open source work on this already?
Re: Deploying branches to GitHub.com
#4We're following github flow and are currently doing these steps manually on deployment (i.e. merge branch with master, check out branch). Then roll back to master if something fails, otherwise merge master with the branch. It would be great with some tooling to help this. Has someone done open source work on this already?
Re: Deploying branches to GitHub.com
#5If one of your developer's Campfire (assuming y'all still use this) accounts gets popped, does the attacker now have the ability to deploy to production, or is there some other mitigating factor not mentioned here?
VPN would be my guess.
Re: Deploying branches to GitHub.com
#6"spider-skull-island" can I get access?
Re: Deploying branches to GitHub.com
#7The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good.
It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in.
So they could just merge first, and then if staging passes in their CI system, automatically deploy to prod, which is the way many orgs do it.
My point is though, you'd want to deal with the merge fun (if any) first, else you are deciding to test branches (pull requests) that only have ALL of the commits from master (rebased, etc), so it's easier to just make sure they hop on master first, else you might "remove" something from prod for a while until it's merged in. Not good.
They may have some things to deal with that, but in this case, it doesn't seem like something I'd recommend for most people, and feels weird and organically evolved. One branch may not have the commits another has and both could be deployed without merging, leaving the github deployed code state fluctuating back and forth as one commit drops out and another drops in, before finally both are in at the same time.
I wonder how this is handled?
Re: Deploying branches to GitHub.com
#8The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good. It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in. So they could just merge first, and then if staging passes in t…
I'm guessing that the master branch is first merged down to their develop branch or directly to their release branch. That way their release branch does have everything in master already.
Re: Deploying branches to GitHub.com
#9The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good. It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in. So they could just merge first, and then if staging passes in t…
I'm guessing that the master branch is first merged down to their develop branch or directly to their release branch. That way their release branch does have everything in master already.
Indeed that is the case:
> Since master is our stable release branch, we want to ensure that any branches being deployed are caught up with the latest code in master. Before proceeding with a deployment, Hubot will detect if our branch is behind and automatically merge in master if required.
Re: Deploying branches to GitHub.com
#10I really enjoy reading how organizations have implemented continuous deployment.
One question I have which is not addressed by the article is how to deal with database changes. Every database has difficulty with schema migrations to one degree or another, but MySQL (which IIRC is what GitHub uses) is particularly bad. In my organization, we are VERY careful with any deploy that contains a migration.
(I suppose this is where GitHub's staging environments with real world datasets come in.)
One workaround I've considered is automatically deploying code that doesn't contain a migration (which is the vast majority) and forcing a more manual approach to database migrations, to make sure people are on hand to roll it back if necessary.