Investigate infrastructure management solutions (Deploy! Deploy! Deploy!)

[rummik]

IRC: https://botbot.me/freenode/gittip/msg/5899206/

Right now we're just using some manual configuration on gttp.co, but it would be nice to have this automated so we just have to push couple buttons to deploy to a second VM in the future.

We'll also be using this for www.gittip.com when we've outgrown Heroku, so whatever it is needs to be pretty much language agnostic.

Some suggested solutions (see IRC):

• Salt Stack
• +1 Chef
• +1 Puppet
• +1 Ansible (@rgieseke)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[mvdkleijn]

I quite like Puppet myself. Not familiar with Salt Stack, but Chef seems more geared towards developers doing quick test setups and Puppet more towards system admins doing production setups. Mostly small differences though.

[seanlinsley]

I'd prefer to have something that will work with Vagrant, and I know of that list at least Chef can do that

[rummik]

@daxter There's room for more suggestions :P

[seanlinsley]

My point is that Vagrant makes it easy to get Gittip up and running locally, inside of a virtual machine so you don't have to install all the libraries in your host OS. And while I haven't tried using it yet, we already have a Vagrantfile

[rgieseke]

Ansible would be another option (Python based, configs are done in YAML), there is a Vagrant provisioner as well: http://docs.vagrantup.com/v2/provisioning/ansible.html

[rummik]

@rgieseke I've updated the issue text

[chadwhitacre]

@rummik Once you get back up to speed w/ the new 'top, let's discuss this ticket and narrow it down and possibly reticket from it.

[rummik]

@whit537 I'm going to have to look them over a bit more, but so far I'm liking the look of Chef's tiny configs

[clone1018]

More discussion: https://botbot.me/freenode/gittip/msg/7585870/

[patcon]

I would humbly suggest we consider managing our pipeline with the open source continuous delivery tool StriderCD:
http://stridercd.com/

[clone1018]

I don't think that this is a solution for our deployment problem. Strider is basically our existing travis app + deployment to one place (heroku), what we're looking for is something to manage our server infrastructure once we move away from Heroku.

[patcon]

@clone1018 it's actually not tied to heroku at all. It's pluggable, and heroku just happens to be the common deployment strategy. I haven't had a chance to use it myself, but planning to use it to decouple my deployment processes from any one solution or setup :)

https://github.com/search?q=%40Strider-CD+strider-
https://github.com/Strider-CD/strider-custom

[clone1018]

Does Strider also do configuration management and software updates/installs?

[patcon]

Oh and 👍 for Chef/Vagrant as well!

[patcon]

Nope, that's outside it's scope. So, for instance, you could have a custom deployment strategy that just runs capistrano, and all the smarts are in the capfile, which deploys to some server spun up with chef/puppet/ansible/whatever

I believe strider's main strength is building a transparent, user-friendly and decomposable build pipeline that can start with a single stage but be expanded as needed.

[clone1018]

What's the advantage over Travis? I'm guessing the "deploy on green"?

[patcon]

The main thing is that travis can't really do pipelines, or if it does, it's because you did something like gave it your EC2 credentials and it's spinning up all this magic elsewhere. But by definition, that won't be visual and integrated -- it'll just be a line in the logs where travis will be doing stuff elsewhere. Travis instances are transient and it's not intended to pass things between runs.

continuous delivery aims for pipelines where single steps can fail and you can promote the "build" through stages, and data gets passed between. So you could have smoke tests in one stage, capacity tests in another, sign-off by chad or team X in the final step, and you can promote a commit through those stages -- each representing more and more human or computational investment -- up until the given commit makes it to prod, having passed all the manual and automatic gates.

EDIT: Sorry, if I just rehashed continuous delivery principles there, but not sure where everyone stands on them :)

EDIT2: Keep in mind that I haven't had a chance to use strider yet, but I more have a sense of what a tool that touts itself as CD (continuous delivery) will be striving for.

[chadwhitacre]

Per IRC here are the business goals for this ticket:

1. As easy to deploy as currently with Heroku.
2. "Reasonable" price.
3. "Reasonable" time/maintenance burden.

[patcon]

Recently discovered that there's a heroku labs feature for pipelines:
https://blog.heroku.com/archives/2013/7/10/heroku-pipelines-beta

Currently experimenting on our hubot with it:
https://github.com/gittip/roobot#deploying

[patcon]

IRC convo with @zwn about vendoring and using a pipeline

[patcon]

Interesting hubot deploy workflow at http://pipelinedeals.com:
https://github.com/brandonhilkert/pipeline_hubot/blob/master/scripts/pipeline_workflow.coffee

[nobodxbodon]

We decide to continue using Heroku in short term.