Re: [capistrano] Testing Capistrano with Rspec?

[Lee Hambley]

Hi Drew,

Typically people don't bother testing their recipes, I'd say there's a rule, as long as you are working on something simple (calling a command, calling a rake task, etc) there's very little that needs to be tested, if you want to write something complicated in Capistrano; you might think about writing (and testing) a rake task, and simply calling that task from Cap, as if you would anywhere else.

The reason that people don't typically test their Cap recipes is that a) it's difficult (because the testing culture in Ruby wasn't as strong as it is now, when Capistrano was architected), and b) that for the most part, a passing test case in a spec bears little resemblance to the potentially chaotic environment where your code will be executed on the server (with dotfiles, and different versions of software, and etc)

If unsure, and if you identify constraints (Git option support is a source of common pain for us maintainers) - it's sane to do a check first, call out and capture the version number of the software you are using, and check that it's new enough, or trust it to err out before doing any damage if it's something you can trust to be sane.

Hope that helps.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

On 5 April 2013 17:19, Drew Sheneman <drewsh...@gmail.com> wrote:

I am fairly new to Capistrano. I was wondering if there are any resources / tutorials on testing my Capistrano configuration with Rspec?

I have seen a few examples using capistrano-spec, however these seem to always be related to testing recipes, whereas I have a very simple setup in my deploy.rb at the moment.

Is testing this necessary? Thanks.

--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
---
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Paul Hollyer]

Hi Guys,

On 5 Apr 2013, at 16:29, Lee Hambley <lee.h...@gmail.com> wrote:

Hi Drew,

Typically people don't bother testing their recipes, I'd say there's a rule, as long as you are working on something simple (calling a command, calling a rake task, etc) there's very little that needs to be tested, if you want to write something complicated in Capistrano; you might think about writing (and testing) a rake task, and simply calling that task from Cap, as if you would anywhere else.

The reason that people don't typically test their Cap recipes is that a) it's difficult (because the testing culture in Ruby wasn't as strong as it is now, when Capistrano was architected), and b) that for the most part, a passing test case in a spec bears little resemblance to the potentially chaotic environment where your code will be executed on the server (with dotfiles, and different versions of software, and etc)

How about setting up a VM as a staging server to test that the recipes do deploy as expected?

Best

Paul

[Lee Hambley]

Sure, you absolutely should use a staging environment or VM, or anything before you throw recipes at production, but even then it's tricky to anticipate all the weirdness that might crop up.

Typically the impact of botched deploys is minimal as the deploy isn't linked in the "live" position until the last step, but absolutely it's a thing to be aware of.

In the forthcoming version of Capistrano it's much easier to use with chef and puppet (solo, and solo runmode) which should eliminate the temptation to set servers up by hand, and have unknown environments which aren't really controlled anywhere. But in the meantime, a VM, or a snapshotted AMI image, or any other number of solutions are great ways to get come to some kind of minimum confidence level before rolling out the big guns!

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

[Paul Hollyer]

On 5 Apr 2013, at 16:40, Lee Hambley <lee.h...@gmail.com> wrote:

Sure, you absolutely should use a staging environment or VM, or anything before you throw recipes at production, but even then it's tricky to anticipate all the weirdness that might crop up.

Typically the impact of botched deploys is minimal as the deploy isn't linked in the "live" position until the last step, but absolutely it's a thing to be aware of.

In the forthcoming version of Capistrano it's much easier to use with chef and puppet (solo, and solo runmode) which should eliminate the temptation to set servers up by hand

Cool, I will be looking forward to that then. I'm currently/intermittently learning the Puppet DSL, so now I have another good reason to get my head well and truly stuck into Deploying Rails.

[Paul Hollyer]

@drew

Sorry to have 'hijacked' your thread a little.

Paul

[Drew Sheneman]

No problem at all! Thanks for the great feedback, Lee & Paul. I have definitely looked into using VMs as a staging environment and will probably being doing this once I get into larger projects.

This helps me going forward as far as testing is concerned.

[Peter M Souter]

For testing capistrano recipes, I'd recommend vagrant. if you're using multistage you can create a vagrant.rb (config/deploy/vagrant.rb) and do "cap vagrant deploy" to test your stuff out on. At least that's what I do and it works for me?

PS. Don't be afraid to use capistrano-spec, its awesome in every way!

PPS. Full disclosure, I'm one of the maintainers of that gem ;)

[Cassiano Leal]

You might want to add ServerSpec to the mixture as well: http://serverspec.org

It's pretty neat.

- cassiano