Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
11–20 of 41 posts
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#12Any suggestions on reading material/designs for deploying a complete CI process for a new development team using these newer processes/applications?
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
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#13There'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…
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#14Any suggestions on reading material/designs for deploying a complete CI process for a new development team using these newer processes/applications?
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/
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#15There'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…
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#16There'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.
That's why I made the master vs. master-xxx distinction: deployments are an explicit action, which you are free to defer as needed.
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#17There'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…
We use a similar git flow system, but we build when a deployable bit of work has been merged into the release branch for this sprint of work (e.g. release-0.1). Once this merge has occurred, a build is triggered, and is then sent to our deployment tool (Octopus Deploy). Our branch naming structure partners with the build number for this specific bit of work to create a build number that matches semantic versioning.
From Octopus, we push these releases from our automated dev deployments up to UAT, staging, and eventually to live. Once we have pushed a release to live, the release branch is merged into master, making that release our new master build. When we move on to the next sprint/release cycle, we reset the build number and merge into a new release branch
We were keen to use this approach as it allows QA and non-technical people like project managers to deploy releases rather than developers. It was a bit weird to move to a workflow where you never actually deploy from master, but it's worked really well for our use case. It's also reassuring to know that the build that works on your dev box is the exact same build being deployed to your other boxes.
With that aside, I definitely agree with the idea behind your post. These are problems that can be solved with existing tools. You can do it using plain-old pull requests, or using a dedicated deployment tool. These tools already have plugins that you can throw into your favoured chat platform, or through email. It seems like there are an ever-increasing number of build/deploy solutions out there that seem to do basically the same thing, but slightly differently.
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#18If 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.
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#19There'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 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...
Re: Show HN: A Bot to Deploy to AWS, Digital Ocean Etc.
#20Seems 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
Does one need to have Docker configured to use this? I haven't gotten around to learning Docker yet.