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/
----------------------------------------------
