My workflow is similar to Josh's.  I keep all layout, css, js, etc on the
filesystem with "file-system-resources" as well - works like a charm.

All data sits up on a staging server where my clients input all their data,
content, images, etc.

I pull down that content and data with git (for images and assets) and
Navicat to pull down certain tables from a MYSQL db.  Navicat costs money
but it's a great investment as I no longer need to muck with versioning
mysqldumps, etc.   I just connect to staging via ssh+mysql and do a data
transfer of the tables I need.

For more info :

As far as gui clients this one is a winner, I can assure you.  I'm more than
happy with using the command line client but the tools available via navicat
are a tremendous time-saver.

- Joel

On Tue, Jun 22, 2010 at 9:36 AM, Josh French <> wrote:

> I suspect the full answer involves getting your colleague to work with
> actual source control, but here's our general setup:
> * Multiple local development environments
> * A local staging server
> * Maybe a second staging server on the client's end
> * The final production server
> We've got a few cap/rake tasks that help us manage the flow. Generally,
> code (extensions, markup) only moves in one direction, from local up to
> staging/production. Data (page content, config settings, &c) only move
> downhill, from production/staging to local.
> Something like File System Resources (
> might help
> you draw the line between code and data. We've used extensions like
> super_export and I've come to the conclusion that trying to version the
> entire database is just asking for trouble. FS Resources lets us focus on
> what we can safely version (markup) and avoid the hassle of what we can't
> (page content.)
> So our daily workflow might be something like:
> * We all pull down the staging or production database (depending on if
> we're pre- or post-launch)
> * I fix some bugs in an extension
> * At the same time, my coworker is working on the layout & css, both which
> are all stored on disk via FS Resources
> * Independently, we push our changes to staging
> * Staging gets QA'd
> * The day's build is pushed to production
> Nothing we've done overwrites any DB settings or content on production.
> Conflicts are a less likely, and the things that are liable to conflict are
> all under source control so you've got a safety net.
> Hope that helps,
> j
> On Jun 22, 2010, at 8:27 AM, Matt Spendlove wrote:
>  Hi all
>> My current workflow is this:
>> 1) dev locally
>> 2) rake db:super_export
>> 3) svn commit
>> 4) cap deploy - to test server
>> 5) rake production db:super_import - on test server
>> I'm working with another colleague who's largely focussing on
>> layouts/css. He doesn't have a local installation so has been working
>> directly on the test server - that doesn't really effect the issue
>> though. I occasionally checked in with him and backed up, versioned
>> and locally installed his changes from test.
>> Mostly his changes were fairly superficial so it largely worked. I
>> guess you can see what's coming, the other day we got stuck in
>> conflict hell and had to redo changes, lost pages etc.
>> Clearly, this process won't really work, perhaps the point here is
>> that we're just supposed to share one installation, wiki stylee?
>> I guess if I separated out "structural" work locally (extensions etc)
>> and just did layout/presentation work on test things would be a bit
>> safer..
>> Anyone else out there got a better working practice?
>> Cheers
>> Matt
>> ----------------------------------------------
>> ----------------------------------------------

Reply via email to