Winning at Continuous Deployment with the Expand/Contract Pattern (Live Demo)
Conference (INTERMEDIATE level)
Room A
You've done everything right: you have a continuous deployment pipeline, you have a commit stage with great unit tests, a pre-prod stage with fully automated deployment, robust end-to-end tests as well as some performance & security checks, and once all your quality gates are passed, your stream of changes march confidently towards production - but then somehow, someway, somewhy, production still blows up!
Continuous delivery is awesome, but the devil is in the details, and there's a decent chance you've been bitten by one of the biggest challenges - the safe management of contract changes.
Contracts can be obvious and public such as APIs (URL structure & schema), or obvious and private, such as database schemas, or non-obvious, such as the schema of in-flight messages in a queue, or dependency on specific timing expectations.
This talk demonstrates with real deployments the fundamental principle that underlies all safe contract changes - the 3 step model:
1. expand - introduce the change in a backwards and forwards compatible way
2. change - ensure all instances of the component and all dependants are using the new definition
3. contract - retire the obsolete compatibility elements
The good news is, with continuous delivery we can often do all three steps in quick succession!
Continuous delivery is awesome, but the devil is in the details, and there's a decent chance you've been bitten by one of the biggest challenges - the safe management of contract changes.
Contracts can be obvious and public such as APIs (URL structure & schema), or obvious and private, such as database schemas, or non-obvious, such as the schema of in-flight messages in a queue, or dependency on specific timing expectations.
This talk demonstrates with real deployments the fundamental principle that underlies all safe contract changes - the 3 step model:
1. expand - introduce the change in a backwards and forwards compatible way
2. change - ensure all instances of the component and all dependants are using the new definition
3. contract - retire the obsolete compatibility elements
The good news is, with continuous delivery we can often do all three steps in quick succession!
Chris Simon
Chris Simon - Technology Coaching & Advisory
Chris is a technology coach & advisor empowering technology teams to drive business success. He has a particular focus on helping startups realise their vision and new CTOs flourish in their roles. He also supports executives & boards with strategic technology advice, and engineering teams with training, mentoring and consulting in architecture, quality, domain-driven design and test driven development.
He is a regular meetup & conference speaker (NDC, KanDDDinsky, Serverless Days ANZ) and to support teams using Domain-Driven Design, he recently launched https://contextive.tech & co-founded the DDD Australia meetup.
He is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (recently acquired by NAB).
He is a regular meetup & conference speaker (NDC, KanDDDinsky, Serverless Days ANZ) and to support teams using Domain-Driven Design, he recently launched https://contextive.tech & co-founded the DDD Australia meetup.
He is the technical co-founder of https://www.inloop.com.au, home of Australian Fintech success stories https://www.flexischools.com.au and https://www.lanternpay.com (recently acquired by NAB).