Thanks, Denny. These are some good issues to think about. M!ke
-----Original Message----- From: Denny Valliant [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 16, 2006 7:09 PM To: CF-Talk Subject: Re: SOT: Keeping Content In-Sync on QA and Production Sites I like CMS's over Dreamweaver Templates, so I'm sorry to hear of the switch, but the development in tiers is a way good idea. While I have played with the idea of storing "content" in a SVN repository or some such, generally when you talk of Dev / QA / Production you are talking about code, vs. content... oh, duh, it's all code now that it's in DW, never mind. Hrmmm. That's one way to keep it all versioned. Set up some commit hooks to email people when there is something to approve... But the only trouble with that is that you inevitably need some type of database to track the "approved" or "disapproved", and why. Which is really the meat and potatoes of the whole issue anyways. What people want is accountability. A log, basically, of changes, and submissions for approval, and responses. Having strict rules of who can do what is just icing on the cake. Locking down who it is you need to track down and beat the crap out of for allowing X change into the system, every time, vs. having to look it up. Six of one, really. But what's important (I've found, and this is just opinion from an admittedly poor coder) is that history/communication is transparent. - So long as you can get the "who what why where when" or whatever from any given change, you're pretty golden, pony-boy. I would recommend using a repository of some sort, and branches for your various stages of production. Maybe some email hooks to facilitate the process of communication... you'll end up using a database, basically a project management database, no matter what, so basically you'd tie in issues and stuff to the repository, and have the project drive the repository vs. the repository driving the project, if that makes any kind of sense. Tie in some logic like: change X cannot be committed to server Y unless people (or person) Z has signed off. You can really lock it down, and only allow person Z to commit to server Y, so that (theoretically) nothing can "slip by", if you will. One you have the framework, it's really up to you and the people you work with's level of comfort. Or requirements. Stuff gets driven by policy too, so maybe checkout how the current policies (approval paths, etc.) flow and try to mimic that. Well, not to concise or very helpful probably, but maybe a little, so there you go. =] Good luck, may the force be with you, :Denny ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:240760 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
