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...)
- 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