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 <[email protected]> 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/ >> ---------------------------------------------- >> > >
