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

1. Continuous delivery story with FIFA
Introducing best practices in legacy project
Mirosław Jedynak
Architect @ Making Waves
12.12.2012 © MAKING WAVES 1

2. Maslow’s hierarchy
Creativity
Self-esteem
Friends, family
Security of body,
employment
Breathing, food, sleep
12.12.2012 2

3. Revisable
• Source control
Revisable • Revert, branch and merge
• No zip files/shared disk
12.12.2012 3 PROPOSED BY SCOTT HANSELMAN

4. Buildable & deployable
• Able to compile code
Buildable & deployable • Built automatically
• Deploy as easily as you can
build it
Revisable
12.12.2012 © MAKING WAVES 4 PROPOSED BY SCOTT HANSELMAN

5. Maintainable
• Able to fix bugs
Maintainable • Verify them
• Any tests at all?
Buildable & deployable
Revisable
12.12.2012 5 PROPOSED BY SCOTT HANSELMAN

6. Refactorable
• Follow conventions
Refactorable • Refactor without fear
• Automated unit tests
Maintainable
Buildable & deployable
Revisable
12.12.2012 6 PROPOSED BY SCOTT HANSELMAN

7. Pride
• „It’s clear to me”
Pride • „Ok, John was here”
Refactorable
Maintainable
Buildable & deployable
Revisable
12.12.2012 7 PROPOSED BY SCOTT HANSELMAN

8. source: www.wesport.org.uk

9. Day 0
Inherited project evaluation

10. Clever solutions
12.12.2012 © MAKING WAVES 11

11. Code
duplication
12.12.2012 © MAKING WAVES 12

12. Day 1
Transfer source control

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 assemblies
12.12.2012 © MAKING WAVES 14

14. Day 2
Automate build

15. practice where team
members integrate their work
frequently, usually at least
daily - leading to multiple
integrations per day
Continuous Integration

16. Single Source Repository
Automated Build
Self-testing
Easy to get the latest executable

17. Day 3
Establish internal test
environment

18. Testing - inheritance
• Manual test suite
– Army of testers
– Functionality exploration
– Regression
– Input for automation
12.12.2012 © MAKING WAVES 21

19. Testing - improvements
• Unit tests
– Hard to introduce
• Functional acceptance tests
– UI tests
– Fragile
• Smoke tests
– Useful when automating deployment
12.12.2012 © MAKING WAVES 22

20. Testing environment
• Similar to production
– Operating system/IIS version
– Load balancer
• Isolated
• Mocked external systems
12.12.2012 © MAKING WAVES 23

21. How long would it take in your
organization to deploy a change that
involves just a single line of code?
How long would it take to set up
production environment when your
data center blows up?

22. Project goal:
shorten release cycle

23. a set of practices and
principles aimed at
building, testing and
releasing software faster
and more frequently.
Continuous Delivery

24. Last mile
UAT IT
Last mile
12.12.2012 27

25. Developer IT
Customer
Customer
Focus of
Focus of last 10 years continuous delivery
12.12.2012 © MAKING WAVES 28

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 customer's 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. Day 4
Convince customer – business
value

28. Business value
• Feedback from users
– Competitive advantage
– Fail fast and early
12.12.2012 © MAKING WAVES 31

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 Time
12.12.2012 © MAKING WAVES 32

30. Examples
Waiting for 151 hosts
12.12.2012 © MAKING WAVES 33

31. Examples
12.12.2012 © MAKING WAVES 34

32. Most software developed by
large teams spends a significant
proportion of its development
time in an unusable state.

33. Waterfall
Black art
„All hands on board”
„We deploy on Saturday”
Deployment – bad parts

34. Day 5
Design deployment pipeline

35. Deployment pipeline
Dev Tester/PO PO
Version Build & Acceptance Acceptance
Release
control unit test tests tests
Artifacts repository
12.12.2012 © MAKING WAVES 38

36. When it hurts,
do it more often

37. Day 6
Manage environment
configuration

38. It’s easier to break
system by changing
one line of config than
one line of code

39. Configuration types
Environment Environment Application
+
Application
12.12.2012 © MAKING WAVES 43

40. Configuration templating
Configuration Environment- Environment Deployment
template specific &application package
configuration specific
12.12.2012 © MAKING WAVES 44

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. Day 8
Deploy to production

43. Continuous deployment
• Deploy continuoulsy
• After each change
Continuous delivery
• Be production ready
• Release any time
12.12.2012 © MAKING WAVES 49

44. Best practices
How we get there

45. Best practices - Summary
• Version everything
• Similar environment
• Automate existing procedure
• Manage configuration
• Most expensive/risky first
• Deploy never easy - try as soon as possible
12.12.2012 © MAKING WAVES 51

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 often
12.12.2012 © MAKING WAVES 52

47. Q&A
Mirosław Jedynak
m.jedynak@makingwaves.pl
12.12.2012 © MAKING WAVES 53

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 needed
App App
v1.0 v2.0
Expansion Contractions
script v2.0 cript v2.0

49. 12.12.2012 © MAKING WAVES 55