IT/Production Acceptance/DRM

Note: This project is separate from the IT/Production_Acceptance/CRM project that is also running on CiviCRM. This project is a donor relationship management tool that is for internal use only.

Start of project

• Name each of the following:
  • Project sponsor -- David Boswell
  • Main IT contact -- TDB
  • Main WebDev contact -- TDB
  • Main QA contact -- TDB
  • Main third party contact (if developed externally) -- Tom Wolf at Chicago Technology Cooperative
  • Final application owner/maintainer -- David Boswell
• Outline the following:
  • Overall goal of the project -- Create a tool that will allow us to automate many of the donation related tasks the Foundation is currently doing.
  • Any pre-requisites needed (technology, server capacity, staffing, monitoring, response time, etc)
    • The project requires a two-server setup: an internal server which is to be a full repository of all information and an external server which will function as a front-end for interacting with the public.
    • Based on current understanding, the internal server will be a virtual one.
    • A LAMP stack with PHP 5+, MySQL 5+, and a MTA is necessary on both servers.
    • Both servers will need a minimum of 48MB allocated to PHP's script execution memory.
    • The additional load from this project should be minimal to the externally-facing server (which is assumed to be the same one as the Foundation's general web server); the system will *only* be used for the processing of donations. The internal server will be serving only a few users doing relatively unintensive data retrieval and analysis.
    • Beyond basic monitoring to ensure the system remains online, no systems staff time should be necessary to either administer or maintain the solution.
  • Initial timeline -- Our goal is to have the initial CiviCRM install happen within the next week or two. Once that is up, CTC will handle customization work that will last approx. 4 weeks.
  • External dependencies
    • Drupal and CiviCRM will be used on both servers to build a custom solution.
  • Dev environment specs
    • The development environment should mirror the production one, most importantly with regard to the network architecture separating the public and internal boxen. The protocol for transmitting information from the public server to the internal one will be dependent on what communication channels and/or barriers are present between the two systems.
  • Does this project use any plugins or proprietary technology?
    • No

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