
How to deploy an app to production with an actual button - guessmyname
https://blog.github.com/2018-08-16-how-to-deploy-to-production-with-an-actual-button
======
mbostleman
Just make sure your build server's lava lamp is green.

------
bsmith
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.

~~~
onion2k
_" 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.

~~~
bsmith
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.

------
onion-soup
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

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

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

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

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

e.g. [http://www.pilotautomotive.com/lighting/PL-
SW26.html](http://www.pilotautomotive.com/lighting/PL-SW26.html)

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

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

~~~
chrischen
Trivial to implement if you use git for deployment.

git reset --hard HEAD^

Then redo build/post-receive hooks.

~~~
SmellyGeekBoy
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.

~~~
chrischen
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.

~~~
therein
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.

~~~
chrischen
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.

~~~
therein
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.

~~~
chrischen
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.

------
jimnotgym
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

~~~
suyash
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](https://www.youtube.com/watch?v=VjgK-g3neTc)

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

[https://en.m.wikipedia.org/wiki/Two-
man_rule](https://en.m.wikipedia.org/wiki/Two-man_rule)

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

------
sbhn
Gitlab CI/CD and docker compose.
[https://youtu.be/RV0845KmsNI](https://youtu.be/RV0845KmsNI)

------
JazzXP
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.

~~~
Something1234
What are BA's and Ae's?

~~~
zachrose
Guessing business analyst and account executive

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

~~~
JazzXP
Yep, that’s correct.

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

~~~
Something1234
That's because they want to matter.

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

------
egfx
I'm bookmarking this right now!

~~~
sandebert
You should have an actual button for that.

~~~
SmellyGeekBoy
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?

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

------
stevage
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.

