Explore capistrano for deploys

[patcon]

Currently we're deploying with Chef itself. It might make more sense to deploy with Capistrano, with the idea being that we can deploy to the configured vagrant VM in the same way that we would deploy to a remote server.

So basically, use Chef to set up the server environment from scratch, but use a real deploy tool to send the set up the actual Drupal app.

Definitely requires way more thought, but just wanted to throw it out there

[coloradobum]

I have been experimenting with a similar workflow and really like the approach so far.

I use my local box (usually a vagrant) for dev, a staging server (chef made in my local lan) and a prod server (chef made in ec2, rackspace cloud, etc). Capistrano is a great tool for easily pushing my project through these environments.

I'm still tweaking things, but saw your comment on this, so I had to respond. I have been experimenting a little with your project and love the vision. You have my vote on this feature (although cap works from your client and is not installed server side, so the feature may come in the form of a capfile to be used in conjunction with ariadne?). Let me know if I can help.

jeff

[patcon]

That's awesome @coloradobum! I don't suppose you'd be interested in teasing out the common chef bits into a separate project? Are you in a situation where you can share the common stuff, or do you have lots of private stuff mixed in?

And as for approach, I'm thinking the Capfile (and accompanying rubygems and support files), plus appropriately versioned gems in the group :development section of the Gemfile, with the assumption that people will deploy from the project folder?

Also, while it's been awhile since I spoke about this with @bjaspan at Drupalcon Denver, my understanding is that the Acquia guys are at least open to the idea of bypassing git in favour of cap-style deploys for those who want it. (They just perpetually have a lot of stuff on their plates.) So there's always the angle that it could become a more standard way of doing deploys, and doesn't necessarily have to remain fringe. OUTSIDE TOOLS FTW!

[patcon]

/cc @sylus

[coloradobum]

@patcon I do have some private stuff intermixed, but have been looking for the opportunity to generalize it and start using github more - here it is.

I will start digging into this more and post my progress soon.

[patcon]

wahoo! 👍

Even just stripping out the private stuff and replacing it with dummy strings would be a start. Nothing wrong with posting something broken as a starting point, so long as you're clear when it is :)

[coloradobum]

hi patcon

Just an update that I am still working on this and haven't forgotten. =-).

j

[bjaspan]

@patcon, your consistent referencing my name in your github issues has apparently worked. Here I am. :-)

On the topic of "bypassing git in favour of cap-style deploys", my understanding is that means that you would explicitly push code to your server(s) each time you want to change it. You could achieve that in Acquia Cloud using Live Development, which gives you a writeable docroot directory, but for multi-web node deploys, Live Development lives on a network filesystem, which you pretty much do not want to use in production. If we gave you a writeable docroot area on local server disk which you could then copy code to, what would you want us to do when your server failed and we had to relaunch it? Without your code in git, we would be unable to re-deploy it, and your site would be down or impaired until you got around to copying the code again.

[patcon]

Thanks for helping me understand Barry. I think you'd brought that up previously, but I'd forgotten. And in all honesty, hadn't been thinking too deeply on this recently. Might be that this approach is not sensible for Acquia. You've given me something to think on though...!

The root concern (at least for me) was that we wanted to be in control of the format in which we maintained our Canonical Source of Truth git repo. Acquia expects a full docroot, but we wanted to VCS just an install profile. I've recently learned that heroku deals with providing this flexibility by utilizing something called a buildpack. It basically makes the environment setup steps (after each push) pluggable -- "official" deploys of node/ruby/python apps use specific buildpacks, but you can just as easily use a custom one. Not that it's easily implemented in our case, but seemed to be an interesting approach. For example, this guy added composer support for php apps on heroku:
https://github.com/bergie/heroku-buildpack-php
http://bergie.iki.fi/blog/using_composer_to_manage_dependencies_in_heroku_php_apps/

Technically, heroku could support a drupal buildpack that ran drush make after each push, but the heroku system would never allow ssh (and hence no drush support), so that's kind of a deal-breaker :)

Anyhow, don't worry about a specific reply here -- this has kinda spiralled into something not particularly actionable atm!

[patcon]

Continuous delivery principles encourage precompilation on a single build server (rather than compiling on the edge on web servers themselves). Here's a post discussing how to do this with cap:
http://www.rostamizadeh.net/blog/2012/04/14/precompiling-assets-locally-for-capistrano-deployment

The relevance of this is that the same cap recipe would be used for deploying from the jenkins build server. Since we only want to build once per commit (ie. one artifact per commit) and send that built site to each future environment, we'd need to figure out how to cache each build and simply deploy it to different servers depending on desired environment.

Also, at least locally, would probably want the option to run the local precompile remotely, since only the VM is guaranteed to have all the tools required (ie drush/composer/etc) -- we don't want to also ask people to install them on the host machine, as that's a pain.

[dkingofpa]

Hi there @patcon. We're using the xforty/drush-deploy project for deployments to production servers. It's built on top of Capistrano. Perhaps that can give you some ideas? Feedback is definitely welcome.

[patcon]

Thanks man! I didn't mention xforty in this thread specifically, but you guys are always on my radar when I'm telling people that capistrano + vagrant is the way forward. We've been using Acquia's cloud API lately, so deploying to self-hosted environment went off the radar in terms of urgency. Starting some new projects that have brought us back to it :)

Thanks very much for the heads up, and I wholly plan on testing out your project before attempting to build our own. I'll def let you know of any feedback!

[patcon]

Oh HEY! Just realized you'd changed the format quite a bit. Really like the idea of camouflaging as drush and the site alias integration!

[dkingofpa]

Yeah, drush-deploy is a separate project from our vagrant work. It's another standalone tool in our Drupal process.

[patcon]

no sorry, i had been looking at drush capistrano-deploy, but didn't realize you'd started a new fork that I should've been watching :)

[patcon]

Quick and dirty instructions for posterity:
https://gist.github.com/patcon/4728949