
Show HN: A Bot to Deploy to AWS, Digital Ocean Etc. - LukeFitzpatrick
https://deploybot.com/
======
vemv
There's a number of startups doing some variation of this.

What many don't seem aware of is that plain pull requests, in combination with
CI, entirely kill the need for a deploy app/bot.

This is how I do it at my current company:

    
    
      * use plain git flow (master/develop, hotfixes, etc)
      * use additional explicit branches per deployment target (e.g. master-spain for http://myapp.es, master-mexico for http://myapp.mx).
      * Protect these branches using github/bitbucket 'protected branches'.
      * open a PR from master to master-spain for performing a deploy of said target, detailng nicely what is being deployed and why.
      * instruct CI to deploy my app on each build of master-spain. master and develop are never deployed.
    

This setup has the same benefits (and then some more) than competitors:

    
    
      * Explicit deployment authors, reasons, timestamps
      * Impossible to deploy red code
      * Impossible to deploy code not in master
      * Impossible to deploy concurrently to the same target
    

Hope it helps someone!

~~~
heavenlyhash
The biggest issue I have with this model -- and git-flow as an opinion about
how deploy works in general -- is that it doesn't take any account of
rollbacks, and it doesn't scale well to arbitrary numbers of deployments.

The history of my production deploys is not monotonically forward: if
something breaks, it rolls back. Nor does production roll forward as one
piece: different components of the stack roll in separate motions (the db
schema vs the frontend servers for example).

Git, tied to the project _dev_ history, does not well represent these things.
Reverts in the deploy branch are not semantically identical to rollbacks in
production: and it's not necessarily safe or wise to merge them back into dev
history.

A separate git repo, referencing release numbers, or dev repo commit hashes,
would work pretty well on the other hand...

~~~
vemv
I'd say rollback is possible under a 'git driven' workflow.

That said, sincerely I find rollback one of those inherently complex ideas:

\- Rolling back assumes going back to the previous commit will fix everything,
an unproven (unprovable?) hypothesis in the face of database migrations, job
queues, etc.

\- Making database migrations reversible can be nearly impossible
(particularly at scale), aside from a significant engineering effort (for
something that _should absolutely never happen_ )

So I just don't contemplate the possibility of rolling back a deploy.

Instead I try things (particularly migrations) on staging rigurously:

\- staging environments always ephemeral - created from scratch for a given
relase

\- always load fresh production DB into staging

\- check that all my model objects are still `.valid?`
([http://api.rubyonrails.org/classes/ActiveRecord/Validations....](http://api.rubyonrails.org/classes/ActiveRecord/Validations.html))
after the migration

\- leave staging running a few days.

\- if you really can (not easy), forward production traffic to staging as
well.

If things go wrong (which under my proposed discipline would be a _massive_
screw-up), then the fix would require analysis, a regular fix (no time
travelling), and a regular deploy.

Reacting instantly (i.e. without analysis) is kind of delusional thinking. I'd
rather stay broken a little longer for avoiding further complications!

~~~
greenleafjacob
Code rollbacks are about immediate mitigation, not about pie in the sky
snapshot rollback. If you are sane about deployment and don't go to 100% of
traffic instantly, then halting a broken deploy and rolling back is certainly
better than shifting into analysis mode.

> I'd rather stay broken a little longer for avoiding further complications!

Unfortunately analysis is slow and an unbounded process, and high leverage
businesses where every second of downtime has actual measurable loss simply
cannot accept this trade-off.

~~~
vemv
Good point. Few solutions are apt for every scale and every business!

OTOH, if you really essay a given deployment again and again, you can become
really confident that the operation will succeed in production.

Real example: the most important feature I've developed this year has been put
5+ times in staging across a couple months. Every time I've asserted all kind
of stuff, gathered feedback from the business owner, etc.

The deployment going bad in production is just not a possibility.

At a larger scale than mine, I would probably introduce 'dark launching' as
well. That would further reduce the possibility of needing rollback.

------
avtar
Seems like a pretty neat service. To save others some time, they don't have a
free tier, you can't host it yourself, and they use Docker for builds before
deployments:

[http://support.deploybot.com/article/1028-plans-and-
pricing](http://support.deploybot.com/article/1028-plans-and-pricing)

~~~
captn3m0
Suggestion to all companies: please have a /pricing/ page.

~~~
avtar
Fair enough. They do list their prices but on their signup page
[https://signup.deploybot.com/signup/new](https://signup.deploybot.com/signup/new)

------
schappim
We[1] use DeployBot every day and we can't endorse them enough!

The combination of DeployBot, Github and AWS Elastic Beanstalk is awesome and
is the closest thing to having Heroku in Australia.

We used to just use Elastic Beanstalk, but when AWS moved their deploy method
away from git to using zips of S3 bundles, it meant that you needed to
reupload the entire app whenever you made a change (not just the delta). This
can take a long time on ADSL. DeployBot saved the day here, and allowed us to
pull the code from Github.

[1] [http://littlebirdelectronics.com](http://littlebirdelectronics.com)

------
jondubois
The problem with generic deployment services like this is that they don't
account for scalability.

Different stacks have different requirements. I built my own deployment
service for my open source project/stack specifically so that it would handle
scalability too. See [https://baasil.io/](https://baasil.io/) I know Laravel
followed this approach too with
[https://forge.laravel.com](https://forge.laravel.com)

I think using more sepcialized deployment stacks (as opposed to generic ones)
is the best approach for non-trivial apps.

Though I guess if you use a microservices approach, you could have a different
deployer for different kinds of services.

------
obisw4n
Migrated a complex Jenkins setup to Deploybot in 2015, saves our company a
_ton_ of time managing deploys. I'd highly recommend deploybot to anyone.

If I could critique even just one thing it would probably be its pricing
structure for personal use, I can't justify $15/m just for deployments. I'd
love if they had some kind of personal "developer" tier with support for more
repos. On the business side, $15/m is ridiculously cheap for what service
we're getting.

------
jszymborski
How does this compare to something like Laravel Forge[0]? Is it just that
Forge focuses on PHP?

[0] [https://forge.laravel.com](https://forge.laravel.com)

------
joshmn
Kudos to WildBit. They're undeniably great in all the ways.

~~~
hoodoof
Their team photos look so happy that they seem about to explode in a sparkling
cloud of rainbows and unicorns.

[http://wildbit.com/](http://wildbit.com/)

~~~
joshmn
Sent them cupcakes once. Nat's pretty awesome at customer stuff.

------
parasanti
Any suggestions on reading material/designs for deploying a complete CI
process for a new development team using these newer processes/applications?

~~~
twista
Definitely take a look onto Ansible[1]. We are using it on daily basis and to
deploy and provision servers.

Deployment from CI was just 4 lines into CI config (fetch repo, set-up keys,
deploy in the very same way as we do)

edit: we are using quite widely. Wanna create new servers in AWS - just run a
playbook. Wanna setup new database cluster - just run a playbook. So easy

[1]: [https://www.ansible.com/](https://www.ansible.com/)

~~~
parasanti
Thanks, will do! We are starting a new dev team and I would like to get these
practices going immediately instead of "oh, I lost the code cause it was on my
laptop" (which happens right now)

------
lsiebert
Heh, my company uses this. I didn't realise it was so new that it deserved a
HN post to it's front page.

------
vs2
I have used deploybot for over a year, great engineering. My favourite deploy
tool

------
riffic
Happy user of DeployBot here. Does exactly what it's advertised it does.

------
sandstrom
Any suggestions on similar open-source tools?

