With the sad passing of fantasy author extraordinaire Sir Terry Pratchett, a small internet project has sprung up to immortalise him in the code of webservers and emails everywhere. The project is GNU Terry Pratchett.
Now every visit to the main www.spotlight.com site serves the header ‘X-Clacks-Overhead: GNU Terry Pratchett’ for the foreseeable future as a part of our Varnish configuration.
Here is how we get ideas to production at Spotlight. I’ve borrowed the sales funnel analogy to illustrate our latest process.
- Ideas go into Trello to start with where they are evaluated
- Good ideas get turned into stories which we put into Pivotal Tracker along with other stories
- Stories get planned, worked on and the resulting code gets put into GitHub along with other minor fixes
- We make heavy use of pull requests so code that can’t be automatically merged is rejected to be reworked
- All code must get reviewed and this makes it very easy to see the changes
- Commits are tagged and Pivotal gets updated automatically
- The result of the code merged into master is built by TeamCity and unit tests are run
- If the build or any tests fail then the code is rejected
- The pull request is marked as good to merge automatically if everything is green
- The build outputs are put into our internal NuGet repository
- We then use Octopus to deploy the release to the test environment (in AWS)
- A suite of automated Selenium regression tests are then run against the deployed code
- Manual testing is then performed if required
- If everything is good then the code is promoted to the live environment (also in AWS)
The key here is automation. A huge amount of the above is automated. A commit to GitHub will trigger a large amount of processes to check that the code won’t break anything. When a pull request is merged the master build will be deployed to the test environment overnight and regression tested by automated browsers. This process allows us to release more often and reduce risk.
However, the above is just a subset. The environments at AWS are built with Chef so if we need a new one it is just a click away. This makes it repeatable and more consistent. We can be confident that the test environment is as close to live as possible. Everything is monitored with automated alerts to highlight issues as early as possible. We also have some interesting ways of surfacing this information which we hope to write about soon.
This is having the test environment become the live environment (usually by switching the DNS) so you don’t need to promote anything.
Automatic push to live
We’d like to have the confidence to have a change go all the way to live without human intervention but we’ll need to improve the test coverage first.
We’ll keep you updated as we go.