Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Don't refactor. rebuild. kinda. (Agile 2015, Washington DC)

4,239 views

Published on

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.

Published in: Software
  • Be the first to comment

Don't refactor. rebuild. kinda. (Agile 2015, Washington DC)

  1. 1. Don’t Refactor. Rebuild. Kinda. Wouter Lagerweij @wouterla
  2. 2. 16.5M Bikes ~1 Bike/person
  3. 3. ● Slow, unreliable unit tests ● Slower Selenium tests ● Messy, duplicated code ● Manual deployments ● Production issues
  4. 4. ● 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)
  5. 5. 25%1.7% - 2.1% - Feb May unit-test coverage
  6. 6. Rebuild?
  7. 7. 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
  8. 8. In Practice ● Architecture: Strangler Pattern ● Process: Continuous Delivery ● The First Sprints
  9. 9. 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
  10. 10. DB request for website A request for website B request for website C request for website D request for website E Legacy system
  11. 11. DB website A Legacy system Incoming request New Page Service Incoming request for new page
  12. 12. ● 100% unit-test coverage ● TDD all the way ● All functionality defined by BDD scenarios ● Fully automated deployment ● Every push goes to production Process
  13. 13. DB website A Legacy system Incoming request for job detail page Job Detail Page Job Service Incoming request for other pages
  14. 14. Sprint 1
  15. 15. 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.
  16. 16. 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
  17. 17. 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
  18. 18. Sprint 2: Detail Page Goal: Get a fully functional Job Detail Page replacement working behind the feature toggle
  19. 19. Sprint 2: Detail Page ● Create Job Service component, including full pipeline
  20. 20. DB website A Legacy system Incoming request for job detail page Job Detail Page Job Service Incoming request for other pages
  21. 21. 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...
  22. 22. Done?
  23. 23. 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
  24. 24. Problems
  25. 25. @wouterla Wouter Lagerweij Thank You!

×