On Campus Drupal Hosting: Approved Modules

* Are clients allowed to add modules to their sites or does central IT approve all new modules requests?

Probably yes for our higher end service.

* What is your criteria for module inclusion?

In progress:
- do we already have a module that does that?
- is it actively maintained?
- what is the usage like (e.g. http://drupal.org/project/usage/realname)
-- is it in the top 100? (http://drupal.org/project/usage)
- what is its FRED on drupalmodules.com (e.g. http://drupalmodules.com/module/realname)
- what does the present issue queue look like?
- how many security advisories has it had issued?

* Do you attempt to keep modules and core updated on all sites as security releases are issued? What is your procedure?

Here are my very rough notes:

Procedures for updates

Drupal Core Update

    1. Notified of new drupal core
    2. Script
        1) download new core
        2) svn import
        3) svn commit
    3. Make any needed customizations to core
        1) e.g. robots.txt module 
    4. svn commit #customized core
    5. Puppet will discover the new core and 'svn co' to new platforms
    6. Aegir UI, each platform needs to be created
        1) TODO: automate 

Drupal Contributed Module Update (for the UCB-managed subset of modules)

    We will probably update modules 1-2 times per month.

    1. Notified of update
    2. Script
        1) download new version
        2) svn commit to all-d6/trunk
    3. If needed
        1) customize module
        2) svn commit #customizations
    4. Periodically the webserver environment directories (below) have 'svn update' invoked on them. (The test environment updates from the trunk branch; Dev from the dev branch; Etc)
        1) do this via cron (installed by puppet), or 
        2) puppet could do this on each run
    5. AegirUI: Platforms should be reverified so that they are aware of new package version
    6. Script clone_site.sh: prod --> test
        1) (invokes drush updatedb)
    7. Email all clients that had foobar.module installed and tell them to test in their "test" environment 
    (http://somesite-test.berkeley.edu)
    8. If testing fails for a client
        1) install the older module in site-specific modules directory (assuming not a critical security issue), OR
        2) uninstall module until they can fix site
    9. SVN merge tested module to all environments (dev, qa, prod)
        1) merge trunk --> prod
            command:
            svn merge svn+ssh://example.com/projects/ucb/cois/drupal/platforms/all-d6/trunk \
            svn+ssh://example.com/ucb/cois/drupal/platforms/all-d6/prod
        2) merge trunk --> qa
            a) not crucial, but be consistent
        3) merge trunk --> dev
    10. New module is deployed from svn branch to corresponding webserver environment directory
                    Client should be notified
        all updates should be deployed as a new Aegir platform
            "batch forward merging": uncomplicated merge.  everything that happens trunk happens. 
            don't pick and choose files to merge trunk --> prod

            platform name: prod 6.16-292 <--specific revision
            then you can hold people back simply by not migrating their sites.  and it's easy to tell who's been held back






SVN Branches and corresponding webserver environment directories:
svn branch  site environment    path to managed modules dir (symlinked)     environment purpose 
trunk           test                    platforms/test/all-d6                           Security upgrades tested here. 
dev             dev                     platforms/dev/all-d6                            Client's dev environment 
qa          qa                  platforms/qa/all-d6                             Client's qa environment 
prod            prod                    platforms/prod/all-d6                           Client's prod environment