Please join us to talk about infrastructure as code. DiUS have kindly offered to host the August meetup and will supply food and beverages.
Stephen Bartlet (@srbartlett) and Brendan Spinks (@brendanspinks) - Continuous Deployment in action
We attempt to get fast feedback on everything we do. It began 10 years ago when we started using Continuous Integration. Today enterprise software development has shifted to cloud-based, continuous delivery with fully automated quality, functional and performance tests gating live deployments to production. The practise known as Continuous Delivery is a key enabler to shorten the cycle time and getting fast feedback.
This interactive session will be run by DiUS Senior Consultants Stephen Bartlett and Brendan Spinks. The pair will introduce the technical practices and activities that enable teams to deliver software of high quality and value into production multiple times a day. They will talk about continuous delivery through continuous integration, automated testing and the deployment process.
There will be demonstrations of continuous delivery in action using agile cloud-based infrastructure to automate the management of dev/test and production environments. They will also attempt to deploy an application live to production and discuss how to achieve zero downtime deploys, techniques to mitigate risks, and the importance of collecting metrics to get the all important user feedback.
Ricky Cook (@thatpandadev) - LXC + Puppet + AuFS = CI Awesomeness
Agile development says to test fast, test often, test in isolation, test close to production and fail quickly.
Your Continuous Integration should optimise for these, but usually simply setting up Jenkins and pointing it at a repo is not enough. You set up a custom server with a custom environment and it’s nothing much like production at all.
At Infoxchange we’ve put together a better solution. Using Linux containers (LXC), AuFS and Puppet we can rapidly build environments with minimal overhead that keep up to date with your real production servers and actually represent the environment that your software will be running in to run full test suites.
When you do all this and it takes only a few minutes, it opens up enormous opportunities for improving code quality and reducing botched deployments: you can run your full test suite for every change in parallel on a prod-like setup and get very fast feedback for just your own changes; you can automatically deploy a new site for every branch you are working on so that features can be thoroughly user-acceptance-tested in isolation from each other. This reduces merges to master just for acceptance testing, means your master branch is always deployable and prevents your work from blocking that of other developers.
Please contact Matt (@geekle) or David (@dlutzy) if you'd like to talk.