My developers in a project want to have the dev db on dev server synced with live db on live servers, which I think is a bad idea. Despite that, what is the best way to deploy a codebase+db to live? So far I use rsync for data and simple export/import for the db. The final setup consists of a dev server and 2 Live server (one in US, one in Europe, for HA/LB). MariaDB Cluster was proposed, but I am not sure if I want to introduce multi-master replication in this setup. Especially since the 2 Live server are separated that much by distance. Furthermore I have to somehow manage to provide them with an up2date live db for the dev server because the development obviously can't push the db to live when its old (then there would be missing entries in the time in between export/import). Maybe I am not seeing the trees in the forest here and its rather simple. What do you guys propose I should do?
-
2Go the other direction: take snapshots of prod, clean them of personal data and anything else they should not have access to, and provide those to dev.– Michael HamptonNov 27, 2015 at 9:54
-
2It's a fairly common requirement to frequently sync the prod database to dev, so that development is proceeding against something approximating reality. But the other way around? Not sure I've ever seen that. Definitely wouldn't do it; I foresee a disturbing amount of time spent recreating the prod db from backups.– MadHatterNov 27, 2015 at 9:54
-
@MadHatter I know right? The issue is that whenever they change something on the website (drupal base + custom other backend) there are changes in the database, so if you push only codebase changes then it wouldnt work from what I am told.– pdanjouNov 27, 2015 at 10:16
-
Drupal schema migrations are straightforward; if they've used Drupal's API properly then there should be no problem. If they haven't... then you get crazy requests like this.– Michael HamptonNov 27, 2015 at 11:32
-
@MichaelHampton the problem is that there is another php backend integrated into the site that is interconnected with drupal codebase and database but in itself also has its own codebase and database– pdanjouNov 27, 2015 at 12:26
1 Answer
Since this beginning to turn into an exchange of comments, I thought I'd write it up properly.
Firstly, it's a fairly common requirement to (frequently) sync the prod database into dev, so that development is proceeding against something approximating reality. But the other way around? I'm not sure I've ever seen that, and I definitely wouldn't do it.
You are right to note that often schema or db content changes require updates to the prod db to coincide with code changes that are being rolled across from development. But a sane release process handles that by developing procedures to update the schema, upload new content, and/or modify existing content, and deploying those procedures at code publishing time.
In the best-regulated environments I've worked in, the changes are literally scripted - a lengthy change-test-response document is produced by one developer, saying in painful detail what must be typed, what will be seen, how it should be tested, and what results are required. The script is signed off by a second developer, to confirm it's been tested against a clean test environment, and executed by a third developer, who has not worked on the process. This ensures that noone tries to get clever, and go off-piste when something odd happens. Often, a fourth developer will co-sign the script, to say that (s)he has confirmed everything that was claimed to be seen and done.
The script also specifies a tested back-out procedure, and this is executed by the third developer if at any point the responses do not match what the script says to expect. If the whole procedure passes muster, the prod environment is usually resynced into the dev and test environments.
I'm not saying that that entire process is appropriate for your environment; only that it is for some people. But you seemed to want to know how schema and content changes are handled other than by blindly syncing dev into prod, so I hope this sheds some light on that. If you do end up deploying by syncing dev into prod, make sure your backups are up-to-date, and your restore procedures are well-tested. You're going to need them.
-
-
Doesn't stop you putting in writing to management that you advise strongly against this scheme, and then letting them know each time prod is down because the dev sync accidentally stomped over the last 4,000 customers, and they all have to be restored from backups. Again. Eventually, some management teams can take the hint. Nov 27, 2015 at 12:28