Extending CI Past Traditional Dev & Release Process

From CitconWiki
Revision as of 23:40, 26 June 2009 by Juliangamble (talk | contribs) (New page: - Traditional 'CI' - The Build Server - Using the CI Server to test site availability - process availability ? Overkill? - not if less than the overhead of involving infrastruc...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
- Traditional 'CI' - The Build Server
- Using the CI Server to test site availability
  - process availability
  ? Overkill?
   - not if less than the overhead of involving infrastructure department
   - Can see build server reporting and availability all in one report
- Used to test assumptions about vendor app configuration (DB) (Custom metadata)
  - also extends to Dummy customer setup
- Automated Deployments
  - Definition - to any environment - command line trigger?
  - auto deploy from CI Server for manual testing
  - required for CI automated functional testing
  - no one is doing it to production (without workflow management)
- Tableaux - a product used in Suncorp for Workflow and Depoloyments all the way to production
- System that automates your current 300 manual steps
 + incl workflow and QA signoff checks recording
- Local Devs use their Hudson CI Server
 - Output from Hudson build #340 is input to Tableau server - which does environment staging
- Discussion about separation of concerns in deployment as equivalent to Accounting Separation of Concerns
- Monitoring System Load
  - Metrics on load components  of the system
- Length of Build queues on CI Server
  - CI Background Hum
    - 15% of build failures caused by infrastructure dropouts


- builddoctor.com
   - CI - building a machine from scratch
- Infrastructure CI - testing on 'firewall server' - copy of production - checking for extra exceptions