Your SlideShare is downloading. ×
0
Software Dev. Practices – Continuous Integration<br />Agile Mëtteg – June 16th, 2011<br />
ABOUT US<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />2<br />
PROFILE<br />Created in 2004<br />Independent Software Development Company<br />16 June 2011<br />Agile Mëtteg – Continuou...
FIGURES<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />4<br />2,5M€ en 2010<br />32 in 2011<br />
MISSION<br />Design, Develop and Customize “Software as Business & Operational Enabler” <br />Fast & flexible solutions bu...
OUR SERVICES<br />MgtTeamServices<br />4<br />Applications enabling productivity<br />Bespoke application<br />Mobile appl...
OUR MEANS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />7<br />80% > 4 years<br />56% > 8 years<br />3...
OUR MAIN CUSTOMERS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />8<br />
SPEAKERS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />9<br />
About you<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />10<br />
PARTICIPANTS<br />Who are you ?<br />What is your role ?<br />What do you know about agility ?<br />16 June 2011<br />11<b...
INTRODUCTION<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />12<br />
CONTINUOUS INTEGRATION<br />Continuous Integration in a few questions<br />Why do I need it ?<br />What is it ?<br />What ...
SOFTWARE DEVELOPMENT: INDUSTRY? PROCESSES?<br />What is Software Development?<br />an industry mining, farming, constructi...
SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />15<br />
SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />16<br />
« Houston, we’ve got a problem! »<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />17<br />
AGILE MANIFESTO vs SOFTWARE INDUSTRIALIZATION ?<br />Agile Manifesto<br />Individuals and interactions overprocesses and t...
SOFTWARE CRAFTSMANSHIP vs SOFTWARE INDUSTRIALIZATION?<br />Manifesto for Software Craftsmanship<br />Not onlyworking softw...
SOFTWARE DEVELOPMENT: AN ART?<br />Agile Manifesto and Manifesto for Software Craftsmanship were created by veterans of th...
SOFTWARE DEVELOPMENT: AN ART?<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />21<br />
SOFTWARE DEVELOPMENT: AN ART?<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />22<br />
SOFTWARE DEVELOPMENT IS AN ART<br />So, Software Development is an art!<br />But building nearly anything is also an art<b...
RULES AND BEST PRACTICES<br />What’s the worst?<br />Not following therules usually leads to a rather direct and abrupt fa...
RULES AND BEST PRACTICES<br />What’s the worst?<br />Not following the best practices augments, sometimes dramatically, th...
RULES AND BEST PRACTICES<br />What’s the worst?<br />Both are terrible: sources of failure<br />But one is harder to detec...
SOFTWARE QUALITY<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />27<br />
WHAT IS SOFTWARE QUALITY?<br />“Quality is value to some person” (Gerald Weinberg, “Quality Software Management”)<br />i.e...
IMPLICIT FACTORS FOR SOFTWARE QUALITY<br />The software projects typically follow rather detailed requirement plans<br />T...
IMPLICIT FACTORS FOR SOFTWARE QUALITY<br />Conformance to implied requirements:<br />Understandability<br />Completeness<b...
GUARANTEEING CODE QUALITY<br />How can we guarantee the level of quality of software during the « coding » phases?<br />Th...
GUARANTEEING CODE QUALITY<br />Focus on Unit Tests and Test Driven Development (TDD)<br />Unit Tests<br />The first tests ...
GUARANTEEING CODE QUALITY<br />Cyclomatic complexity of a method?<br />the number of linearly independent paths in the met...
GUARANTEEING CODE QUALITY<br />Necessity to put in place the supporting <br />Structures (practices):<br />Unit testing<br...
GUARANTEEING CODE QUALITY<br />How to put in place the supporting <br />Structures (practices):<br />Define and prioritize...
Ci Rules and pre-requisites<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />36<br />
CI RULES AND PRE-REQUISITES (1/3)<br />maintain a code repository<br />automate the build<br />the build must be self-test...
CI RULES AND PRE-REQUISITES (2/3)<br />self-contained modifications<br />i.e. commits don’t break the build process<br />t...
CI RULES AND PRE-REQUISITES (3/3)<br />latest deliverables easily available to anyone who needs them<br />easy access to t...
BUILD INDUSTRIALIZATION PLATFORM<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />40<br />
BUILD INDUSTRIALIZATION PLATFORM<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />41<br />
SOURCE CODE MANAGEMENT<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />42<br />
SOURCE CODE MANAGEMENT<br />What are SCM tools ?<br />Tools that allow sharing and versioning files<br />… but really not ...
SCM RULES FOR CONTINUOUS INTEGRATION<br /><ul><li>Tag your releases
Use branching strategies
Release branches
Feature branches for large changes</li></ul>“branch by abstraction” pattern works well with continuous integration (for no...
SCM RULES FOR CONTINUOUS INTEGRATION<br /><ul><li>Commit “atomically”
all the files related to a single task/issue in one operation </li></ul>or, if really not possible, max a few operations<b...
add a meaningful, standardized comment that (for example) includes:
the task/issue identifier (first line)
status (first line)</li></ul>« completed » or « in progress »<br /><ul><li>short description from the issue tracking syste...
eventually a dedicated URL from the issue tracking system (second line)
a meaningful description of what’s been done (subsequent lines)</li></ul>16 June 2011<br />Agile Mëtteg – Continuous Integ...
SCM RULES FOR CONTINUOUS INTEGRATION<br />The idea is<br /><ul><li>to be able to easily link back a modification (with all...
to be able to take out easily a modification
that should not be included in a specific release
that breaks the build process
that blocks the other developers
that conflicts with other changes
…
keep your code agile ! </li></ul>16 June 2011<br />Agile Mëtteg – Continuous Integration<br />46<br />
List of tasks from issue tracker[“assigned to me”]<br />
Details of a task<br />
Activate a task<br />
Filter: show only <br />files worked on<br />for the currently active task<br />
Modified files <br />grouped by tasks <br />(“atomic” commits)<br />
ISSUE TRACKER<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />55<br />
AUTOMATED BUILD TOOLS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />60<br />
AUTOMATED BUILD TOOLS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />61<br />
AUTOMATED BUILD TOOLS : REPOSITORIES<br />
AUTOMATED BUILD TOOLS : REPOSITORIES<br />
CONTINUOUS INTEGRATION SERVER<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />64<br />
QUALITY ANALYSIS AND REPORTING<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />67<br />
Upcoming SlideShare
Loading in...5
×

Agile Mëtteg - June 2011

1,890

Published on

Continuous Integration and software factories
16 June 2011

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
1,890
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • That’s the answerswe are trying to give in thispresentation
  • Really? If itis the case, whyfailingprojects?
  • At firstsight, the Agile Manifestoseems to beagainst Software Industrialization and processes.Emphasize must begiven on the « over »: itdoesn’tmean « against ». It rathermeans « in favor of …»
  • The Manifesto for Software Craftmanshipalsoseems to beagainst Software Industrialization and processesEmphasize must begiven on the « not only »: itdoesn’tmean « not ».
  • Jazzmen seem to be totally freeHowever they tend to follow a lot of:Rules:Arrangements and compositionsRhythms, pitches, key signatures, transpositionsImprovisation considerations (context, balance, direction, …) Best practices: Themes: “Blues Form” and “Song Form”Scales: Blues, Bebop, Pentatonic, Symmetric, …Introduction, accompaniment, styles of composition
  • Developers seem to be totally freeHowever they tend to follow a lot of:Rules:Standards (« industry » or « de facto »)Specifications (IETF, W3C, OASIS, ISO …)Company levelBest practices: Design patterns and principles (yagni, kiss, dry, …)Clean code, coding conventionsLow coupling, high cohesion …Yagni: You Ain’tGonna Need itKiss: Keep It Straight SimpleDry: Don’t Repeat Yourself
  • Impliedrequirements (mostly):not oftenstatedexplicitly in the productrequirements
  • Static code analysis: analysis performed on the code without it being executed
  • Static code analysis: analysis performed on the code without it being executed
  • Static code analysis: analysis performed on the code without it being executed
  • Notice eachstep in the « Structures » isalsorelated to the correspondentstep in the « Infrastructures »
  • Source Code Management: CVS, PVCS, SourceSafe, Perforce, SVN, Git, Mercurial, Team Foundation Server uses a database (Microsoft SQL Server)Issue Tracker: JIRA,BugZilla, Trac, Team Foundation Server « Work Item Tracking » (integrated in Visual Studio)AutomatedBuild: Ant, Maven, Apache Ivy, Gradle, Team Foundation Server « AutomatedBuild »ContinuousIntegration Server: Hudson, Jenkins, CruiseControl, AtlassianBamboo, JetBrainsTeamCity, Team Foundation Server « Build Agent »QualityAnalysis and Reporting: Maven reports, Hudson plugins, Sonar, Team Foundation Server « Reporting »
  • Source Code Management: CVS, PVCS, SourceSafe, Perforce, SVN, Git, Mercurial, Team Foundation Server uses a database (Microsoft SQL Server)
  • TFS: Team Foundation Server (Microsoft)
  • Standardized: pick a format that all the developers on your project will use and, if possible, apply it for all the projects in your company.
  • The SCM doesn’t enforces the comments, but IDE tools can help:- In Java under Eclipse, the free Mylyn plugin does that –and more- automatically (shown here and in the next slides)- Similar mechanism in IntelliJ IDEAFocus on:the “Task List” view: shows the tasks from the issue tracking systemthe central view: shows the details of one task (also providing interaction with the issue tracking system from the IDE)The “Synchronize” view: shows only the files modified for the selected issue (in order to prepare a commit)The “Package explorer” view [as cherry on the cake]: shows only the modifications linked to the active task (instead of all the files in the project)
  • The SCM doesn’t enforces the comments, but IDE tools can help:- In Java under Eclipse, the free Mylyn plugin does that –and more- automatically (shown here and in the next slides)- Similar mechanism in IntelliJ IDEAFocus on:the “Task List” view: shows the tasks from the issue tracking systemthe central view: shows the details of one task (also providing interaction with the issue tracking system from the IDE)The “Synchronize” view: shows only the files modified for the selected issue (in order to prepare a commit)The “Package explorer” view [as cherry on the cake]: shows only the modifications linked to the active task (instead of all the files in the project)
  • Double clicking a task in the “Task List” view opens a central view that shows the details of the task, also providing interaction with the issue tracking system directly from the IDE
  • “Round” button to activate/deactivate a task. This button is also present next to each task in the “Task List” view (hard to see on this slide, but the active task is shown in bold)Only one task active at a given time
  • The “Package explorer” view: shows only the modifications linked to the active task (instead of all the files in the project)Filter can be on/off (also with a keyboard shortcut to quickly open a file not yet opened so far in the active task)In Bold, files that have been changed more frequently.
  • The “Synchronize” view: group the changed files by task (in order to prepare a commit in a task based mode)
  • The SCM doesn’t enforces the comments, but IDE tools can help:- In Java under Eclipse, the free Mylyn plugin does that –and more- automatically (shown here and in the next slides)- Similar mechanism in IntelliJ IDEAFocus on:the “Task List” view: shows the tasks from the issue tracking systemthe central view: shows the details of one task (also providing interaction with the issue tracking system from the IDE)The “Synchronize” view: shows only the files modified for the selected issue (in order to prepare a commit)The “Package explorer” view [as cherry on the cake]: shows only the modifications linked to the active task (instead of all the files in the project)
  • The SCM doesn’t enforces the comments, but IDE tools can help:- In Java under Eclipse, the free Mylyn plugin does that –and more- automatically (shown here and in the next slides)- Similar mechanism in IntelliJ IDEAFocus on:the “Task List” view: shows the tasks from the issue tracking systemthe central view: shows the details of one task (also providing interaction with the issue tracking system from the IDE)The “Synchronize” view: shows only the files modified for the selected issue (in order to prepare a commit)The “Package explorer” view [as cherry on the cake]: shows only the modifications linked to the active task (instead of all the files in the project)
  • Issue Tracker: JIRA,BugZilla, Trac, Team Foundation Server « Work Item Tracking » (integrated in Visual Studio)
  • AutomatedBuild: Ant, Maven, Apache Ivy, Gradle, Team Foundation Server AutomatedBuild
  • AutomatedBuild: Ant, Maven, Apache Ivy, Gradle, Buildr (Ruby), A-A-P (Python), Cake (Python), SBT (Scala) Team Foundation Server AutomatedBuild, NANT (.Net ANT)
  • ContinuousIntegration Server: Hudson, Jenkins, CruiseControl, AtlassianBamboo, JetBrainsTeamCity, Team Foundation Server « Build Agent »
  • QualityAnalysis and Reporting: Maven reports, Hudson/Jenkins plugins, Sonar, Team Foundation Server « Reporting »
  • Sonar IDE: Plugin to integrate into IDE (here with Eclipse)
  • In time: employee’s involvement (dev teams, management and administrators for the infrastructures)In money: hardware and serversIntensive task = should not be underestimatedROI: Return On Investment
  • Standardized: pick a format that all the developers on your project will use and, if possible, apply it for all the projects in your company.
  • Standardized: pick a format that all the developers on your project will use and, if possible, apply it for all the projects in your company.
  • Transcript of "Agile Mëtteg - June 2011"

    1. 1. Software Dev. Practices – Continuous Integration<br />Agile Mëtteg – June 16th, 2011<br />
    2. 2. ABOUT US<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />2<br />
    3. 3. PROFILE<br />Created in 2004<br />Independent Software Development Company<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />3<br />
    4. 4. FIGURES<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />4<br />2,5M€ en 2010<br />32 in 2011<br />
    5. 5. MISSION<br />Design, Develop and Customize “Software as Business & Operational Enabler” <br />Fast & flexible solutions business value oriented<br />Help IT and all Business & Operational Organizations to adopt the culture of “Software as Business & Operational Enabler”<br />Simple & pragmatic methods making effective the collaboration of the actors of a project<br />Easy and powerful tools for follow-up of relevant KPI<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />5<br />
    6. 6. OUR SERVICES<br />MgtTeamServices<br />4<br />Applications enabling productivity<br />Bespoke application<br />Mobile application<br />Based on package<br />Consulting services <br />Coaching & Support<br />Training<br />Resource delegation<br />1<br />Software<br />Development<br />OpsTeamServices<br />Dev Team Services<br />Agility<br />Agility<br />2<br />3<br />1<br />Agility<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />6<br />2<br />3<br />4<br />
    7. 7. OUR MEANS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />7<br />80% > 4 years<br />56% > 8 years<br />31% > 12 years<br />Agility<br />Authorized Training Center in Luxembourg<br />
    8. 8. OUR MAIN CUSTOMERS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />8<br />
    9. 9. SPEAKERS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />9<br />
    10. 10. About you<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />10<br />
    11. 11. PARTICIPANTS<br />Who are you ?<br />What is your role ?<br />What do you know about agility ?<br />16 June 2011<br />11<br />Agile Mëtteg – Continuous Integration<br />
    12. 12. INTRODUCTION<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />12<br />
    13. 13. CONTINUOUS INTEGRATION<br />Continuous Integration in a few questions<br />Why do I need it ?<br />What is it ?<br />What does it require ?<br />How does it relate to the Agile principles ?<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />13<br />
    14. 14. SOFTWARE DEVELOPMENT: INDUSTRY? PROCESSES?<br />What is Software Development?<br />an industry mining, farming, construction, manufacturing, …etc.<br />with clearly identified and well-defined processes, i.e. easily reproducible<br /> Really?<br /> No failed project?<br /> A lot of…<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />14<br />
    15. 15. SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />15<br />
    16. 16. SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />16<br />
    17. 17. « Houston, we’ve got a problem! »<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />17<br />
    18. 18. AGILE MANIFESTO vs SOFTWARE INDUSTRIALIZATION ?<br />Agile Manifesto<br />Individuals and interactions overprocesses and tools<br />Working softwareovercomprehensive documentation<br />Customer collaboration overcontract negotiation<br />Responding to change overfollowing a plan<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />18<br />
    19. 19. SOFTWARE CRAFTSMANSHIP vs SOFTWARE INDUSTRIALIZATION?<br />Manifesto for Software Craftsmanship<br />Not onlyworking software, but alsowell-crafted software<br />Not onlyresponding to change, but alsosteadily adding value<br />Not onlyindividuals and interactions, but alsoa community of professionals<br />Not onlycustomer collaboration, but alsoproductive partnerships<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />19<br />
    20. 20. SOFTWARE DEVELOPMENT: AN ART?<br />Agile Manifesto and Manifesto for Software Craftsmanship were created by veterans of the software industry<br />However, when summed up, one can conclude software development is more an art than an industrial process<br />So, let’s compare with music…<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />20<br />
    21. 21. SOFTWARE DEVELOPMENT: AN ART?<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />21<br />
    22. 22. SOFTWARE DEVELOPMENT: AN ART?<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />22<br />
    23. 23. SOFTWARE DEVELOPMENT IS AN ART<br />So, Software Development is an art!<br />But building nearly anything is also an art<br />Don’t you think?<br />And, more importantly,<br />Art is not without rules <br />and best practices<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />23<br />
    24. 24. RULES AND BEST PRACTICES<br />What’s the worst?<br />Not following therules usually leads to a rather direct and abrupt failure<br />project fails integration testing <br />project is refused by infrastructure<br />project fails user acceptance testing<br />…<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />24<br />
    25. 25. RULES AND BEST PRACTICES<br />What’s the worst?<br />Not following the best practices augments, sometimes dramatically, the risks of failure<br />reduces overall quality<br />increases the time to market / time to deliver<br />has typically a pervasive effect: can be ignored or remains unknown until it becomes really critical<br />increases the maintenance and ownership costs<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />25<br />
    26. 26. RULES AND BEST PRACTICES<br />What’s the worst?<br />Both are terrible: sources of failure<br />But one is harder to detect than the other<br />Necessity to put in place and to define the structures and infrastructures required to check the quality at every level<br />Because “the earlier, the best” (and less expensive)<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />26<br />
    27. 27. SOFTWARE QUALITY<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />27<br />
    28. 28. WHAT IS SOFTWARE QUALITY?<br />“Quality is value to some person” (Gerald Weinberg, “Quality Software Management”)<br />i.e. quality is inherently subjective; people experience the quality of the same software very differently<br />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)<br />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<br />Steve McConnell defines external and internal quality characteristics (‘”Code Complete”)<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />28<br />
    29. 29. IMPLICIT FACTORS FOR SOFTWARE QUALITY<br />The software projects typically follow rather detailed requirement plans<br />Though a set of characteristics often goes unmentioned<br />These are the implied requirements that are expected of all professionally developed software<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />29<br />
    30. 30. IMPLICIT FACTORS FOR SOFTWARE QUALITY<br />Conformance to implied requirements:<br />Understandability<br />Completeness<br />Conciseness<br />Portability<br />Maintainability<br />Testability<br />Usability<br />Reliability<br />Efficiency<br />Security<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />30<br />
    31. 31. GUARANTEEING CODE QUALITY<br />How can we guarantee the level of quality of software during the « coding » phases?<br />The same ways as in the industry<br />Factory inspections: “static code analysis” in IT<br />Incremental improvements: “release soon, release often” in IT<br />Tests, tests, tests, tests, tests, tests, …<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />31<br />
    32. 32. GUARANTEEING CODE QUALITY<br />Focus on Unit Tests and Test Driven Development (TDD)<br />Unit Tests<br />The first tests to write<br />Written by the developers before the code<br />Write the code afterward to make the tests succeed<br />Must run in isolation, without any infrastructure<br />Must be fast to execute<br />How many unit tests per method ?<br />One test per degree of “cyclomatic complexity”<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />32<br />
    33. 33. GUARANTEEING CODE QUALITY<br />Cyclomatic complexity of a method?<br />the number of linearly independent paths in the method<br />If .. and .. then<br />If .. or .. then<br />If .. then<br />If .. then .. else<br />Do .. While<br />While .. Do<br />Switch<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />33<br />
    34. 34. GUARANTEEING CODE QUALITY<br />Necessity to put in place the supporting <br />Structures (practices):<br />Unit testing<br />Integration testing<br />Performance testing<br />Regression testing<br />Acceptance testing<br />Infrastructures (tools):<br />Source Code management<br />Issue tracking<br />Build tools<br />Continuous Integration server<br />Quality reporting tools<br />Agility<br />Build Industrialization<br />Build Industrialization<br />Platform<br />Agility<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />34<br />
    35. 35. GUARANTEEING CODE QUALITY<br />How to put in place the supporting <br />Structures (practices):<br />Define and prioritize the quality requirements<br />Refine and adapt the relevant quality criteria to the objectives<br />Communicate rules and best practices: sharing, training and mentoring<br />Verify the correct usage and level of adoption<br />Review the results and improve the processes<br />Infrastructures (tools):<br />Select the tools adapted to the defined quality requirements<br />Set them up based on the selected criteria (define measurements)<br />Communicate on their usage: sharing, training and mentoring<br />Generate quality reports and metrics<br />Analyze the conformance of the results and adapt the tools<br />Agility<br />Agility<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />35<br />
    36. 36. Ci Rules and pre-requisites<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />36<br />
    37. 37. CI RULES AND PRE-REQUISITES (1/3)<br />maintain a code repository<br />automate the build<br />the build must be self-testing<br />regular code sharing<br />i.e. frequent commits<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />37<br />
    38. 38. CI RULES AND PRE-REQUISITES (2/3)<br />self-contained modifications<br />i.e. commits don’t break the build process<br />the build must be fast<br />integration tests (for the least) in a clone of the production environment<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />38<br />
    39. 39. CI RULES AND PRE-REQUISITES (3/3)<br />latest deliverables easily available to anyone who needs them<br />easy access to the results of the tests<br />automated deployments to a live test server<br />continous deployment to production is the ideal achievement<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />39<br />
    40. 40. BUILD INDUSTRIALIZATION PLATFORM<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />40<br />
    41. 41. BUILD INDUSTRIALIZATION PLATFORM<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />41<br />
    42. 42. SOURCE CODE MANAGEMENT<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />42<br />
    43. 43. SOURCE CODE MANAGEMENT<br />What are SCM tools ?<br />Tools that allow sharing and versioning files<br />… but really not their primary interest …<br />… shared folders can do that too !<br />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<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />43<br />
    44. 44. SCM RULES FOR CONTINUOUS INTEGRATION<br /><ul><li>Tag your releases
    45. 45. Use branching strategies
    46. 46. Release branches
    47. 47. Feature branches for large changes</li></ul>“branch by abstraction” pattern works well with continuous integration (for non-distributed SCM’s like CVS, SVN, TFS…)<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />44<br />
    48. 48. SCM RULES FOR CONTINUOUS INTEGRATION<br /><ul><li>Commit “atomically”
    49. 49. all the files related to a single task/issue in one operation </li></ul>or, if really not possible, max a few operations<br /><ul><li>don’t mix changes from different tasks/issues in the same commit
    50. 50. add a meaningful, standardized comment that (for example) includes:
    51. 51. the task/issue identifier (first line)
    52. 52. status (first line)</li></ul>« completed » or « in progress »<br /><ul><li>short description from the issue tracking system (first line)
    53. 53. eventually a dedicated URL from the issue tracking system (second line)
    54. 54. a meaningful description of what’s been done (subsequent lines)</li></ul>16 June 2011<br />Agile Mëtteg – Continuous Integration<br />45<br />
    55. 55. SCM RULES FOR CONTINUOUS INTEGRATION<br />The idea is<br /><ul><li>to be able to easily link back a modification (with all its related changes) to an issue from the issue tracker
    56. 56. to be able to take out easily a modification
    57. 57. that should not be included in a specific release
    58. 58. that breaks the build process
    59. 59. that blocks the other developers
    60. 60. that conflicts with other changes
    61. 61.
    62. 62. keep your code agile ! </li></ul>16 June 2011<br />Agile Mëtteg – Continuous Integration<br />46<br />
    63. 63.
    64. 64. List of tasks from issue tracker[“assigned to me”]<br />
    65. 65. Details of a task<br />
    66. 66. Activate a task<br />
    67. 67. Filter: show only <br />files worked on<br />for the currently active task<br />
    68. 68. Modified files <br />grouped by tasks <br />(“atomic” commits)<br />
    69. 69.
    70. 70.
    71. 71. ISSUE TRACKER<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />55<br />
    72. 72.
    73. 73.
    74. 74.
    75. 75.
    76. 76. AUTOMATED BUILD TOOLS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />60<br />
    77. 77. AUTOMATED BUILD TOOLS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />61<br />
    78. 78. AUTOMATED BUILD TOOLS : REPOSITORIES<br />
    79. 79. AUTOMATED BUILD TOOLS : REPOSITORIES<br />
    80. 80. CONTINUOUS INTEGRATION SERVER<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />64<br />
    81. 81.
    82. 82.
    83. 83. QUALITY ANALYSIS AND REPORTING<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />67<br />
    84. 84.
    85. 85.
    86. 86.
    87. 87.
    88. 88.
    89. 89. QUALITY METRICS IN THE IDE<br />
    90. 90. WRAP-UP<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />74<br />
    91. 91. CONCLUSIONS<br />Guaranteeing code quality is an intensive task<br />In time<br />In money<br />Continuous Integration pays back and offers a lot<br />Has a high ROI<br />Cost of ownership reduces over time<br />It can be applied incrementally<br />Agility should be the driving backbone for its adoption<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />75<br />
    92. 92. RESOURCES<br />Gartner’s study ID “G00151721” http://condor.depaul.edu/~dmumaugh/readings/handouts/SE477/Gartner%20Reports/from_the_cio_trenches_why_so_151721.pdf<br />Standish Group’s Chaos Reporthttp://www.standishgroup.com/services.php<br />“Quality Software Management : Systems Thinking”Gerald Weinberg, 1991, ISBN 978-0932633729<br />“Code Complete”, Microsoft Programming SeriesSteve McConnell, 1993, ISBN 978-1556154843<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />76<br />
    93. 93. RESOURCES<br />CVS http://www.nongnu.org/cvs/<br />Subversion (SVN) http://subversion.apache.org/<br />Maven http://maven.apache.org/<br />Ant http://ant.apache.org/<br />Nanthttp://nant.sourceforge.net/<br />Ivy http://ant.apache.org/ivy/<br />EasyAnthttp://www.easyant.org/<br />Gradlehttp://www.gradle.org/<br />Buildrhttp://buildr.apache.org/<br />Gant http://gant.codehaus.org/<br />Jenkins CI http://jenkins-ci.org/<br />Hudson CI http://hudson-ci.org/<br />Sonar http://www.sonarsource.org/<br />Microsoft Team Foundation Server http://www.microsoft.com/visualstudio/en-us/products/2010-editions/team-foundation-server/<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />77<br />
    94. 94. RESOURCES<br />Agile Partner: www.agilepartner.net<br />&Blog: http://blog.agilepartner.net<br />Trainings<br />http://www.agilepartner.net/formations/coup-de-projecteur-sur/?lang=fr<br />Agile Interest Group LU: www.aiglu.org<br />Agile Tour Luxembourg8 November 2011<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />78<br />
    95. 95. CONTACTS<br />Thank You<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />79<br />
    96. 96. DEBRIEFING<br />Questions ?<br />5 fingers vote<br />1 = useless<br />“I gained nothing. I completely lost my time!”<br />2 = useful<br />“It wasn’t worth all the time spent on it. I lost most of my time”<br />3 = average<br />“I gained enough to justify the time spent on”<br />4 = above average<br /> “Good value, I gained more than the time spent”<br />5 = excellent<br />“Really useful session, time well spent”<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />80<br />
    97. 97. EXTRAS<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />81<br />
    98. 98. BRANCH BY ABSTRACTION<br />“Branch by abstraction” <br />all the changes are done in the same place, same location in the SCM<br />no need to merge (hazardously) a lot of code from the feature branch<br />history of the changes stays easy to follow <br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />82<br />
    99. 99. BRANCH BY ABSTRACTION<br />“Branch by abstraction”<br />Cookbook:<br />Introduce an abstraction over the core bits of the big thing you are going to change<br />Update all the bits of code that were formerly using the thing directly to use it via the new abstraction<br />Make a second implementation of the abstraction, with unit tests that specifically test its core functionality<br />Update all the code to use the new implementation<br />Deprecate the first implementation<br />Delete the first implementation (there is no need to go back)<br />Remove the abstraction (only if it is inelegant, not often the case)<br />16 June 2011<br />Agile Mëtteg – Continuous Integration<br />83<br />
    1. A particular slide catching your eye?

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

    ×