Version of this talk from Agile 2015, Washinton DC Each and every time, the situation is the same: a big, messy code-base, few (if any) tests and many production issues. It’s no accident that, when he joined what would be the first XP team, the first thing Kent Beck said was: “*Let’s scrap it!*” Even with a world class team, these problems can be almost insurmountable. And we don’t usually start out with world class teams. Learning all the XP practices is hard enough without a Big Ball (of Mud) and Chain holding you back. So maybe we should rebuild. But the Agile way: incrementally, iteratively, and with close involvement from the business. Using examples from practice, I’ll show that: - We can set up a clear, loosely coupled architecture around the existing system, so we can replace parts while its running - We are then free to use all our modern practices for the new parts, and start Continuous Delivery from the first sprint - We can closely involve the business to surface the actually needed functionality, and build up Living Documentation in the process - We can get even an inexperienced team using and accepting practices such as TDD and ATDD quickly Learning Outcomes: The audience will see how extending some existing approaches to system improvement can give teams working on legacy systems renewed energy and belief (through experience) that high quality is possible.

1. Don’t Refactor.
Rebuild.
Kinda.
Wouter Lagerweij
@wouterla

3. 16.5M Bikes
~1 Bike/person

11. ● Slow, unreliable unit tests
● Slower Selenium tests
● Messy, duplicated code
● Manual deployments
● Production issues

13. ● TDD
● BDD
● coding katas
● pairing
● training w/ Chet
● Improve test run time
● 100% coverage of new code
● refactor in the small (boy scout rule)
● refactor in the large (planned improvements)

14. 25%1.7% -
2.1% -
Feb
May
unit-test
coverage

17. Rebuild?

18. So...
● Deliver value from day one
● Don’t rebuild the same mess
● Don’t rebuild using the same process
● Don’t rebuild the same functionality

19. In Practice
● Architecture: Strangler Pattern
● Process: Continuous Delivery
● The First Sprints

20. Architecture: before
DB
request for
website A
request for
website B
request for
website C
request for
website D
request for
website E
Legacy system

21. DB
request for
website A
request for
website B
request for
website C
request for
website D
request for
website E
Legacy system

22. DB
website A
Legacy system
Incoming request
New Page
Service
Incoming request
for new page

23. ● 100% unit-test coverage
● TDD all the way
● All functionality defined by BDD scenarios
● Fully automated deployment
● Every push goes to production
Process

26. DB
website A
Legacy
system
Incoming request
for job detail page
Job Detail Page
Job Service
Incoming request
for other pages

27. Sprint 1

28. Sprint 1: Proxy
Goal:
Get a new front-end component up that proxies
all traffic to the old system but serves ‘hello
world’ if we ask nicely.

29. Sprint 1: Proxy
● Create a new environment, in this case on amazon’s AWS
● Create Ansible scripts to provision a basic infrastructure:
○ jenkins
○ sonar
○ docker nodes for test, acceptance and production
● Set up a VPN to the existing (hosted somewhere else) environment
● Create a new codebase for a (php, symfony) component
● Create build scripts for the new component
● Create a hello world page for the url that pointed to the job detail page
● Create a proxy so that all calls would be delegated to the old system (apache vhost.conf)
● Create a feature toggle so we could override the proxy based on a cookie (apache vhost.conf)
● Package our new component as a Docker image, and figure out how to deploy it
● Use a docker registry to store and version out deployment packages
● Create Jenkins Job Builder configuration to set-up a delivery pipeline for our new web front end
● Create a basic smoke test for the component to check successful deployment in the pipeline
● Set-up the AWS loadbalancers for all the environments
● Make sure newrelic could be configured on all our nice new Docker containers
● Route all traffic for our first website through our new infrastructure

30. Sprint 1: Proxy
● Create a new environment, in this case on amazon’s AWS
● Create Ansible scripts to provision a basic infrastructure:
○ jenkins
○ sonar
○ docker nodes for test, acceptance and production
● Set up a VPN to the existing (hosted somewhere else) environment
● Create a new codebase for a (php, symfony) component
● Create build scripts for the new component
● Create a hello world page for the url that pointed to the job detail page
● Create a proxy so that all calls would be delegated to the old system (apache vhost.conf)
● Create a feature toggle so we could override the proxy based on a cookie (apache vhost.conf)
● Package our new component as a Docker image, and figure out how to deploy it
● Use a docker registry to store and version out deployment packages
● Create Jenkins Job Builder configuration to set-up a delivery pipeline for our new web front end
component
● Set-up the AWS loadbalancers for all the environments
● Make sure newrelic could be configured on all our nice new Docker containers
● Route all traffic for our first website through our new infrastructure

32. Sprint 2: Detail Page
Goal:
Get a fully functional Job Detail Page
replacement working behind the feature toggle

33. Sprint 2: Detail Page
● Create Job Service component, including full pipeline

34. DB
website A
Legacy
system
Incoming request
for job detail page
Job Detail Page
Job Service
Incoming request
for other pages

35. Sprint 2: Detail Page
● Create Job Service component, including full pipeline
● Database access to old system’s DB
● Unit testing build steps for php
● Sonar (static analysis) deployment and build steps
● Contract test for Job Service
● Client library for Job Service
● Acceptance scenarios for job detail functionality
● Unit testing build steps for javascript
● Sonar setup for javascript
● Implement Just Enough to Read a Job
● Create a nice looking front-end...

36. Done?

37. In one month
● legacy system
● few tests
● manual deploys
● 1 release per week
● timid team
● decoupled services
● 100% coverage
● full automation
● 30 releases per day
● courage

39. Problems

40. @wouterla
Wouter Lagerweij
Thank You!