- Switch from activity specific (SDI/XCI) to component specific planning, design, and testing discussions threads
- Introduce a new component user community discussion thread
- Introduce a new component operator discussion thread
Component documentation should be kept up-to-date as agile changes happen.
- Design/security description
- Testing plans
- Operations documentation
- User documentation
- Production change log
As design/security description changes the development team should evaluate whether a change specific (mini) design/security review "DSR" would be beneficial.
To trigger a DSR:
- Dev-Ops team posts a revised design/security description to the component design thread listing which specific sections and changes need review
- Dev-Ops team notifies RACD management to request a mini-DSR and suggests reviewers
- RACD management will prepare and manage the mini-DSR
- Reviewers will provide feedback and the dev-ops team will reply thru the component design thread
- At the end of the DSR the dev-ops team will post a brief DSR summary to the component design thread
As functionality changes the development team should evaluate whether a change specific integration test would be beneficial.
To trigger the testing:
- Dev-Opts team posts the revised testing plan to component testing thread and lists which tests need to be run
- Dev-Ops tea notifies RACD management to start integration testing
- Testers will post issues and results and developers will reply thru the component testing thread
- Testing lead will summarize the testing results with the pass/fail to the testing thread
As functionality goes production:
- Operator will post changes to the production change log
- There is no launch review and the dev-ops team decides which changes to implement (they can request input if they want).
- Dev-ops team can trigger a mini-DSR when useful
- Dev-ops team can trigger a mini-integrated testing when useful
- Dev-ops team deploys in production when ready and publishes changes