Drumbeat/website/deployment plan

From MozillaWiki
Jump to: navigation, search


Drumbeat Alpha Web Site: Deployment Plan

The goals of the Drumbeat.org ALPHA web site are to:

  • Get an early iteration up quickly. Focus on feedback and improvement rather than getting it perfect.
  • Provide an early means for us to display Drumbeat project content and enable contributions from the public.
  • Work with our community of designers and Drupal developers to improve on and hack against the alpha site. Community members have already expressed interest in helping with QA and are waiting to start.

Drumbeat.org Deployment Plan

Steps 1 - 10 complete

11) UPDATED: Fix mail server and SSL bugs

  • WHEN: Feb 17
  • GERV: will own & co-ordinate with IT to debug.

12) Matt & Gerv do final QA on staging site

  • WHEN: Feb 18
    • Matt & Gerv triage bugs and assign priority
    • Matt reviews blocker bugs w. Mike Haggerty 12:30pm EST

13) Set outgoing mail address

14) Fix donation functionality

15) Get Gerv shell access to staging server

16) Check out Trellon update from SVN

  • WHO: Jeremy Orem
  • WHEN: Feb 18

17) Update DNS

  • WHO: Doug Isenberg & Gerv
  • WHEN: Feb 23
    • TASK: Doug updates DNS
    • TASK: Gerv to QA DNS update and confirm complete

18) Complete production server set-up

  • WHO: Jeremy Orem
  • WHEN: Feb 23
    • TASK: Gerv / Matt: Get status update from Jeremy
      • When does he estimate completion?
    • TASK: Gerv will file comment in bug to update Jeremy on next steps, below

19) Halt data entry to staging site

  • WHO: Matt
  • WHEN: Just before Jeremy ready to perform step 20
    • Temporarily turn off staging site. Notify users of temporary down-time for production.

20) Re-migrate the staging database to production

  • WHO: Jeremy

21) Re-configure production site

  • Database re-migration will require some re-configuration
  • WHO: Jeremy

22) QA on production site

  • WHO: Gerv & Matt
    • Check critical functionality (outgoing mail, donate, project creation / join, etc.)
    • TASK: Matt: pull list of configuration bugs from staging server to re-check in production

23) Launch drumbeat.org alpha site

  • WHO: Matt




25) Staging server site turned back on

  • WHO: Matt
    • TASK: Update staging site header to clearly indicate "staging site only"

Renumber below:

21) Community QA on alpha site

  • WHO: Community Members (Carlo / Paul Booker / Ned Schwartz, etc.)
  • WHEN: ~Feb 1 onwards, in parallel

22) Community members install local copy of code

  • WHO: Community
  • WHEN: Any time after documentation provided

23) Community members attach patches to bugs

  • WHO: Community
  • WHEN: Any time after documentation provided

24) Changes approved by site code owner

  • WHO: Paul Booker? (community member)
  • WHEN: As part of normal development process post-launch

25) Changes pushed at intervals by IT to staging server for testing

  • WHO: IT, prompted by a filed bug
  • WHEN: Schedule depends on what has been developed and bug fix urgency

26) Changes tested on staging server

  • WHO: Community QA, developers
  • WHEN: After changes make it to staging server

27) Changes pushed to production server

  • WHO: IT, prompted by a filed bug
  • WHEN: Weekly or fortnightly is usual

Deployment Stakeholders

Mozilla Foundation (MoFo)

  • Matt Thompson -- Drumbeat project manager
  • Gerv Markham -- liason with Mozilla IT & QA teams

Mozilla IT

  • Matthew Zeier -- IT team manager
  • Chris Lyon -- security reviewer
  • Mike Morgan -- WebDev
  • Jeremy Orem -- server configuration

Trellon

  • Mike Priest -- Trellon's tech lead
  • Campbell Vertesi -- Trellon project manager

QA

  • QA will be provided by Drumbeat community volunteers
    • Ned Schwartz, Paul Booker & Carlo Frinolli

Questions for Mozilla IT

  • QUESTION (for Jeremy): Can production server set-up happen at same time as security review?

For Chris Lyon:

  • What are the security review requirements for changes and updates made to the site after alpha launch?
    • e.g., When our community QA resources spot problems, do the fixes & updates need to go through security review again?
  • Frequency of change requests
    • How frequently can we make changes and updates? How do we follow correct protocol and avoid straining existing processes?

Draft documentation from Trellon

  • Drumbeat.org uses the same codebase as Mozillians.org, but with a significantly changed database.
  • Trellon will be providing the updated database(s) - drupal and civicrm.
  • One thing that isn't covered below is order of operations. This will be included later though.

Server configuration

PHP 5.2 - config tweaks: memory_limit = 128M, max_execution_time = 300, upload_max_filesize = 8M (or your preference - affects file uploads to the site) - libgd2 for image manipulation - pecl module "uploadprogress" for enhanced ajax uploads - sendmail support

Apache 2 - mod_rewrite enabled - provides clean urls (/nice/path instead of ?q=not/so/nice) - php5-memcache - provides OO and procedural interfaces for php5

MySQL 5 - mysqli connection method - innodb - 1x database for drupal, 1x database for civicrm - Modify connection strings in {Drupal root}/sites/default/settings.php and {Drupal root}/sites/default/civicrm.settings.php

Memcached - /usr/bin/memcached -m 2048 -p 11210 -u {apache user} -l 127.0.0.1 - Check settings in {Drupal root}/sites/default/settings.php match (port)

Apache solr install - {todo}

Drupal cronjob


File system settings

- boost module Boost module maintains a page cache here, which dramatically improves performance for anonymous users. Modify the "cache" folder in the Drupal root apache writeable, other readable. Copy the settings generated at http://{drumbeat staging url}/admin/settings/performance/boost-rules into {Drupal root}/.htaccess over the existing #Boost rules section.

- Drupal file upload folder: modify "sites/default/files" from the Drupal root apache writeable, other readable.


Web UI settings

- GMap api key - for geo locating. Configure @ admin/settings/gmap

- Flickr API key - for flickr widget. Configure @ admin/settings/flickr


Other issues

- Moving CiviCRM database from staging to live. Clear the CiviCRM configuration from the database - which is rebuilt automatically from {Drupal root}/sites/default/civicrm.settings.php UPDATE `mozcrm_civicrm`.`civicrm_domain` SET `config_backend` = NULL WHERE `civicrm_domain`.`id` =1 LIMIT 1 ;

Retrieved from "https://wiki.mozilla.org/index.php?title=Drumbeat/website/deployment_plan&oldid=204157"