We will look at the history of continuous delivery and its place in a wider technological framework. Looking backwards is often overlooked when trying to understand the implications of new technologies. By understanding our past, we can better understand the complexities of the problems we currently face.
|Goal of the session:||To help participants get a grip of the current state of continuous delivery and how it can help them.|
|Intended audience:||Anyone interested in assessing the value of their products. (see Personas)|
|Session Type:||Presentations, interactive talk|
|Topic:||Technology and Technique|
Many in the XP community knew that their tests told them something about their design. Code that was hard to test, the heuristic told us, was badly designed. There are, however, sister heuristics: the build time of a system tells us something of that system. The run-time of the tests tell us they may need refactoring, the compile and link times may tell us that we have not composed our modules correctly. That we need all our modules for all our tests might very well tell us something about how we use mocks, stubs and other test doubles. The common solution to the run-time problem is more firepower, hence the recent obsession with grid computing. The real solution is of course to fix the build (or never let it get into such a state).
In this talk, Mark Coleman and Jamie Dobson will look at the history of Continuous Delivery, how it started as the ‘daily build and smoke test’, mutated into ‘Continuous Integration’ a la XP, before being taken over by the tool merchants and sold as something ‘all teams had to do’. We’ll look at CD anti-patterns, including the nightly build, the test-team wrapper and more fire power.
Finally, we’ll look into the current state of continuous integration. Fuelled by the hype surrounding Eric Reis’ ideas that he collects in his book, The Lean Start-up, there is a trend towards continuous delivery for real end users, with companies like Flickr, Booking.com and Facebook changing, and releasing, their software daily. Because of this, automated testing takes on a new function: to enable rapid delivery of software by finding defects faster.
What you can expect from this session
Participants of this talk can expect a solid introduction into the history of continuous delivery, which may force them to consider the state of their own solutions. Via our analysis of anti-patterns, they can find improvements. And finally, by looking at what continuous delivery means to the business, we can equip participants with a language that their business sponsors understand and can respond to.