This document discusses practices for implementing continuous delivery in legacy software environments. It outlines key characteristics of continuous delivery like keeping software deployable throughout its lifecycle. It then provides examples of how one company transitioned their monolithic legacy application to a continuous delivery model by using techniques like the strangler pattern, refactoring to separate concerns, and restructuring their organization into cross-functional product teams. The document emphasizes establishing technical foundations, learning through the build-deploy-learn cycle, and focusing on delivering value to customers.

1. Practices, mechanisms and
organisational models
that can be applied to any
software project, big or
small, old or new.
Continuous
Delivery in a
Legacy
Environment

2. - Technical Architect at Planday
- Lead consultant at Lean Software
- 16+ Years in software
development, based in London &
Madrid
Peter Marshall
MAIL
info@leansoftwareservices.com
TWITTER
@petemar5hall
LINKEDIN
https://www.linkedin.com/in/petedmarshall

3. How many people are practicing
continuous delivery or have a devops
team/culture?

4. How long would it take your organisation to build
and safely deploy a change that involved just one
small feature or a single line of code?

5. Agile gave us..

6. “Continuous
delivery is about
focusing on
technical
excellence”

7. “Continuous Delivery is a
software development
discipline where you
build software in such a
way that the software can
be released to production
at any time.”
Martin Fowler, May 30, 2013

8. Key
Characteristics

9. 1. YESTERDAY
Your software is
deployable
throughout its
lifecycle
Key Characteristics

10. 1. YESTERDAY
Your team
prioritises
keeping the
software
deployable over
working on new
features
Key Characteristics

11. You can perform push-button deployments of any version of your
software to any environment on demand
Key Characteristics

12. Anybody can get
fast, automated
feedback on the
state of their
systems any time
somebody makes a
change to them
Key Characteristics

13. A quick look at

14. The Leading
Workforce
Collaboration
Solution
for shift based
businesses
Driven by simple,
powerful and beautifully
designed SaaS technology

15. Healthy & organic growth for 11 years
Investment from Creandum in 2014 ($3.75 million)
Global expansion
Founded
in 2004

16. 70+ people
HQ in Copenhagen
Offices in
Oslo
Aalborg
Hanoi
London
New York

17. Founded in 2004
1. YESTERDAY
“Conquer the world in
the next 12 months!”
which translated to:
“Move into the USA with the
next 6-12 months”
“Be ahead of the game,
always”
“maintain our reputation of
producing quality software”

18. vs.
“to be able to deliver software quick, easily,
and with very low risk of failure”
“to be able to scale our systems very quickly”
Technical Goals

19. Web Portal
Models & Controllers
Business Logic
Data Access
Salary
Scheduler
Messaging
Services
Punchclock
REST
Sign Up Android iOS
Planday Monolith
Mobile
Databases
Supplementary Web Apps .net

20. “Always have at least some
idea of where you are now, and
where you want to go, and
share that with the team,
organisation, and even
customers.”

21. Where do you
start?
First pass.

22. Build Agent & Devel
The delivery pipeline
Pre commit tests
Code review
PO/UX review
Branch / Merge
Build
Unit tests
Contract tests
Component tests
Coverage
Static analysis
Component
performance
End to end
component tests
NFR tests
Exploratory Test
performance testing
Story sign off /
Demos
NFRs
Analytics
Monitoring
Production tests
canary or blue /
green release
CI Environments
Developer
Local
Pre-Production Production
Virtualised Full stack environments
Commit Auto-Deploy Promote Release
Build Pipeline:
There can be multiple pipelines, usually per system, should execute in minutes
Commit:
The commit can include changes to the infrastructure, database, or application code.
Outputs:
Software, infrastructure and configuration
Environment manifests
Release notes
stabilise

23. Remove the
fear. Remove unnecessary
human intervention from
the process.
Remove the magic.

24. Put simple continuous
integration in place, with build
monitors.
Put a simple deployment
mechanism in place.
Make it easy to clone, build, and
commit code.

25. first pass
Build Deployment ?

26. Second pass.
Improve our knowledge of the
state and behaviour of the system.

27. Simple environment provisioning.
Lets run some tests.
Logging and monitoring.

28. “A good, easily accessible
event & error monitoring
system is essential for anyone
releasing software. Build an
early warning system into your
environment!”

29. “Understanding your systems
steady state allows you to react
quickly to any deviation”

