View source for Extending CI Past Traditional Dev & Release Process

* Traditional 'CI' is the build server
* Example: Using the CI Server to test site availability - check that processes are running
** Question if this is overkill
** Should infrastructure already have tools to do this?
** Not overkill if less than the overhead of involving infrastructure or other departments
** Can see build / server reporting and availability all in one report
* Example: Used to test assumptions about vendor application configuration, especially when configuration is stored in the database (custom metadata)
** Also extends to dummy customer setup
* Automated Deployments
** Definition - to any environment - command line trigger?
** Automatic deployment from CI Server for manual testing
** Required for CI automated functional testing
** No one is doing it to Production (without workflow management)
** Tableaux (http://www.incanica.com/tableaux.html) - used at Suncorp for workflow and depoloyments all the way to production - system that automates your current manual steps, including workflow and customer interaction checks and signoff
* Hudson used by many as their continuous integration server (https://hudson.dev.java.net)
** Output from Hudson build can be input to Tableaux server, which does environment staging
* Discussion about separation of concerns in deployment as equivalent to accounting separation of concerns
* Example: 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 at Atlassian
* The Build Doctor blog has lots of good stories (http://www.build-doctor.com)
** such as CI - building a machine from scratch
* Example: Infrastructure CI - testing a 'firewall server' - copy of production - checking for exceptions or missing/extra configuration