DevelopmentStagingProcess
Revision as of 17:07, 13 November 2007 by Brandon CS Sanders (talk | contribs) (Merging DeveloperStagingSupport in here so that I can get rid of the redundant tasks)
What (summary)
Come up with the ability to be able to stage branches for testing purposes.
- Immediate action when necessary
- A platform to incrementally release and user test things before they go live
Why this is important
- This will enable us to more fully test large changes (external access to developer branches)
- Not surprising users in "a bad way"
- Rarely make "mistakes"
- Getting better at communicating with our users so they know when things are about to be installed
DoneDone
- Branches can be staged, both on till and local developer machines
- Methodology is clearly defined for how things enter the staging process
- we start staging our larger changes, to smooth out our impact on the live tree
Steps to get to DoneDone
- We should toss up a solution that makes sense to us ... DevTools
- Then convene a meeting of all stakeholders to discuss our prototype staging process and whether there are tweaks we should introduce
Stuff
- easy script to create a branch
- make sure it doesn't conflict with an existing branch name
- branch aboutus and compost
- easy script to make a branch active on your (the developers) box
- branch serving on till
- port allocation for compost mongrels
- apache config
- easy revert for when things get hosed (tags?)
- Ability to see what has been running on the live site (date based tags would be fine, possibly a log of hashes or whatever)
- easy script to merge + close branches