Continuous Delivery at Deli XL

1,145
-1

Published on

Why and how Continuous Delivery was implemented at Deli XL, including benefits, design, technologies, examples and various metrics.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,145
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Continuous Delivery at Deli XL

  1. 1. Ernst de Haan, E-commerce Architect, Deli XL June 6, 2012 Continuous Delivery @ Deli XL
  2. 2. Executive Summary> PROD = 18 machines (16 virtual)> Developer to PROD: ± 50 min> Monday after Sprint → PROD> Multi-site, multi-branch> Deployment = 1 click (takes ± 20 min)> Rollback = 1 click> Deployment issues = 0
  3. 3. ✓ 1K suppliers ✓ 110K products ✓ 2M consumers?✓ 30K customers ✓ € 750M/year ✓ 100 catalogs
  4. 4. Process> Scrum, 3 week Sprints> Acceptance test inside Sprint> Separate streets: D→A→P and T> Monday after Sprint → Prod (06:00 h)> Prod deployment by Ops team in India> Developers/testers deploy to D/T/A
  5. 5. Architecture> ATG 10 (multi-site) > Commerce > Service> XINS > integration layers > high testability> GigaSpaces > service grid + data grid > high scalability
  6. 6. web browsers, mobile apps, external systems Internet E-commerce Apache Architecture Domain Image API (XINS) JSPs JavaScript API (XINS) ATG Out API ATG In API (XINS) (XINS) CMS Data Grid Passthru API(First Spirit) (GigaSpaces) (GigaSpaces) External systems: SAP, IDM, AS/400, etc.
  7. 7. Continuous Delivery @ Deli XL 1 Why we did it 2 What we did 3 Demo 4 Discussion
  8. 8. Typical IT Headaches been there…> Creating builds = manual labour> Deploying to test environments = slow> Deployment reliability = error prone> Get Sprint ready for PROD = challenging> Root cause analysis = difficult> Elastic scaling = not possible
  9. 9. Typical Business Headaches> TTM > long, even with agile (Developer → P in weeks?) > much variance (typically due to issues after Sprint)> Cost > manual builds & deployments are recurring costs > the later an issue is found, the more expensive
  10. 10. Why Continuous Delivery> Improve TTM (shorten, reduce variance)> Automate tedious work> Increase project efficiency (within Sprints)> Increase Ops efficiency> Make offshoring easier> Simplify new initiatives/brands> Reduce (impact of) Production defects> Elastic scaling
  11. 11. Why Continuous Delivery - Summary> Reduce overhead cost> Increase reliability> Increase agility and because it reduces headaches for IT :-)
  12. 12. Continuous Delivery @ Deli XL 1 Why we did it 2 What we did 3 Demo 4 Discussion
  13. 13. At Project Start> Manual quality control> Manual builds & deployments> Single site/brand> Single project (1 branch in version control)> Slow environment provisioning
  14. 14. Steps Taken During Project> Unified vision & NFRs> Standardized all processes> Continuous Integration including QC> Automated builds & deployments> Workflow control system (Jenkins)> Standardized environment provisioning> Environment cloning procedures
  15. 15. Design> Environment-agnostic builds/packages> Commit Stages - one per branch > e.g. per project: previous release/hotfixes, next release > includes QC > includes automated deployments to CI environment > includes automated functional regression tests> Deployment Pipelines > independent from Commit Stages > configuration easy to change
  16. 16. Technology> Maven> Jenkins> Puppet less relevant, it’s about how you set it up…
  17. 17. Dealing with Parallel Projects> Example: > Sprint 22 – 3 weeks – regular Sprint > Sprint 21+ – 1 week – started at same time> Approach: > separate branch (10 min) > separate commit stage (10 min) > allocated a deployment pipeline (= environments) > communication > daily merge, one way > final merge after P delivery
  18. 18. Dealing with Data> Simple approach for typical situations > repeatable data model changes> In exceptional cases intervention is needed
  19. 19. Hotfixes> Again: single click> Regular deployments from release branch
  20. 20. Rollbacks> Typical: > one click of a button> Exceptional cases: > intervention needed because of data (structure)
  21. 21. Resourcing Vision (1/2)> Business & management consulting: > local Solution Architect> Analysis > Deli XL> Development: > local ATG/Java expertise, leads (Mindcurv Europe) > offshore ATG/Java capacity (Mindcurv India)
  22. 22. Resourcing Vision (2/2)> Testing: > local testers documenting test cases > offshore Testing-as-a-Service (Mindcurv)> Support & maintenance: > mostly offshore > local Service Delivery Manager
  23. 23. Continuous Delivery @ Deli XL 1 Why we did it 2 What we did 3 Demo 4 Discussion
  24. 24. Continuous Delivery @ Deli XL 1 Why we did it 2 What we did 3 Demo 4 Discussion
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×