Dev/Live workflow whilst a client edits live via CMS
Hey there,
I am getting close to a really useable workflow, development/live server setup.
Live is a checkout from bzr version control. I do a bzr up to update css/themes on the live server. The client makes changes via the CMS which affect the database only (well also /files dir for uploads but so far this has not been an issue).
When we make substantial changes to the site, which will involve both filesystem and database changes via the dashboard, we do a live->dev db import and commit any changes from live. We do a bzr up on our development server, making it an identical copy of the live site.
We make our changes on our development server, send them to clients for proofing, then do a dev->live db import. However during this development period we need to ensure that the client isn't making any changes via the dashboard, as they will be lost when we import our db from dev.
Our practice at the moment is to email all a site's editors, explaining that we are making changes, and anything they do will be lost during this period. We then email again when we are done.
This essentially works but it is a little crude and prone to failure. With a distributed team of developers, emails to clients get forgotten, or the client hasn't read the email and goes off to edit their site.
A better solution would be to add a button to the admin CMS, maybe under maintenance, which will lock out all users in the Editors group. Then if our client goes to login to edit their site via the CMS, they will see a message explaining that their web design company is making changes. An automated email would go out to everyone in the Editors group when an admin ticks this checkbox, and again when unticked to tell the client editors that they can resume making changes to their site via the CMS.
This functionality would ensure that we never ran into a situation where a clients edits where lost.
Would be good to get people's feedback on this issue, and my proposed solution.
Another idea I had was to have like and "export" button on a page. This would create some kind of text file with the instructions on how to create a page (with all the blocks, permissions, etc), but not in sql (to avoid duplicate ids in the db, etc)
Then you would go somewhere in your live site and import the page.
I'm just wondering if you solved your problems. We're having similar issues managing edits to both the DB and filesystem, going through proofing, deployment, etc., and I'm trying to figure out a better workflow with less possibility of mistakes being made.
Then you would go somewhere in your live site and import the page.