Re: [Fab-user] Any interest in extension to support getting things from source control?

[Jeremy Katz]

On Fri, Oct 9, 2009 at 1:34 PM, Jeff Forcier <address@hidden> wrote:
> On Fri, Oct 9, 2009 at 11:21 AM, Jeremy Katz <address@hidden> wrote:
>
>> For one thing, if you want to be able to reliably handle errors, run()
>> isn't going to be feature-ful enough unless you're wrapping some sort
>> of shell scripting.
>
> Have you used the version of run() in the 0.9 beta (as opposed to the
> 0.1.x version)? Just curious, I added a bunch of small things that
> make it much easier to interrogate a run() or sudo() about its return
> status and such. If that's not enough, I'm all ears for ways it can be
> further improved.

Return status is always a little perilous to depend on in my
experience... I haven't extensively looked at the changes in 0.9 there

>> With the right level of abstraction,
>> that could be mostly a no-op from the side of our deployment scripts.
>
> I'm torn on the "abstract SCM operations" point, partly due to the
> work I've done on experimental Trac/Redmine type software. It's a
> great idea at the very highest level ("obtain X tree from Y source
> server") but as soon as you enter the zone that differs between
> centralized and decentralized SCMs (mostly anything to do with
> branches), it gets very hairy and you have to start making a lot of
> assumptions.

Yeah, it's definitely a possible minefield.

> That's not to say I don't want to go that route -- just that I
> hesitate a bit. I personally think it'd be best to have per-SCM
> modules which share as much API as possible but diverge where
> necessary.

And this is a reasonable way to avoid the minefield :)

>> I'm not 100% decided that Fabric is the right tool for our needs, but
>> I have a strong leaning towards trying to reuse and build on top of
>> existing projects rather than starting from scratch
>
> And the FOSS world needs more of that attitude vs knee-jerk wheel
> reinvention, so kudos to you :) (Ruby/Capistrano folks might say I'm
> on shaky ground with that statement, but that's another discussion.)
>
> As mentioned, I'd like to try and get Fabric to a spot where it's
> legitimately useful to a lot of people  without getting top-heavy with
> too many features. We'll have to see if that's doable, but I'm
> optimistic.

*nod*  Having an extensive contrib is definitely a good way to go for
that and it also gives a way to start testing things, seeing if they
"fly" and if they prove awesome, then they can move out of being just
contrib and being more core.

>> * Reverts to ensure no one screwed with the code on the remote box and
>> avoid needing a merge
>
> Just curious -- how do you deal with the (awful but common, IME)
> situation where the un checked in code needs to be preserved or merged
> in?

We ignore it entirely for better or for worse.  It's one of the areas
that I sort of want to eventually improve what we do, it's just lower
on my list of priorities at the moment

>> * Logging to get commit log messages.
>
> What do you do with this information exactly?

We send out emails for successful deployments and being able to show
what's changed since the last deployment is incredibly helfpul.
Especially when something breaks.

- Jeremy