Extending CI Past Traditional Dev & Release Process

From CitconWiki
Jump to navigationJump to search
  • 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