Rolling out on a clients host

Drupal requirements:

* DNS hostname/ip
* Email
* Mysql
* Apache

Timeline

As soon as the client 'ok's the project (even before development starts) you can start organising:

* PRE-rollout: DNS hostname/ip
* PRE-rollout: Email
* PRE-rollout: access to the server
* PRE-rollout: mysql
* PRE-rollout: apache access
* PRE-rollout: system tweaks
* PRE-rollout: setup a dev site

As soon as there is any kind of development site

* PRE-rollout: test rollouts

Then:

* PRE-rollout: dev site is working?
* PRE-rollout: test rollout!!
* Actual rollout!!

PRE-rollout: DNS hostname/ip

Timetable: immediately after client agrees to contract

A drupal site needs a host (with an IP address) and a site name (DNS entry).

Tickoff:
* can you 'ping sitename'

PRE-rollout: Email

Timetable: immediately after client agrees to contract

Drupal needs to send email notifications. You want to avoid issues covered in [Email_Bounce_Issues]]

There might be issues with the DNS MX records too.

This might also include playing with the drupal mailer module.

Tickoff:
* you can send an email as your drupal user (apache@site or no-reply@site)
* you can send an email to the client's domain (to check for issues in [Email_Bounce_Issues]]
* you can send an email to cf.com's support address (sysadmin)
* what happens when you reply to the drupal user

PRE-rollout: access to the server

Timetable: After client agrees to contract (way before rollout date, atleast 2-4 weeks before rollout)

As the rollout approaches we need 'shell' access to the server to install the files and load the database. (This is usually done with an ssh key and probably requires some intervention by the remote site admin.)

(It can be done via ftp, but it is like trying to operate a puppet in boxing gloves.)

Tickoff:
* Can we log into the server? Are marcus and cam happy?

PRE-rollout: mysql

Timetable: After client agrees to contract (way before rollout date, atleast 2-4 weeks before rollout)

Drupal stores it's nodes in mysql, so we need to load the site into the msysql database. To do this we need the remote site admin to create a database in mysql.

Note: we dont need remote mysql access (no phpmyadmin or remote ports), we do it all via the shell access.

Tickoff:
* What are the mysql username, password and database details?

PRE-rollout: apache access

Timetable: After client agrees to contract (way before rollout date, atleast 2-4 weeks before rollout)

Apache serves drupal's php out from its directories. So we need apache configured for the site to serve our from a directory on the host.

We need access to that directory to install the drupal files into.

Tickoff:
* Can we chuck an index.html file in and view it on the site?

PRE-rollout: system tweaks

Timetable: atleast 2-4 weeks before rollout

XXX: Patch php.ini for more memory.

XXX: Patch my.php memory limits.

Tickoff:
* Are the dev's happy with the settings?

PRE-rollout: setup a dev site

Timetable: As soon as the client says 'make me a site'!

Tickoff:
* Do the sysadmins have accounts with admin?

PRE-rollout: test rollout

Timetable: As soon as there is any kind of dev site, way before rollout time.

Build a rollout plan from doing a test rollout and documenting the process.

Rough steps to migrate the site:
* copy the mysql database from the dev to the server
* copy the files from dev over to the apache directory
* fix the mysql in settings.php (mysql username, password and tablename)
* test drupal
* set drupal hostname in config, set email address
* test email notifications work as expected

NOTE: This is a test rollout, everything can be nuked as it will be overwritten when the site is finally rolled out.

We should have a process to take the dev site and clone it over to the live site.

Tickoff:
* The site is up and looks like the dev site?
* Can you add / delete content and do everything else?

PRE-rollout: dev site is working?

Timetable: before test rollout

Is the dev site done? Dont roll out before the dev site is done.

Tickoff:
* cf devs have signed off on it? (shouldnt get to here if they are not)
* cf admins are happy?
* cf managers signed off?
* client signed off?

PRE-rollout: test rollout

Timetable: 1 week before rollout

We should already have done a couple of test rollouts, so we should have an idea of how the process will go.

NOTE: This is a test rollout, everything can be nuked as it will be overwritten when the site is finally rolled out.

With the test rollout working, everyone should test the site and see that everything works as expected. This is a finfal

Tickoff:
* cf admins are happy? (shouldnt get to here if they are not)
* cf devs have signed off on it? (shouldnt get to here if they are not)
* cf managers signed off?
* client signed off?

Actual rollout

At this stage:
* we agree the dev site is 100% working
* we agree the test rollout worked too
* we have a plan/script for migrating from dev to live

So we run through the plan that we developed in the test migration.

Notes

mysql setup details

This is for our own reference....

We create it with:

# Create the database....
echo "creating $SITE_MYSQL_DATABASE"
cat << CREATEDB_INSTRUCTIONS | mysql
CREATE DATABASE $SITE_MYSQL_DATABASE;
ALTER DATABASE $SITE_MYSQL_DATABASE DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
FLUSH PRIVILEGES;
quit
CREATEDB_INSTRUCTIONS

/usr/bin/mysqladmin -u root reload

# TO allow user access to the database (sets the default password to munkies)
cat << CREATEDB_INSTRUCTIONS | mysql
use mysql;
GRANT ALL PRIVILEGES ON $SITE_MYSQL_DATABASE.* TO '$SITE_MYSQL_DATABASE'@'localhost' IDENTIFIED BY "munkies";
FLUSH PRIVILEGES;
quit
CREATEDB_INSTRUCTIONS

# TO set the password to a human string ($PASSWORD) then do...
cat << CREATEDB_INSTRUCTIONS | mysql
use mysql;
update user set password=PASSWORD("$PASSWORD") where User="$SITE_MYSQL_DATABASE";
FLUSH PRIVILEGES;
quit
CREATEDB_INSTRUCTIONS

---