IT/Production Acceptance/PartnerRepacks

From MozillaWiki
Jump to: navigation, search

Automated Partner Repacks

Note: This project has also been referred to as "Low Touch Infrastructure Plan" and the "Automated Build System for Partnerships".

Start of project

  • Project sponsor: Kev Needham, Business Affairs
  • Main IT contact: phong
  • Main WebDev contact: Mike Morgan (final contact TBD)
  • Main RelEng contact: Chris Cooper
  • Main QA contact: Carsten Book (Tomcat)
  • Final application owner/maintainer: Release Engineering (to be confirmed)


Overall goal of the project

Our current infrastructure and resource allocations allow for limited scaling of creating, testing, and authorizing customized versions of Firefox for redistribution by partners. Distribution creation, QA, and signing is a manual process, and the Automated Partner Repack system's primary goal is to automate as much of the current process as possible, and to provide a web-based front-end for creating and managing those distributions. The system's secondary goal is to provide an automation framework that can interact with third party systems and/or Mozilla services to facilitate the creation and distribution of customized builds by Partners directly.

There are three initial components that are required for this project, which include:

  • A distribution generation system that stores information about multiple individual builds (partner and configuration information) in a central repository (i.e. an rdb), and can create customized distributions of Firefox based on that information on-demand or automatically (e.g. triggered by a general release). This component will form the framework for applications and/or processes that generate customized distributions.
  • A web-based administrative front-end that allows Mozilla to manage (add, modify, delete) the information stored about Partners and their customized distribution(s), and generate builds on-demand (initiated by Mozilla) or on release (initiated by a point release).
  • A web-based public facing front end that will allow participants in a specific program/initiative to register and (on approval) generate a customized distribution with a limited set of changes.

Following successful completion of the first two phases, planning would begin for follow-on development work. In an ideal scenario components such as automated Minotaur testing and AUS2 channel creation and management would be integrated. We'd also look to expand upon phase III - dependent upon its success - to provide partners with additional customization options, distribution, and reporting for their customized versions of Firefox.

Project Pre-Requisites

Technology: OSX Server (in-place, for Phase III a fault tolerant setup would be preferred. NB: OSX is required for DMG creation (maybe not)), storage capacity for 100 partners (approx. 75-100GB), Apache, Perl, MySQL, CakePHP (legacy system developed w/Cake)

Monitoring Required: availability, i/o utilization, and storage 24x7x365 w/8hr response (ideally faster response on release days)

Backups: Application, installer sources, and database. Archiving of Partner builds would not be required (resource-prohibitive, and can be rebuilt rather than restored)

Staffing: TBD - expect on-going development for 2009. no full time or part-time admin needed.

Initial Timeline

  • Phase I: DB updates, script updates, and testing of distribution generation to support existing Firefox 3.x Partner Repacks. Suggested/targeted completion by early Q1 2009
  • Phase II: CakePHP updates to existing interface to support changes made in Phase I. Suggested/targeted completion mid-Q1 2009.
  • Phase III: New application development to support the browser customization/creation project. Suggested/targeted completion end of Q1 2009/start of Q2 2009. Needs input from WebDev on resource availability and Marketing for timing.

Additionally, development is expected to be iterative over 2009, and will ideally add automated QA, marketing/bizdev review, and notification processes to the service, as well as integration with Business Affairs Contact and Contract Management systems. Additional phases will be added in Q1 2009, once a clear path to completion of Phase III is visible.

External dependencies

  • No external dependencies known at this time.

Development Environment Specifications

Per above, the technology framework is pretty much a LAMP setup, with the only additions being CakePHP development framework for the existing XPI-buddy application and perl for the back-end scripts.

The existing XPI-buddy application, developed by Dan Mills, supports the Firefox 2.x Partner Repack appication, and can be obtained from Kev Needham. A copy of the existing application is available on MPT, please email Kev for details.

The existing partner repack tools, which are a series of perl scripts for generating DEX files and repackaging customized 2.x distributions, are available from Kev Needham.

The partner distribution server (dm-partner01) will be used for development and testing in Phase I and Phase II. The development environment for Phase III is to be determined, dependent upon WebDev or third-party (if applicable) requirements.

Milestones and Tasks to Completion

Phase I: Back End Scripts and Info Repository

  • 12-Nov-2008: Initial meeting with Release Engineering to discuss requirements, gather feedback, solicit comments.
  • 17-Nov-2008: Release PRD outlining DB changes, /distribution assembly requirements, repack requirements. Development process starts.
  • 21-Nov-2008: Release development timeline and dependencies based on review of PRD.
  • 01-Dec-2008: Start Weekly Status Updates
  • TBD: QA/Testing
  • TBD: Release

Phase II: Administrative Front-End

  • 24-Nov-2008: Release PRD to Release Engineering and WebDev for analysis and comment.
  • 03-Dec-2008: Initial review with Release Engineering and/or WebDev
  • 08-Dec-2008: Release initial development timeline for Administrative Front-End

Phase III: Build Your Own Browser

  • 14-Nov-2008: Release project overview document for internal review (Kev/Dave R.), and start development of PRD.
  • 08-Dec-2008: Release PRD for partner-facing application to WebDev
  • 15-Dec-2008: Establish resource requirements and development timeline for BYOB project

Staging Signoff

In order to get an app into staging, the following should be completed:

  • Code committed to Mozilla source control and tagged
  • Initial architecture review by IT and WebDev
  • Plugin/tech review by Evangelism
  • Site must be password protected
  • Review timeline to go live
  • Review any production requirements so IT can order any new hardware needed

Production Signoff/Launch

  • Final WebDev signoff
  • Final IT signoff
  • Final QA signoff
  • Operations documents filled for support & any training complete
  • Monitors in place