Case Study: How Energized Work used Continuous Integration to get early feedback

Case Study: Continuous Integration feedback – much more than simply builds

The second of the case studies that we’ve sourced from the community, this one comes from Simon Baker and Gus Power at Energized Work. We really appreciate the time they spent with us in order to write this case study.

In 2011, Energized Work, a software engineering lab, began building an MVP for a new start-up The concept was to create a social commerce website and back office that invited consumers to combine their spending power in order to achieve bulk discounts. If 50 people wanted a digital camera, for example, they should be able to buy it at a wholesale price. In theory, the more people who wanted a product then the bigger the potential discount.

The team practised continual integration from day one. Every piece of code checked in was executed with unit tests and integration tests by the CI server and then deployed to an internal reference environment. At the end of week one, the CI server was deploying running tested features to a secure public- facing demonstration environment on a daily basis. This meant that it could be demonstrated to investors – their feedback improved the concept, and a new version would be ready to show in a very short time for the next pitch.

The concept of BuyaPowa meant that products were being offered with a limited stock. Therefore, the system had to ensure that only the number of units on sale would be sold by reducing the stock count only after payment at PayPal had completed successfully. Tests checked there were no concurrency issues and by creating mocked-up versions of the external systems, in particular PayPal, the CI server executed high volume concurrency tests through the deployed end- to-end system. This meant that any changes that might introduce concurrency problems were automatically detected. For example, a few times subtle changes to the domain model broke expected behaviours and the CI server provided instant feedback about the problem.

Given the different integrations with external systems, it was important the team made sure the feedback was as meaningful and useful as it could be – not just a ‘build is broken’ alarm! When feedback revealed an external dependency had broken, for example because Facebook had changed their API, the team knew to stop and address the integration problem before moving on to develop new features. They went a step further and made sure that any break automatically generated a complete information picture of that exact point in time – error messages, log files, configuration set-ups. This meant the pair fixing the break could easily identify whether the fault was something relating to connectivity to external systems, the external systems themselves, or whether there was actually an error in the code.

For this team, continuous integration was not something simply to tick off (great, the builds didn’t break this time), but an integral part of their feedback on development and customer interaction with the system.

Related content