IT/Production Acceptance/PartnerRepacks: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 20: Line 20:
* 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 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 the Build Your Own Browser program (target of late Q1/early Q2 2009) to register for the program, submit their proposed customizations, and (on approval) generate and distribute their customized builds.
* A web-based public facing front end that will allow participants in the Build Your Own Browser program to register for the program, submit their proposed customizations, and (on approval) generate and distribute their customized builds.
 
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.


=== Project Pre-Requisites ===
=== Project Pre-Requisites ===

Revision as of 17:20, 11 November 2008

Start of project

  • Project sponsor: Kev Needham / Business Affairs
  • Main IT contact: TBD
  • Main WebDev contact: TBD
  • Main RelEng contact: Chris Cooper
  • Main QA contact: Carsten Book (Tomcat)
  • Main third party contact: TBD
  • Final application owner/maintainer: John O'Duinn / RelEng


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 based on that information on demand automatically.
  • 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 the Build Your Own Browser program to register for the program, submit their proposed customizations, and (on approval) generate and distribute their customized builds.

Project Pre-Requisites

Technology: OSX Server (in-place, for BYOB a fault tolerant setup would be preferred. OSX is required for DMG creation), storage capacity for 100 partners (approx. 75-100GB), apache, 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 Build Your Own Browser project. Suggested/targeted completion end of Q1 2009/start of Q2 2009. Needs input from WebDev on resource availability.

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

Phase II: Administrative Front-End

Phase III: Build Your Own Browser

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