Capistrano

Comments and changes to this ticket

• 

  Jamis Buck May 29th, 2008 @ 01:41 PM

  • → State changed from “new” to “invalid”

  Neat idea! However, since this requires users to have an S3 account to use this strategy, I'd rather not bundle it with Capistrano proper. This would make an excellent gem, though--please do bundle this up and release it separately! I think there are plenty of people that would find this useful.

• 

  Bill Kirtley May 30th, 2008 @ 10:25 AM

  (Please let me know if there is another forum in which you'd prefer to have this conversation.)

  The current implementation is fairly tightly coupled with capistrano, implementing a Capistrano::Deploy::Strategy::S3Bucket that inherits from Strategy::Copy.

  This may wind up being fragile to capistrano changes. Being inside the project there could be testcases to highlight any dependencies.

  To reduce the fragility I could make my strategy more completely standalone, just depending on configuration. This has the downsides of lots of duplicated code and lost opportunity to benefit from bug fixes / new features in the main line.

  Capistrano does have support for commercial products today. (e.g., perforce).

  Naturally, having an S3 account would not be necessary to use capistrano with other strategies, or to run testcases even of the S3 deploy strategy.

  Can I get you to consider accepting a patch?

• 

  Jamis Buck May 30th, 2008 @ 02:12 PM

  I understand your concern about it being fragile to capistrano changes. But the same would be true if it were implemented within capistrano. Even if it goes in capistrano, it won't magically stay in sync--someone needs to do the work. If you release it standalone and cap changes, then you just update your library and make a new release.

  You're right that Capistrano does ship with support for other commercial products, like perforce. The difference is that if someone is not using perforce, there is no confusion over whether or not they need to use the perforce module. This is not the case with deployment strategies. By bundling a new deployment strategy, it increases the number of options available to people out-of-the-box, which sounds like a good thing but really isn't. Too many options at the beginning can be confusing.

  Furthermore, what happens when you decide to enhance the strategy, by adding new features? You need to submit a patch to me and then wait for a new release. It's much better for things like this to have a life of their own--you can patch it and release it on your own schedule, without waiting for capistrano.

  I am sorry to disappoint--saying "no" is one of the hardest things I have to do--but an s3 deployment strategy is not a good fit for a standard capistrano option. However, I honestly believe it would make a fantastic third-party extension.

• 

  Sujal Shah June 8th, 2008 @ 11:06 PM

  Is this available somewhere for us to use? In other words, did you end up making it a gem?

  If not, let's put it together and set it up on Github. Happy to help out -- we're switching right now to a tarball deployment off of S3, though I have a few other wrinkles (We're branching releases and deploying those rather than the trunk, for example).

• 

  Sujal Shah June 8th, 2008 @ 11:26 PM

  Never mind, found it.

  For others looking for this: http://capistrano-s3.rubyforge.o...