Continuous Delivery story with FIFA (Wroc.net - 2012.12.11)

344 views
276 views

Published on

Continuous Delivery is the process of having a shippable product after each check-in to the source control repository. Continuous Delivery is usually implemented as a natural improvement of a Continuous Integration process. This presentation highlights challenges and presents hints on how to start from a raw environment and incrementally build a successful deployment pipeline based on Team Foundation Server (TFS), providing substantial added-value for business.

This presentation will describe the process of establishing Continuous Delivery in a project for FIFA. We describe the starting point, what we achieve in the first phases and what are the plans for further improvements in order to deliver high quality software in schedules defined by business needs – not by process and technology constraints.

http://blog.m.jedynak.pl/2012/06/continuous-delivery-story-with-fifa.html

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

  • Be the first to like this

No Downloads
Views
Total views
344
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Continuous Delivery story with FIFA (Wroc.net - 2012.12.11)

  1. 1. Continuous delivery story with FIFAIntroducing best practices in legacy projectMirosław JedynakArchitect @ Making Waves12.12.2012 © MAKING WAVES 1
  2. 2. Maslow’s hierarchy Creativity Self-esteem Friends, family Security of body, employment Breathing, food, sleep12.12.2012 2
  3. 3. Revisable • Source control Revisable • Revert, branch and merge • No zip files/shared disk12.12.2012 3 PROPOSED BY SCOTT HANSELMAN
  4. 4. Buildable & deployable • Able to compile code Buildable & deployable • Built automatically • Deploy as easily as you can build it Revisable12.12.2012 © MAKING WAVES 4 PROPOSED BY SCOTT HANSELMAN
  5. 5. Maintainable • Able to fix bugs Maintainable • Verify them • Any tests at all? Buildable & deployable Revisable12.12.2012 5 PROPOSED BY SCOTT HANSELMAN
  6. 6. Refactorable • Follow conventions Refactorable • Refactor without fear • Automated unit tests Maintainable Buildable & deployable Revisable12.12.2012 6 PROPOSED BY SCOTT HANSELMAN
  7. 7. Pride • „It’s clear to me” Pride • „Ok, John was here” Refactorable Maintainable Buildable & deployable Revisable12.12.2012 7 PROPOSED BY SCOTT HANSELMAN
  8. 8. source: www.wesport.org.uk
  9. 9. Day 0Inherited project evaluation
  10. 10. Clever solutions12.12.2012 © MAKING WAVES 11
  11. 11. Code duplication12.12.2012 © MAKING WAVES 12
  12. 12. Day 1Transfer source control
  13. 13. Revisable at FIFA• Multiple SVN repositories – Code duplication between repositories Pride – Missing revisions Refactorable• Sometimes challenging to obtain code deployed to production Maintainable – Assemblies without clear source – Not versioned Buildable & deployable• Changes directly on production Revisable – In markup (aspx) – In assemblies12.12.2012 © MAKING WAVES 14
  14. 14. Day 2Automate build
  15. 15. practice where teammembers integrate their workfrequently, usually at leastdaily - leading to multipleintegrations per dayContinuous Integration
  16. 16. Single Source RepositoryAutomated BuildSelf-testingEasy to get the latest executable
  17. 17. Day 3Establish internal testenvironment
  18. 18. Testing - inheritance• Manual test suite – Army of testers – Functionality exploration – Regression – Input for automation12.12.2012 © MAKING WAVES 21
  19. 19. Testing - improvements• Unit tests – Hard to introduce• Functional acceptance tests – UI tests – Fragile• Smoke tests – Useful when automating deployment12.12.2012 © MAKING WAVES 22
  20. 20. Testing environment• Similar to production – Operating system/IIS version – Load balancer• Isolated• Mocked external systems12.12.2012 © MAKING WAVES 23
  21. 21. How long would it take in yourorganization to deploy a change thatinvolves just a single line of code?How long would it take to set upproduction environment when yourdata center blows up?
  22. 22. Project goal:shorten release cycle
  23. 23. a set of practices andprinciples aimed atbuilding, testing andreleasing software fasterand more frequently.Continuous Delivery
  24. 24. Last mile UAT IT Last mile12.12.2012 27
  25. 25. Developer IT Customer Customer Focus of Focus of last 10 years continuous delivery12.12.2012 © MAKING WAVES 28
  26. 26. http://agilemanifesto.org/principles.html Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. 12.12.2012 Give them the environment and support they need, © MAKING WAVES 29
  27. 27. Day 4Convince customer – businessvalue
  28. 28. Business value• Feedback from users – Competitive advantage – Fail fast and early12.12.2012 © MAKING WAVES 31
  29. 29. Business value• Feedback from users – Competitive advantage – Fail fast and early• Reduced risks of release – Automated Change Change• Real progress less changes – Definition of done frequently• Quicker return of investment Time Time12.12.2012 © MAKING WAVES 32
  30. 30. Examples Waiting for 151 hosts12.12.2012 © MAKING WAVES 33
  31. 31. Examples12.12.2012 © MAKING WAVES 34
  32. 32. Most software developed bylarge teams spends a significantproportion of its developmenttime in an unusable state.
  33. 33. Waterfall Black art„All hands on board” „We deploy on Saturday” Deployment – bad parts
  34. 34. Day 5Design deployment pipeline
  35. 35. Deployment pipeline Dev Tester/PO POVersion Build & Acceptance Acceptance Releasecontrol unit test tests tests Artifacts repository12.12.2012 © MAKING WAVES 38
  36. 36. When it hurts,do it more often
  37. 37. Day 6Manage environmentconfiguration
  38. 38. It’s easier to breaksystem by changingone line of config thanone line of code
  39. 39. Configuration types Environment Environment Application + Application12.12.2012 © MAKING WAVES 43
  40. 40. Configuration templatingConfiguration Environment- Environment Deployment template specific &application package configuration specific 12.12.2012 © MAKING WAVES 44
  41. 41. Troubles Hotfix* Rollback * Deploy last good version * Rollback scripts less tested than deployment * Avoid Fix-forward fire* Hotfix * Follow regular deployment pipeline * It is a tested path * It has known time of deployment
  42. 42. Day 8Deploy to production
  43. 43. Continuous deployment • Deploy continuoulsy • After each changeContinuous delivery• Be production ready• Release any time12.12.2012 © MAKING WAVES 49
  44. 44. Best practicesHow we get there
  45. 45. Best practices - Summary• Version everything• Similar environment• Automate existing procedure• Manage configuration• Most expensive/risky first• Deploy never easy - try as soon as possible12.12.2012 © MAKING WAVES 51
  46. 46. Doubts/Fears• Setup time – Sum up deployment and fix times• Replacing software – Release to beta environment for early adopters• Confidence in automation – Do it more often12.12.2012 © MAKING WAVES 52
  47. 47. Q&A Mirosław Jedynak m.jedynak@makingwaves.pl12.12.2012 © MAKING WAVES 53
  48. 48. Database deployment• separate database migrations – expansion scripts - changes not breaking backwards compatibility with the existing version – contraction scripts - clean up any database structure that is no longer neededApp Appv1.0 v2.0 Expansion Contractions script v2.0 cript v2.0
  49. 49. 12.12.2012 © MAKING WAVES 55

×