Matt, Thanks for the support! (And everyone thinks open source mantainership is for rockstars!)
On Friday, January 6, 2012 at 12:26 AM, Matt Rogish wrote: > Lee, > > I understand. Capistrano has been awesome - been using it for years and years > now - and I absolutely understand there are countless thousands of apps (or > more!) using it and it's far too ubiquitous to make any major changes. If > only my apps were as popular! :) > > Keep up the great work and look forward to seeing what you create! > > Thanks, > > -- > Matt > > > On Tuesday, January 3, 2012 at 3:58 PM, Lee Hambley wrote: > > > Matt, > > > > Certainly, "continuous deployment" is a luxury few of us are afforded, I've > > mostly worked at places where the deploy is weekly, and that's as agile as > > we can get. The PHP crowd are another group who benefit. (although, for > > what it's worth Matther Macdonald-Wallace, I have a project called > > "Railsless-Deploy" which is the normal deploy, minus all the railsisms) > > > > My standard opinion is that the usage of Capistrano is too wide and varied > > for me to be in a position to make any major leaps in functionality or > > behavior, which is why I'm focusing my efforts on writing a better > > underlying SSH driver, with a more sane API, which works the way most > > people are [mis]using Capistrano; my hope being that somewhere on top of > > that API can be a cookie-cutter Rails deployment with sane hooks for people. > > > > This project, when [or rather if, with my schedule the way it is] comes to > > fruition, I will be running a long, long pre-release phase, to try and come > > up with sane defaults that work for most people according to the way things > > work in 2011. > > > > Matt, you're not alone in thinking it's a little odd, either - I quite > > often forget to run migrations, and blow the production sites I work on up, > > with forgotten migrations… worse yet is when I've been out of the office a > > few hours, and the quite finally quietens down, Passenger mod_rails unloads > > the app… and it won't come back up! > > > > Here's to a brighter future. > > > > -- > > Lee Hambley > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > On Tuesday, January 3, 2012 at 9:50 PM, Matt Rogish wrote: > > > > > If I (and by "I", I mean, what I've seen done and what we do now at my > > > current organization) have a migration that *must* be run before the site > > > comes back up, then it has to be run as part of the deploy; the site > > > *should* be down whilst it's doing whatever it is doing. In my > > > experience, those are usually ReallyBigDeals(™) and planned and scheduled > > > in advance, and are the exception, not the rule. Usually not something > > > that is just coincidentally run as part of a regular deploy. > > > > > > Preferably, though, I have a migration that can be feature-flagged away > > > (or some sort of "zero-downtime db deployment" techniques) so the lack of > > > it running won't break prod; then it's run as a background task thru a > > > predefined process/queue and then the feature enabled/toggled once > > > everything's in place & verified working OK. > > > > > > Still, I object that only "toy" apps are expected to have migrations run > > > automagically; I'd also argue that the premise of "professional > > > developers know what they are doing" doesn't necessarily lead to "don't > > > run migrations for them", but I think reasonable people could disagree. > > > > > > In a continuous deployment environment it's not just one person deploying > > > a massive release; we may do more than one a day (although typically not) > > > and they may or may not contain migrations. It seems to me that deploying > > > with potentially explosive "pending" migrations is very dangerous & not > > > scaleable, considering anyone could then run `cap deploy:migrations` and > > > then execute *yours* - oops! > > > > > > A big point of continuous deployment, continuous integration, agile, etc. > > > is that annoying or painful things should be done more often so they > > > become less painful (via automation, etc.); having feature > > > flags/0-downtime migrations seems to be the way I'd handle "breaking" > > > migrations - relying on someone "not running :migrate" seems like a smell > > > more than a best-practice. > > > > > > In any rate, I didn't mean for my initial comment to be a feature request > > > - I know I can simply hook into after deploy; just looking for an > > > additional perspective on the matter. And I think I got it - there are a > > > lot of people out there doing different deploy methods and I failed to > > > take that into account. > > > > > > Thanks, > > > > > > -- > > > Matt > > > > > > > > > On Tuesday, January 3, 2012 at 11:56 AM, Donovan Bray wrote: > > > > > > > Because if you want to deploy with migrations there's a task for that > > > > > > > > deploy:migrations > > > > > > > > That gives you the ability to choose what's best for your situation > > > > > > > > deploy > > > > (site comes back up) > > > > deploy:migrate > > > > > > > > For long running migrations > > > > > > > > Or > > > > > > > > deploy:migrations > > > > (site comes back up) > > > > > > > > Or > > > > > > > > deploy > > > > (site comes back up) > > > > > > > > Fastest deploy when you know you don't have migrations. > > > > > > > > You can also change the normal deploy to always do migrations. > > > > > > > > before "deploy:symlink", "deploy:migrate" > > > > > > > > On Jan 3, 2012, at 8:36 AM, Matt <matt.rog...@gmail.com > > > > (mailto:matt.rog...@gmail.com)> wrote: > > > > > > > > > Hi, > > > > > > > > > > Just curious - why is the default for `cap deploy` to *not* run > > > > > migrations? > > > > > > > > > > I accept that there may be some circumstances in which you'd want to > > > > > skip migrations on a deploy (long-running migrations you'll run > > > > > later, I guess?). But, in my years of deploying many many different > > > > > rails apps, I can only think of a handful of times I've wanted to > > > > > deploy but not run migrations. And even then, it was probably best > > > > > done as a separate rake task. > > > > > > > > > > Indeed, whenever I start a new rails project I use RailsMachine's > > > > > excellent "moonshine" which runs migrations automagically. I don't > > > > > even know if there's a way to disable migration running on moonshine? > > > > > > > > > > > > > > > In any rate, it seems like it would best be done the other way around > > > > > - `cap deploy` does migrations, too, and `cap deploy:nomigrations` > > > > > does what it says. Is there something I'm missing? > > > > > > > > > > Thanks, > > > > > > > > > > -- > > > > > Matt > > > > > > > > > > -- > > > > > * You received this message because you are subscribed to the Google > > > > > Groups "Capistrano" group. > > > > > * To post to this group, send email to capistrano@googlegroups.com > > > > > (mailto:capistrano@googlegroups.com) > > > > > * To unsubscribe from this group, send email to > > > > > capistrano+unsubscr...@googlegroups.com > > > > > (mailto:capistrano+unsubscr...@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 post to this group, send email to capistrano@googlegroups.com > > > > (mailto:capistrano@googlegroups.com) > > > > * To unsubscribe from this group, send email to > > > > capistrano+unsubscr...@googlegroups.com > > > > (mailto:capistrano+unsubscr...@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 post to this group, send email to capistrano@googlegroups.com > > > (mailto:capistrano@googlegroups.com) > > > * To unsubscribe from this group, send email to > > > capistrano+unsubscr...@googlegroups.com > > > (mailto:capistrano+unsubscr...@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 post to this group, send email to capistrano@googlegroups.com > > (mailto:capistrano@googlegroups.com) > > * To unsubscribe from this group, send email to > > capistrano+unsubscr...@googlegroups.com > > (mailto:capistrano+unsubscr...@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 post to this group, send email to capistrano@googlegroups.com > (mailto:capistrano@googlegroups.com) > * To unsubscribe from this group, send email to > capistrano+unsubscr...@googlegroups.com > (mailto:capistrano+unsubscr...@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 post to this group, send email to capistrano@googlegroups.com * To unsubscribe from this group, send email to capistrano+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
