Continuous Integration and software factories 16 June 2011

1. Software Dev. Practices – Continuous Integration Agile Mëtteg – June 16th, 2011

2. ABOUT US 16 June 2011 Agile Mëtteg – Continuous Integration 2

3. PROFILE Created in 2004 Independent Software Development Company 16 June 2011 Agile Mëtteg – Continuous Integration 3

4. FIGURES 16 June 2011 Agile Mëtteg – Continuous Integration 4 2,5M€ en 2010 32 in 2011

5. MISSION Design, Develop and Customize “Software as Business & Operational Enabler” Fast & flexible solutions business value oriented Help IT and all Business & Operational Organizations to adopt the culture of “Software as Business & Operational Enabler” Simple & pragmatic methods making effective the collaboration of the actors of a project Easy and powerful tools for follow-up of relevant KPI 16 June 2011 Agile Mëtteg – Continuous Integration 5

6. OUR SERVICES MgtTeamServices 4 Applications enabling productivity Bespoke application Mobile application Based on package Consulting services Coaching & Support Training Resource delegation 1 Software Development OpsTeamServices Dev Team Services Agility Agility 2 3 1 Agility 16 June 2011 Agile Mëtteg – Continuous Integration 6 2 3 4

7. OUR MEANS 16 June 2011 Agile Mëtteg – Continuous Integration 7 80% > 4 years 56% > 8 years 31% > 12 years Agility Authorized Training Center in Luxembourg

8. OUR MAIN CUSTOMERS 16 June 2011 Agile Mëtteg – Continuous Integration 8

9. SPEAKERS 16 June 2011 Agile Mëtteg – Continuous Integration 9

10. About you 16 June 2011 Agile Mëtteg – Continuous Integration 10

11. PARTICIPANTS Who are you ? What is your role ? What do you know about agility ? 16 June 2011 11 Agile Mëtteg – Continuous Integration

12. INTRODUCTION 16 June 2011 Agile Mëtteg – Continuous Integration 12

13. CONTINUOUS INTEGRATION Continuous Integration in a few questions Why do I need it ? What is it ? What does it require ? How does it relate to the Agile principles ? 16 June 2011 Agile Mëtteg – Continuous Integration 13

14. SOFTWARE DEVELOPMENT: INDUSTRY? PROCESSES? What is Software Development? an industry mining, farming, construction, manufacturing, …etc. with clearly identified and well-defined processes, i.e. easily reproducible Really? No failed project? A lot of… 16 June 2011 Agile Mëtteg – Continuous Integration 14

15. SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS 16 June 2011 Agile Mëtteg – Continuous Integration 15

16. SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS 16 June 2011 Agile Mëtteg – Continuous Integration 16

17. « Houston, we’ve got a problem! » 16 June 2011 Agile Mëtteg – Continuous Integration 17

18. AGILE MANIFESTO vs SOFTWARE INDUSTRIALIZATION ? Agile Manifesto Individuals and interactions overprocesses and tools Working softwareovercomprehensive documentation Customer collaboration overcontract negotiation Responding to change overfollowing a plan 16 June 2011 Agile Mëtteg – Continuous Integration 18

19. SOFTWARE CRAFTSMANSHIP vs SOFTWARE INDUSTRIALIZATION? Manifesto for Software Craftsmanship Not onlyworking software, but alsowell-crafted software Not onlyresponding to change, but alsosteadily adding value Not onlyindividuals and interactions, but alsoa community of professionals Not onlycustomer collaboration, but alsoproductive partnerships 16 June 2011 Agile Mëtteg – Continuous Integration 19

20. SOFTWARE DEVELOPMENT: AN ART? Agile Manifesto and Manifesto for Software Craftsmanship were created by veterans of the software industry However, when summed up, one can conclude software development is more an art than an industrial process So, let’s compare with music… 16 June 2011 Agile Mëtteg – Continuous Integration 20

21. SOFTWARE DEVELOPMENT: AN ART? 16 June 2011 Agile Mëtteg – Continuous Integration 21

22. SOFTWARE DEVELOPMENT: AN ART? 16 June 2011 Agile Mëtteg – Continuous Integration 22

23. SOFTWARE DEVELOPMENT IS AN ART So, Software Development is an art! But building nearly anything is also an art Don’t you think? And, more importantly, Art is not without rules and best practices 16 June 2011 Agile Mëtteg – Continuous Integration 23

24. RULES AND BEST PRACTICES What’s the worst? Not following therules usually leads to a rather direct and abrupt failure project fails integration testing project is refused by infrastructure project fails user acceptance testing … 16 June 2011 Agile Mëtteg – Continuous Integration 24

25. RULES AND BEST PRACTICES What’s the worst? Not following the best practices augments, sometimes dramatically, the risks of failure reduces overall quality increases the time to market / time to deliver has typically a pervasive effect: can be ignored or remains unknown until it becomes really critical increases the maintenance and ownership costs 16 June 2011 Agile Mëtteg – Continuous Integration 25

