Deploying with DBScripts

Make sure you are on your master branch:
cd /path/to/project/root
git checkout master

Update your own version. Try to do it at a time when no one else will be committing. (You can check that you don't have any committed but not pushed changes with gitk &.)

./scripts/fetch_rebase
[This script combines the commands git-svn fetch and git-svn rebase for convenience.]

(It is possible for there to be a permissions error here, you can nuke it with sudo chmod -R 777 drupal/sites/defaults/files/. After a change like that, be sure to commit everything again.)

./dbscripts/restore.php

Now, test around the site -- a thorough test. Ensure there have been no regressions.

Log into the live server and check on how it's doing.

ssh example.org
cd /var/www/example
svn status

If there is anything modified in the databases directory, that is a problem. It is configured to every night dump itself and commit itself, listed modifications means this failed. As long as they are there you can't dump or commit or anything. Revert everything, and then run an svn update on databases production.

(Only if necessary due to modified files in databases directory.)
./scripts/svn_revert databases/production && svn update databases/production

Once svn status is clear of modifications in the databases/production directory, you are ready to begin the merge and deploy process.

On the live site, go to mode at admin/settings/mode. Change to Read Only.

That stops everyone else from doing anything that modifies the site's database. Don't you click anywhere on the site either.

Now dump the production database.

./scripts/production_dump

(This script wraps stopping and starting the Apache server around ./dbscripts/dump.php production min.)

Check the subversion status, and confirm that things make sense .

svn status

And commit the production changes:

./scripts/svn_add_delete_files
svn commit -m "Production database dump and file repository update."

(Still on the production server here. That same commit message works every time!)

Troubleshooting if the commit fails, one thing that came up:
svn: Commit failed (details follow):
svn: Directory '/var/www/pdonline/drupal/sites/default/files/imagecache/node_image_200/.svn' containing working copy admin area is missing
As this was in imagecache, deleting and then svn updating in that directory resolved this issue.

Back to your local working copy. Grab the changes you just committed from production.

Again, this is back on your local environment.
./scripts/fetch_rebase
./dbscripts/merge.php

80-90% of the time the merge just works.

After a successful merge, you bring up git-gui and see what exactly happened.

git-gui &

Stage to commit and unstage what you don't want.

Try to familiarize yourself with what happened. If you don't understand a change, look into it and figure it out.

Use gitk for that.

You have to make sure that all the deleted files are -new.

And make sure you know why a file is deleted.

Go through variables table hunk by hunk (have not yet updated dbscripts to do line-by-line merging on this table).

For instance, settings changes regarding the contact module, site administrators have permission to edit the contact form on the live site, so preserve it-- do not commit that hunk.

If it looks like a configuration setting and no one else set that, let that go from development to production.

(With the variables table we are blatantly overwriting production.)

Knowing what is done where is crucial.

Go to trac, and click on annotate (aka svn blame on command line)
it will take a while.

See what commit changed:

This line was introduced in r1749.

The last deploy was r1739.

Therefore that change was made in production.

Check for structural changes, the autoincrement changes.

The two changes we decided not to keep-- go and revert in git-gui.

Now we have to deploy that reversion to the other two versions.

In this case, what we reverted was the path_redirect table.

A legacy custom module stores some user information in the variables table. If that user had been deleted in production, it would come back and have a + and be colored green, symbolizing addition.

The deletion means that it was created in production, didn't exist in devel and was deleted by the merge.

same cp as below for variable.sql after you commit the part you want, and revert the part you don't.

On the command line:
cp databases/production/data/path_redirect.sql database/last-merge/data/
cp databases/production/data/path_redirect.sql databases/development/data/

You have to know why every change was made. and if you don't know why, look it up.

You can have database merge
and then have fixing what it was, as a second commit
so that we can review it later.

Merge means they should all be identical.

Once in a blue moon, something happens in development that looks weird.

in this you can see

rewritten to 19,69 from 1,69

go over each one and look at it like you did in production.

Probably don't have to go over last-merge.

You can commit now if you want.

In either case, after you've done a merge, and have everything staged.

to fix a bug in DBscripts here you have to run thsi.
./scripts/restore_dump
this puts the auto_increments back [and some other things]
"this is really just me being anal"

it has reorderd things into the correct order.

Once I saw an other error. a couple other places where the

DBscripts should be writing the right autoincrement here, but it's not.

Since we dumped and restored each one, what you have right now is development

And then I run cron. This is also compensating for not being fully featured in DBscripts yet.

First cron runs a while-- I pointed out that it's due to search data

So you can also run:

./scripts/testing_restore

which should restore the production-only data.

In Kathleen's normal workflow, nothing is not committed yet, everything is just staged. But committing earlier in stages is ok.

advanced_help_index is a common change

that's why we run cron

even if you grabbed an RSS

still some autoincrement things that shouldn't be changing and are, but we stage.

Do another restore dump
./scripts/restore_dump

database merge, ran cron

and you kill anyone who committed while you are gone. Which someone did.

Now

git-svn dcommit

Now we are on the production server and do an SVN update.

svn update

It's been in read-only mode.

Verify that it is STILL in read only mode for sure.

./scripts/production_restore

(this stops the web server, restores the database, and starts the server again)

Now, in mode, you move it from Development mode to Production mode.

Now you write a report! Of everything that has changed from the last merge to this one.

Resolution