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