Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

deploybot.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#21

Post by RubyPinch »

heavenlyhash wrote: post #19
vemv wrote: post #9

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). * Pr…

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 separat…

Could that not just be shuffled into the CI side of things

issues occur -> redeploy last-1 deployment

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#23

Post by sciurus »

parasanti wrote: post #11

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

If you haven't read it already, read Continuous Delivery.

https://www.amazon.com/dp/0321601912

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#24

Post by 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

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#26

Post by vemv »

heavenlyhash wrote: post #19
vemv wrote: post #9

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). * Pr…

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 separat…

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....) 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!

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#28

Post by riffic »

avtar wrote: post #3

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

DeployBot certainly does have a free use plan, afaik

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#29

Post by flukus »

josegonzalez wrote: post #15
vemv wrote: post #9

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). * Pr…

Many teams - why, I don't know - dislike automated deployments, but do like being able to trigger a deployment without needing to setup local deploy environments. In this case, having a bot is useful.

So why is a bot better than hitting the build/deploy button on your CI/CD server?

Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.

#30

Post by greenleafjacob »

vemv wrote: post #26
heavenlyhash wrote: post #19

Earlier quoted context omitted.

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 separat…

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 e…

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.

Post reply on HN