How to deploy a large site CMS

Question

I am managing a site with PHP cms.
The site is really big (250 pages) and critical.
There are always 6 translators and content editors working on the site in parallel.
Till today, the CMS worked as out if the box and we did not have to many changes to deploy.

Now we want to start and update the site themes more often, add content areas add more modules to the CMS.

For the deployment action I can block the access of the content editors and do the update but this is not the problem.
The problem is when I want to develop new features the the development time will be long (like a week or a month).

During the time of the development, the content will be massively changed.
In 95% of the cases, a cms upgrade will be involved with database structure and data change.
So, how can I update the site version/data/metadata without loosing or damaging the work that has been done on the site during the development

(We do have a development server and staging server with their own databases, with subversion)

It does not really matter, I am using Concrete5.

Thanks

Update 1
Let's just assume that I have a field in my site named page_title, and I want to change the name to page_description.
The change is actually happening in the database content and not in the database structure.
So I can change that on the dev environment but I have no way to deploy that to the production.
First, because I have no idea where the changes are actually happening cross database.
Second, even if I have a script that will change it in the database, it is almost impossible to track that changes and add it to a script.

Answer 1

I've not yet found a version control system that handled databases to my satisfaction, although RedGate has some SQL versioning products that might be worth looking into. What I've always had to do when making structural changes to the production database is hand-write an SQL script that makes the necessary changes while preserving existing data - and, naturally, test the upgrade scripts on the dev server if they are at all complex.

Answer 2

As a matter of professionalism, I would recommend to take the time to setup a local development mirror and use that as proving grounds for all the changes you make.

I recommend using a versioning system when working on the code, so you may track the changes you have made on top of the original code.

To save yourself a lot of trouble I would really recommend you take the time to note all running software and versions before creating the mirror.

Alternatively, you can create a subdomain on the server and load a duplicate of the site into that domain. Be sure to use a shadow of the database in that case!

Once an application is finished, block the sites access and copy the files to the live server. Downtime shouldn't be more than an hour or two.

Answer 3

Two recommendations:

1. Always do your development on a different code base then the production version. Ideally, you'll have a separate database and CMS instance for your own development and once it has been tested and approved you'll back up production and migrate the database and the code.

2. Always have all your data migration tasks in a consolidated script (or set of scripts). You should also have upgrade/downgrade versions of the scripts (which you test really well) so that you can revert quickly to a previous version of the database.