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