Drumbeat/website/proposal

1) Dev / Staging / Production

Drupal has some limitations in terms of how content moves from dev to staging to production. Certain features available through the web based administrator on production are going to have an impact on how people working on the site at the dev level. We need a plan for how to address this. I wanted to propose a purely mechanical solution for how to handle this:

• establish three levels of deployment for the site (formally): dev, staging and prod
• the production database gets mirrored on staging each night. this allows changes to migrate down where necessary
  • I see one problem here and that is when we come together to look at something on stage. An automated mirror of the production database on stage could potentially destroy configuration of modules etc being reviewed at that time. My thinking is that configuration changes should be going from dev > stage > production so that the only differences between all three environments at any time is content (nodes,comments,taxonomy,..) so what may be better is to update our dev databases daily with a copy of production and make a request on bugzilla to update stage with a copy of production only when were ready to come together to look at something. [booker]
• changes to the database, content types, etc occuring on dev get migrated up to staging then to production using Drush, which is a command line tool for Drupal

This is rudimentary and there are additional Drupal modules that can be added to the stack to facilitate this. I wanted to get down a basic map of the road for now, since deployments can be challenging. I am interested in hearing anyone's comments.

2) Simplifying & sanitizing local install

Certain features enabled on prod are going to create issues for people trying to stage the site. For instance, users are forced to login through SSL, but not everyone working on the site will have SSL on their dev environment. Also, user account privacy is clearly a concern. I would like to create a packaging script for anyone working on the site that clears out and problematic settings and anonymizes any data people will need to work with user information on the site. I would like to get a list going of all the settings that need removing before copies of the site can be distributed.

The list I started over the weekend includes:

• remove database usernames and passwords from settings files
• change firstname, lastname, email, phone, addresses, etc for all contact records
• change all user account passwords in the packaging script to a single hash
• remove all donation information - completely unnecessary for people working on the main site
• disable modules forcing SSL login
• distribute alternate .htaccess file (which also enforces SSL login)
• disable multisite, reassign drumbeat as primary domain in mozillians' code
• remove mozillians code

There are additional items to discuss that are not appropriate for a public forum.

Notes, Question & Discussion

• Paul Booker has a sanitization script from script from spreadfirefox
  • Paul and Michael to co-ordinate via email
  • http://svn.mozilla.org/projects/spreadfirefox.com/trunk/clean_db.php

3) Install profile

Trellon has started working on an install profile for the site. Install profiles are installers for Drupal that will set it up with a set of preconfigured modules / themes / properties. In general, an install profile can be used as a method for distributing working copies of a site without the need for some of the packaging stuff I discussed before.

Writing an install profile for Mozillians is going to allow people to download a copy of the site without needing to download all of the data that goes along with it. Giving some thought to Drumbeat specifically and how it differs from a generic, product based installer, there are some things I am considering that I would like to get some input on:

• packaging the latest version - changes to content types and other parts of the admin interface are going to make any install profile obsolete quickly. It may be useful to write a packaging script specifically around views, content types, and blocks.

• • Would you say that packaging a release will be best suited for when we have a configuration of our modules / themes that were looking to to hold fixed for a time ? We will probably need to look at how we will do versioning / branching but i imagine we will want some thing along the lines of a production branch which is only accepting bug fixes and and a development branch where we will be introducing new modules, .. a snapshot of which will later become the next production branch [booker]

• data - any install profile is going to benefit from some sample data. It would be useful to get a conversation going around what data would be safe to distribute.

• • I would say come from the other direction and consider what data needs to be anonymized as you mentioned in (2) . To your list i would just add nodes / comments [booker]

• multisite - removing multisite features from an install profile (or making them optional) would make this a simpler site to support

• optional features - there may be developers who want to work on this without all the features enabled, to focus on a specific part of the site without the overhead of additional components (CiviCRM, for instance, carries some overhead with it that may be challenging for someone developing on an older laptop). I would like to get a conversation going around what the conceptual areas of the site are, and how we could give people the ability to be selective in what they deploy.

• optional features / additional features - we have written a lot of install profiles. Something I would like to talk about is dropping in some support for internationalization, alternative displays of content, AJAX components, etc for people to play around with. While these might not be features of the core platform just yet, I can see how they would add value to Drumbeat over time. Wondering if there is any opposition to tricking out an install profile just a bit.

Notes: 1) profile file 2) modules 3) data

---

Bugzilla

• challenge for them: priority of tasks there
• Michael: bugs that want Trellon to fix: assign to Campbell Vertesi
• (Remove Trellon staff from default mail)
• "watching" another user / QA contact:

Some possible alternatives to setting up drumbeat on a developers local server [Paul Booker]

• Having access to a personal stage server www-stage.paulbooker.drumbeat.org etc
• Having access to a remote desktop at Mozilla with a local server running drumbeat