26. RULES AND BEST PRACTICES What’s the worst? Both are terrible: sources of failure But one is harder to detect than the other Necessity to put in place and to define the structures and infrastructures required to check the quality at every level Because “the earlier, the best” (and less expensive) 16 June 2011 Agile Mëtteg – Continuous Integration 26

27. SOFTWARE QUALITY 16 June 2011 Agile Mëtteg – Continuous Integration 27

28. WHAT IS SOFTWARE QUALITY? “Quality is value to some person” (Gerald Weinberg, “Quality Software Management”) i.e. quality is inherently subjective; people experience the quality of the same software very differently this applies mainly to the quality of a software product, as perceived from an external view; and it can also comprise the quality of its running environment(s) but the quality of the source code can also have an impact on the efforts needed for having a software product that fulfills the requirements, the intrinsicquality Steve McConnell defines external and internal quality characteristics (‘”Code Complete”) 16 June 2011 Agile Mëtteg – Continuous Integration 28

29. IMPLICIT FACTORS FOR SOFTWARE QUALITY The software projects typically follow rather detailed requirement plans Though a set of characteristics often goes unmentioned These are the implied requirements that are expected of all professionally developed software 16 June 2011 Agile Mëtteg – Continuous Integration 29

30. IMPLICIT FACTORS FOR SOFTWARE QUALITY Conformance to implied requirements: Understandability Completeness Conciseness Portability Maintainability Testability Usability Reliability Efficiency Security 16 June 2011 Agile Mëtteg – Continuous Integration 30

31. GUARANTEEING CODE QUALITY How can we guarantee the level of quality of software during the « coding » phases? The same ways as in the industry Factory inspections: “static code analysis” in IT Incremental improvements: “release soon, release often” in IT Tests, tests, tests, tests, tests, tests, … 16 June 2011 Agile Mëtteg – Continuous Integration 31

32. GUARANTEEING CODE QUALITY Focus on Unit Tests and Test Driven Development (TDD) Unit Tests The first tests to write Written by the developers before the code Write the code afterward to make the tests succeed Must run in isolation, without any infrastructure Must be fast to execute How many unit tests per method ? One test per degree of “cyclomatic complexity” 16 June 2011 Agile Mëtteg – Continuous Integration 32

33. GUARANTEEING CODE QUALITY Cyclomatic complexity of a method? the number of linearly independent paths in the method If .. and .. then If .. or .. then If .. then If .. then .. else Do .. While While .. Do Switch 16 June 2011 Agile Mëtteg – Continuous Integration 33

34. GUARANTEEING CODE QUALITY Necessity to put in place the supporting Structures (practices): Unit testing Integration testing Performance testing Regression testing Acceptance testing Infrastructures (tools): Source Code management Issue tracking Build tools Continuous Integration server Quality reporting tools Agility Build Industrialization Build Industrialization Platform Agility 16 June 2011 Agile Mëtteg – Continuous Integration 34

35. GUARANTEEING CODE QUALITY How to put in place the supporting Structures (practices): Define and prioritize the quality requirements Refine and adapt the relevant quality criteria to the objectives Communicate rules and best practices: sharing, training and mentoring Verify the correct usage and level of adoption Review the results and improve the processes Infrastructures (tools): Select the tools adapted to the defined quality requirements Set them up based on the selected criteria (define measurements) Communicate on their usage: sharing, training and mentoring Generate quality reports and metrics Analyze the conformance of the results and adapt the tools Agility Agility 16 June 2011 Agile Mëtteg – Continuous Integration 35

36. Ci Rules and pre-requisites 16 June 2011 Agile Mëtteg – Continuous Integration 36

37. CI RULES AND PRE-REQUISITES (1/3) maintain a code repository automate the build the build must be self-testing regular code sharing i.e. frequent commits 16 June 2011 Agile Mëtteg – Continuous Integration 37

38. CI RULES AND PRE-REQUISITES (2/3) self-contained modifications i.e. commits don’t break the build process the build must be fast integration tests (for the least) in a clone of the production environment 16 June 2011 Agile Mëtteg – Continuous Integration 38

39. CI RULES AND PRE-REQUISITES (3/3) latest deliverables easily available to anyone who needs them easy access to the results of the tests automated deployments to a live test server continous deployment to production is the ideal achievement 16 June 2011 Agile Mëtteg – Continuous Integration 39

40. BUILD INDUSTRIALIZATION PLATFORM 16 June 2011 Agile Mëtteg – Continuous Integration 40

41. BUILD INDUSTRIALIZATION PLATFORM 16 June 2011 Agile Mëtteg – Continuous Integration 41

42. SOURCE CODE MANAGEMENT 16 June 2011 Agile Mëtteg – Continuous Integration 42

43. SOURCE CODE MANAGEMENT What are SCM tools ? Tools that allow sharing and versioning files … but really not their primary interest … … shared folders can do that too ! Tools to track and document the changes in the code, in such a way the developers can work in a task or issue oriented mode 16 June 2011 Agile Mëtteg – Continuous Integration 43

45. Use branching strategies

46. Release branches

47. Feature branches for large changes“branch by abstraction” pattern works well with continuous integration (for non-distributed SCM’s like CVS, SVN, TFS…) 16 June 2011 Agile Mëtteg – Continuous Integration 44

