[support] Keeping dev and live site in sync

[prothero]

Jim:
Thanks, I think I've got your procedure down. Makes sense. One thing you say in the video is that while you are developing, you are regularly updating changes to your live server. I think you mean to your -dev db, don't you? That way you don't put your ongoing work into the public server until end of day when you've got everything working.

Just a suggestion: The diagrams with arrows and sequence numbers are very helpful. It would be very helpful, in your explanation if you'd give a quick overview. Like, for example: "What I do is make changes working with a WAMP local version where the db is the same name as the public version. Then, I keep 2 backups so that I have a recent public version that isn't touched, and a version that is saved from the previous day's work." 

I've done a bunch of tutorial work for students, and it helps to let them know the overall structure and philosophy before giving the details. That way any ambiguity might make sense to them.

Thanks for the video. 
Best,
Bill

William A. Prothero
http://earthednet.org/



On Jan 26, 2012, at 11:05 AM, Sohodojo Jim wrote:

> [Bill Prothero wrote:]
>> 
>> Nice video. I was trying to follow your presentation and found it a bit
>> confusing. You talked about your "Sandbox" and I wondered what db was the
>> sandbox db. Also, when you said you had a "Mirror" site, was this just a
>> copy of the live site (and its db) or was it some kind of automatic
>> mirroring system that kept them in sync?
>> 
> 
> [Jim replies:] 
> By "sandbox" I just mean the version/copy of my public site that is running
> locally on my development machine (which is also my Wamp-based server -- I
> use Wamp because it has a scriptable config/mgt system that lets me
> configure on-the-fly virtually any combination of PHP/MySQL/Apache that I
> might need based on needing consistency with various project-based configs
> -- but that is another story (needing its own webcast, actually).
> 
> On my development machine, the database that runs my local copy of the site
> is always named the same as the database that runs the live site. It
> probably isn't clear as you say -- but is obvious to me as I evolved this
> workflow and all this is automatic to me -- and that is, the X_dev and X_rem
> databases are "no touch"/"no run" copies of the database that, in effect,
> are pristine copies (never accessed other than for whole-database copying)
> of the database that support all the roll back and forth that are often a
> part of daily development.
> 
> And while I didn't make this explicit, another good feature of this approach
> is that by definition you will have a very active and flexible set of
> back-up copies of your database, including your remote live database.
> 
> Although it has been many years, I am pretty sure that one of the original
> motivations for my thinking this through and coming up with this routine was
> the number of times that my "unforced human errors" (you are too tired, too
> much in a hurry, or just not concentrating enough) have caused me more
> "gotcha" moments than any actual (hardware or data transfer, etc.) problems.
> 
>> 
>> Thanks for the info. I use Navicat, which I like and seems to have much
>> of the same functionality as SQLyog.
>> 
> 
> [Jim replies:]
> I used Navicat for a while, too, but let its maintenance/upgrade contract
> lapse long ago as I narrowed my personal choices for which tools to use. In
> that regard, the _two_ most must-have (and these are Windows-based) database
> commercial apps that I rely on daily are SQLyog -- it's pure "lean and
> clean" and would be the keeper if I had to choose only one -- and EMS' SQL
> Manager for MySQL -- it has truly amazing 'bells and whistles' features that
> I use for complex query development, ad hoc reporting, and other database
> prototyping, etc.
> 
> Regardless of the specific tool of choice, as I mentioned, the general
> strategy and tactics can be applied in varying degrees depending on your
> need and interests. I hope this info helps clarify any confusion you may
> have. And thanks for your comments. I will use this thread of conversation
> to develop clarifying content to the article on Sohodojo.biz that points to
> the YouTube webcast.
> 
> --Sohodojo Jim--
> 
> 
> -- 
> [ Drupal support list | http://lists.drupal.org/ ]