30. second pass
Build & Test
Deployment &
Provisioning Logging & Monitoring
Infrastructure - Environment provisioning

31. Back to the
business goal.
We had stabilised the system, made it easy to work with, and
now we had to win the business!
Put continuous delivery into ACTION!

32. Deliver whatever, whenever.
Scale quickly and safely.

33. Can we do something with our current monolith?
What about microservices, they
could solve all our problems, right?
we have a lot of user experience experiments
to do, we needed to support quick small
experiments. quick releasing.
Would modern UI frameworks be better to
work with than aged .net technologies?

34. As a business we knew
we would win the game
by focusing on user
experience, over making
or improving existing
features

35. How we did it

36. the
strangler
pattern
lipstick on the pig

37. Web Portal
Models & Controllers
Business Logic
Data Access
Salary
Scheduler
Messaging
Services
Punchclock
REST
Sign Up Android iOS
Planday Monolith
Mobile
Databases
Supplementary Web Apps

38. Existing Planday Monolith
Domain
Data Mapping /
Access
Salary
Scheduler
Messaging
Services
API
WebServer:IIS
Android iOS
Web Applications
Mobile
Windows
Databases
New Front End Modules (JS using REACT)
Punchclock Sign UpPortal
Existing Front End

39. broke direct dependencies
Introduced package
management
Introduced load
balancing
Introduced caching at the
application layer
technology geared to
rapid developmentincreased logging,
monitoring & analysis to
cover JS, Server,
Database, &
Infrastructure
adopted domain driven
development
feature toggling

40. Domain + BL
Data Mapping +
Access
Salary
Scheduler
Messaging
Services
API
WebServer:IIS
Android iOS
Mobile
Windows
Databases
Client side front end modules
Punchclock Sign UpPortal
Integration
Partners
Caching
Client side
Old Monolith

41. Load
Balancers
Backup
Servers
VM Hosts
Production &
Development
Database
Servers
Storage
Servers
Development
Servers
Production
Servers
Repurposed our infrastructure
Physical
Virtualisation

42. Organisation
How we restructured the

43. CPH Development Team
Hanoi Development Team
Teams working very much in silos.
Unaligned.
No process.
No management.
No attachment to the business.
Poor communication.
Before
Design Team
Product Team

44. Product Teams
Web Mobile API
Supporting Teams
Dev Ops Tech Management
All teams are cross functional with end-
to-end responsibility for one or more
parts of the system.
We use a mixture of scrum and
Kanban. Some teams use sprints,
others use flow based systems.
Common elements occur regardless
such as daily standups, estimation
sessions, & planning sessions.
Our architecture and deployment
strategy allow teams to release on their
own schedule with minimal impact to
others.
Virtual teams appear as and when the
need arises.
After
Marketing

45. The truth
is in
the data

46. Tech
Values

47. We value overall simplicity over localised simplicity.
We value software developed with a focus on
operation and maintenance in production.
Deliver in small batches
Don't do loads of things

48. Development process
Build > Deploy > Learn cycle
Product requirements are identified by a Product Group and then built by one or more product
teams
Initiatives that support long term business goal
Hypothesis driven with an aim to be proven by specific measurements
Feature toggling mechanisms allow experimentation, exploration and controlled feature launches
Master
Feature
Build the feature Toggle it on or off Measure the impact

49. smaller,
more
frequent
deliveries

50. Where are
we now?

51. Build Agent & Devel
Technical Foundations
Pre commit tests
Code review
PO/UX review
Branch / Merge
Build
Unit tests
Contract tests
Component tests
Coverage
Static analysis
Component
performance
End to end
component tests
NFR tests
Exploratory Test
performance testing
Story sign off /
Demos
NFRs
Analytics
Monitoring
Production tests
canary or blue /
green release
CI Environments
Developer
Local
Pre-Production Production
Virtualised Full stack environments
Commit Deploy Promote Release
Build Pipeline:
There can be multiple pipelines, usually per system
Commit:
The commit can include changes to the infrastructure, database, or application code.
Outputs:
Software, infrastructure and configuration
Environment manifests
Release notes

52. Learnings
We know we will fail sometimes
Simplicity is key
Common & share vision
Strong leadership

53. Thank
you!
TWITTER
@petemar5hall
Agile Consultant & Technical
Architect @planday
Peter Marshall
fiveMAIL
info@leansoftwareservices.com
LINKEDIN
https://www.linkedin.com/in/
petedmarshall