Once you've been on a continuously-delivered project, there's no way back. The combination of rapid feedback, high levels of collaboration, and great software quality produces a virtuous delivery cycle that is both pleasing and effective.
However, existing delivery models and product portfolios may not allow for straightforward adoption of CD. Technical and organisational debt accumulates inexorably over time and can make continuous delivery difficult or even impossible.
In this session, we draw on our extensive project experience to demonstrate some of the software architecture patterns that enable continuous delivery. We look at related anti-patterns; and some strategies for getting a codebase into a shape such that it can be continuously delivered. We use examples of both successful and unsuccessful projects to show some of the rewards and pitfalls of following these strategies.
As the structure of a software product changes, the organisation of the teams building and supporting it will need to go through concomitant changes. Using more real project examples, we discuss what drives these organisational changes, how they can be managed, and how to base a delivery team around collaboration rather than conflict.
As we go, we engage members of the audience in a conversation about instances where they have seen similar issues, and encourage sharing of some methods that they might have tried.
