Pre-pre-deployment

• add notes about new features or bug fixes to CHANGES.txt
  
• Confirm that all necessary tickets in the current milestone have been addressed.  If not, move them to another milestone or fix them.
  
  

Pre-deployment:  Dev

1. Build the full stack from scratch somewhere (dev?).
   
   • Proceed only when the build runs without problems
2. Run opencore & related tests: 
   
   • zopectl test -s opencore
   • zopectl test -s Products.listen
     
   • Proceed only when all tests pass
     
3. other parts of the stack presumably have tests? put those here.
   
4. Run flunc tests as per ... link to flunc howto
   
   • If any failures, fix. rinse, lather, repeat.
   • If fixes involve configuration or dependencies, repeat from step 1 to make sure the build is up to date. All hand fixes to configuration should be integrated into the build process in the appropriate way, eg: checked in to the appropriate build etc repository,  or added to zope setup profiles, etc.
     
     

Trial Run: Stage

1. Run the build on stage.
2. Run a spider script against stage and investigate all errors.  e.g. this one ... in progress
3. Manual testing on stage.
   
   1. Organize a testing party, and make sure everyone knows it's happening.
      
   2. Evaluate risks related to the new deployment -- such as new features, possible bugs, performance, regression, core user stories, etc -- and create new- or find existing charters related to those risks.
      
   3. Send testing party off onto roughly 90 minute time-boxed sessions related to those charters, using the 90 minute time-box to consistently receive information from testing effort.
   4. Report findings of each session to the person leading the testing effort, then make a decision on what findings to submit to the bug tracking system.
      
   5. Submit those findings. (This guideline might be helpful.)
      
   6. Report the testing group's findings to to stakeholders as needed, and repeat 3.2 through 3.6 as necessary.
      
4. Evaluate the bugs found by the testing group as well as those already known, and make a deployment decision. Do we want to deploy with these bugs? Are they severe enough that we should fix them?
5. Fix all bugs decided on in the triage step above, confirming that each of those bugs have actually been fixed.
6. Repeat steps 2 through 5 as necessary until the deployment decision in step 4 is a "Yes."
   

Deploy

1. Is it Friday?  If no, proceed to step 2
2. See livable-streets-qa-release-notes
   
   

Post-deployment 

Make sure everything is working on the live site

Smoke Tests

  * create an account
  * create a project
  * visit /blog on the project
  * create a page in streetswiki
  * log in and create a note on the NYCMap
  * send an email to a mailing list (actually, will this work on any of our QA builds? I guess we don't have proper mail servers set up for all of these? it'd be nice to figure out a way to exercise Listen during this QA cycle though)
  * delete the project
  * trigger a site error and try to send an error report