How to deploy an app to production with an actual button | Hacker News Reader

How to deploy an app to production with an actual button

blog.github.com

87 pointsguessmyname45 comments

Just make sure your build server's lava lamp is green.

Hate to say it, but my first thought upon reading the headline was, "You mean, like, the return key on my keyboard??" But that's no fun at all – I actually love the spirit of this post.

Same here - it's very cute when someone does this on their own for fun but don't know what to make of it when Github (owned by Microsoft) promoting an AWS service and button.

You can always just get a normal dash button (those are "free" simetimes) and listen to ARP requests to determine when the button is pushed.

"You mean, like, the return key on my keyboard??"

No.

The difference is that if you're using your keyboard you're very likely not to bother doing things like implementing defensive checks, reproducible and deterministic steps, good rollbacks that you've actually tested, etc. You're using your computer, so just tweaking a setting or adding in something you forgot is easy. If you're connecting your deploy process to a button then you need to automate everything in the process, which makes the process much more robust.

...and that is the justification I used to get some of these buttons this morning.

I don't know why using my keyboard is any different. Where are your assumptions coming from? A button is a button. This is why we use CI at my company – it IS all automated. And the last button I press after I type `git push origin master` is...you guessed it...return on my keyboard. That commit never sees the light of day in production unless it makes it through all of our checks.

One of those things which sound so exciting. You make it, you play with it, tell to your coworkers about it then you forget about it after a week

But you probably learnt something in the process and had fun while doing so! Win-win imho

I don't want to push the button, instead give me a keylock i need to turn. Like the keylock on old PCs.

Right, I need two keylocks 7 feet apart that need to be turned simultaneously after a security code has been punched in.

“Turn your key, sir.”

I'd rather a huge, Dr Frankenstein style throw switch that produces sparks and lightning when I pull it.

preferably labelled "magic"/"more magic"

Or how about an aviation/racing type switch with a red safety cover?

e.g. http://www.pilotautomotive.com/lighting/PL-SW26.html

Nah, I feel the switch needs to be big enough that two hands are required to pull it

Straight up implement the release process in TIM.

Or maybe something like the box from Hellraiser? ;)

More important is the big red mushroom switch you push to abort and roll back a mistaken deployment!

Trivial to implement if you use git for deployment.

git reset --hard HEAD^

Then redo build/post-receive hooks.

Not that trivial if your deployment involved data migration steps like DB schema changes.

We have an unofficial rule that automated db migrations must have a “downgrade/rollback” script too.

Spoken like someone who has recently learned git but doesn't have extensive experience using it in a production environment. Or perhaps I'm just becoming more cynical with age.

Is there something wrong with doing it that way? I'm a solo developer so don't have the benefit of learning from corporate best practices.

Should work fine for a solo developer however I believe his point was that you shouldn't be re-writing the history.

That is, what would be the next command you use? You have just done a hard reset and removed the last commit from the history. Now your remote and your local copy have diverged. You can do `--force` of course to rewrite the history on your remote but that wouldn't be acceptable in a corporate environment because many other people also have their local copies of that repository and they'll all have issues after you force your change in.

A more transparent approach would be to do `git revert HEAD` or even better `git revert <hash>` to explicitly have your change be reverted with another commit.

The deployment git shouldn't be making commits and should only ever be a slave to wherever it pulls from. Production git clone shouldn't be pushing commits upstream.

So while it's running the previous version, you just `git pull` again to get the latest fixes for whatever broke at a later time. No history is rewritten as it fasts forward to the latest commit. I hope that clears up how it's used. As far as I know this is a common pattern of usage for deployment scenarios.

For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have that repo checked out, they'll have problems. Not problems that they can't take care of, but an additional step nonetheless.

Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it.

1. Push to somewhere (maybe a bare repo, or github/bitbucket). 2. Production clone pulls from the master.

If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version.

> However if you have other developers or SRE that have that repo checked out, they'll have problems

What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment.

I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.

Here: https://security.stackexchange.com/questions/45452/is-using-...

May want to catch up on some git yourself.

I like the idea, but I would prefer to see it accomplished with a Raspberry Pi and a Big Red Button. At least this is one part of your life that shouldn't need AWS

Me too, Easy Peasy with a PI and button can be made as scary as you want :) Check this out: https://www.youtube.com/watch?v=VjgK-g3neTc

Or how about a switch that implements the two-man rule?

https://en.m.wikipedia.org/wiki/Two-man_rule

Good for not having to spend the weekend at work alone.

We have exactly this for deploying one of our side projects at work. :D

I believe it also flashes logs at you in (red) Morse code. It's not the most effective way to monitor a release.

Gitlab CI/CD and docker compose. https://youtu.be/RV0845KmsNI

I always get amazed that people want to "push the button" to deploy. So many times BA's and AE's wanted to hit the Release button on our iOS App.

What are BA's and Ae's?

Guessing business analyst and account executive

More to the point did they want to be the ones to push it? :-P

Yep, that’s correct.

They did, they’d come sit at my desk and push the button. I always thought it was weird.

That's because they want to matter.

Stolen valor

That's one of the best marketing strategy, I really want to buy that button right now :X

I'm bookmarking this right now!

You should have an actual button for that.

We're going to need a lot of buttons for all this functionality. Perhaps we could group them all together on some kind of hardware device that we could keep on our desk and use the interact with our computers. Maybe laptops could have them built in?

Laptops with buttonboards? Now that's insane. Should we also put a small touch screen right above it?

Perfect combination of a really useful mechanism to trigger an action when you're far from a computer, with an action that you never ever need to trigger when you're far from a computer.

Reply on news.ycombinator.com