unsubscribe
On 6/22/10 6:59 AM, "Joel Oliveira" <[email protected]> wrote: 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/ ---------------------------------------------- ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email