50. add a meaningful, standardized comment that (for example) includes:

51. the task/issue identifier (first line)

53. eventually a dedicated URL from the issue tracking system (second line)

54. a meaningful description of what’s been done (subsequent lines)16 June 2011 Agile Mëtteg – Continuous Integration 45

56. to be able to take out easily a modification

57. that should not be included in a specific release

58. that breaks the build process

59. that blocks the other developers

60. that conflicts with other changes

61. …

62. keep your code agile ! 16 June 2011 Agile Mëtteg – Continuous Integration 46

64. List of tasks from issue tracker[“assigned to me”]

65. Details of a task

66. Activate a task

67. Filter: show only files worked on for the currently active task

68. Modified files grouped by tasks (“atomic” commits)

71. ISSUE TRACKER 16 June 2011 Agile Mëtteg – Continuous Integration 55

76. AUTOMATED BUILD TOOLS 16 June 2011 Agile Mëtteg – Continuous Integration 60

77. AUTOMATED BUILD TOOLS 16 June 2011 Agile Mëtteg – Continuous Integration 61

78. AUTOMATED BUILD TOOLS : REPOSITORIES

79. AUTOMATED BUILD TOOLS : REPOSITORIES

80. CONTINUOUS INTEGRATION SERVER 16 June 2011 Agile Mëtteg – Continuous Integration 64

83. QUALITY ANALYSIS AND REPORTING 16 June 2011 Agile Mëtteg – Continuous Integration 67

89. QUALITY METRICS IN THE IDE

90. WRAP-UP 16 June 2011 Agile Mëtteg – Continuous Integration 74

91. CONCLUSIONS Guaranteeing code quality is an intensive task In time In money Continuous Integration pays back and offers a lot Has a high ROI Cost of ownership reduces over time It can be applied incrementally Agility should be the driving backbone for its adoption 16 June 2011 Agile Mëtteg – Continuous Integration 75

92. RESOURCES Gartner’s study ID “G00151721” http://condor.depaul.edu/~dmumaugh/readings/handouts/SE477/Gartner%20Reports/from_the_cio_trenches_why_so_151721.pdf Standish Group’s Chaos Reporthttp://www.standishgroup.com/services.php “Quality Software Management : Systems Thinking”Gerald Weinberg, 1991, ISBN 978-0932633729 “Code Complete”, Microsoft Programming SeriesSteve McConnell, 1993, ISBN 978-1556154843 16 June 2011 Agile Mëtteg – Continuous Integration 76

93. RESOURCES CVS http://www.nongnu.org/cvs/ Subversion (SVN) http://subversion.apache.org/ Maven http://maven.apache.org/ Ant http://ant.apache.org/ Nanthttp://nant.sourceforge.net/ Ivy http://ant.apache.org/ivy/ EasyAnthttp://www.easyant.org/ Gradlehttp://www.gradle.org/ Buildrhttp://buildr.apache.org/ Gant http://gant.codehaus.org/ Jenkins CI http://jenkins-ci.org/ Hudson CI http://hudson-ci.org/ Sonar http://www.sonarsource.org/ Microsoft Team Foundation Server http://www.microsoft.com/visualstudio/en-us/products/2010-editions/team-foundation-server/ 16 June 2011 Agile Mëtteg – Continuous Integration 77

94. RESOURCES Agile Partner: www.agilepartner.net &Blog: http://blog.agilepartner.net Trainings http://www.agilepartner.net/formations/coup-de-projecteur-sur/?lang=fr Agile Interest Group LU: www.aiglu.org Agile Tour Luxembourg8 November 2011 16 June 2011 Agile Mëtteg – Continuous Integration 78

95. CONTACTS Thank You 16 June 2011 Agile Mëtteg – Continuous Integration 79

96. DEBRIEFING Questions ? 5 fingers vote 1 = useless “I gained nothing. I completely lost my time!” 2 = useful “It wasn’t worth all the time spent on it. I lost most of my time” 3 = average “I gained enough to justify the time spent on” 4 = above average “Good value, I gained more than the time spent” 5 = excellent “Really useful session, time well spent” 16 June 2011 Agile Mëtteg – Continuous Integration 80

97. EXTRAS 16 June 2011 Agile Mëtteg – Continuous Integration 81

98. BRANCH BY ABSTRACTION “Branch by abstraction” all the changes are done in the same place, same location in the SCM no need to merge (hazardously) a lot of code from the feature branch history of the changes stays easy to follow 16 June 2011 Agile Mëtteg – Continuous Integration 82

99. BRANCH BY ABSTRACTION “Branch by abstraction” Cookbook: Introduce an abstraction over the core bits of the big thing you are going to change Update all the bits of code that were formerly using the thing directly to use it via the new abstraction Make a second implementation of the abstraction, with unit tests that specifically test its core functionality Update all the code to use the new implementation Deprecate the first implementation Delete the first implementation (there is no need to go back) Remove the abstraction (only if it is inelegant, not often the case) 16 June 2011 Agile Mëtteg – Continuous Integration 83