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 :
http://www.navicat.com/en/products/navicat_mysql/mysql_overview.html

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 <j...@digitalpulp.com> 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 (
> http://ext.radiantcms.org/extensions/148-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
>>
>> ----------------------------------------------
>> http://cenatus.org/
>> http://radialsolutions.co.uk/
>> ----------------------------------------------
>>
>
>

Reply via email to