unsubscribe

On 6/22/10 6:59 AM, "Joel Oliveira" <joel.olive...@gmail.com> 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 <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/
----------------------------------------------




______________________________________________

See  http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email

Reply via email to