Continuous Integration

Software Dev. Practices – Continuous IntegrationAgile Mëtteg – June 16th, 2011

ABOUT US16 June 2011Agile Mëtteg – Continuous Integration2

PROFILECreated in 2004Independent Software Development Company16 June 2011Agile Mëtteg – Continuous Integration3

FIGURES16 June 2011Agile Mëtteg – Continuous Integration42,5M€ en 201032 in 2011

MISSIONDesign, Develop and Customize “Software as Business & Operational Enabler” Fast & flexible solutions business value orientedHelp 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 projectEasy and powerful tools for follow-up of relevant KPI16 June 2011Agile Mëtteg – Continuous Integration5

OUR SERVICESMgtTeamServices4Applications enabling productivityBespoke applicationMobile applicationBased on packageConsulting services Coaching & SupportTrainingResource delegation1SoftwareDevelopmentOpsTeamServicesDev Team ServicesAgilityAgility231Agility16 June 2011Agile Mëtteg – Continuous Integration6234

OUR MEANS16 June 2011Agile Mëtteg – Continuous Integration780% > 4 years56% > 8 years31% > 12 yearsAgilityAuthorized Training Center in Luxembourg

OUR MAIN CUSTOMERS16 June 2011Agile Mëtteg – Continuous Integration8

SPEAKERS16 June 2011Agile Mëtteg – Continuous Integration9

About you16 June 2011Agile Mëtteg – Continuous Integration10

PARTICIPANTSWho are you ?What is your role ?What do you know about agility ?16 June 201111Agile Mëtteg – Continuous Integration

INTRODUCTION16 June 2011Agile Mëtteg – Continuous Integration12

CONTINUOUS INTEGRATIONContinuous Integration in a few questionsWhy do I need it ?What is it ?What does it require ?How does it relate to the Agile principles ?16 June 2011Agile Mëtteg – Continuous Integration13

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 2011Agile Mëtteg – Continuous Integration14

SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS16 June 2011Agile Mëtteg – Continuous Integration15

SOFTWARE DEVELOPMENT: A LOT OF FAILED PROJECTS16 June 2011Agile Mëtteg – Continuous Integration16

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

AGILE MANIFESTO vs SOFTWARE INDUSTRIALIZATION ?Agile ManifestoIndividuals and interactions overprocesses and toolsWorking softwareovercomprehensive documentationCustomer collaboration overcontract negotiationResponding to change overfollowing a plan16 June 2011Agile Mëtteg – Continuous Integration18

SOFTWARE CRAFTSMANSHIP vs SOFTWARE INDUSTRIALIZATION?Manifesto for Software CraftsmanshipNot onlyworking software, but alsowell-crafted softwareNot onlyresponding to change, but alsosteadily adding valueNot onlyindividuals and interactions, but alsoa community of professionalsNot onlycustomer collaboration, but alsoproductive partnerships16 June 2011Agile Mëtteg – Continuous Integration19

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

SOFTWARE DEVELOPMENT: AN ART?16 June 2011Agile Mëtteg – Continuous Integration21

SOFTWARE DEVELOPMENT: AN ART?16 June 2011Agile Mëtteg – Continuous Integration22

SOFTWARE DEVELOPMENT IS AN ARTSo, Software Development is an art!But building nearly anything is also an artDon’t you think?And, more importantly,Art is not without rules and best practices16 June 2011Agile Mëtteg – Continuous Integration23

RULES AND BEST PRACTICESWhat’s the worst?Not following therules usually leads to a rather direct and abrupt failureproject fails integration testing project is refused by infrastructureproject fails user acceptance testing…16 June 2011Agile Mëtteg – Continuous Integration24

RULES AND BEST PRACTICESWhat’s the worst?Not following the best practices augments, sometimes dramatically, the risks of failurereduces overall qualityincreases the time to market / time to deliverhas typically a pervasive effect: can be ignored or remains unknown until it becomes really criticalincreases the maintenance and ownership costs16 June 2011Agile Mëtteg – Continuous Integration25

RULES AND BEST PRACTICESWhat’s the worst?Both are terrible: sources of failureBut one is harder to detect than the otherNecessity to put in place and to define the structures and infrastructures required to check the quality at every levelBecause “the earlier, the best” (and less expensive)16 June 2011Agile Mëtteg – Continuous Integration26

SOFTWARE QUALITY16 June 2011Agile Mëtteg – Continuous Integration27

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 differentlythis 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 intrinsicqualitySteve McConnell defines external and internal quality characteristics (‘”Code Complete”)16 June 2011Agile Mëtteg – Continuous Integration28

IMPLICIT FACTORS FOR SOFTWARE QUALITYThe software projects typically follow rather detailed requirement plansThough a set of characteristics often goes unmentionedThese are the implied requirements that are expected of all professionally developed software16 June 2011Agile Mëtteg – Continuous Integration29

IMPLICIT FACTORS FOR SOFTWARE QUALITYConformance to implied requirements:UnderstandabilityCompletenessConcisenessPortabilityMaintainabilityTestabilityUsabilityReliabilityEfficiencySecurity16 June 2011Agile Mëtteg – Continuous Integration30

GUARANTEEING CODE QUALITYHow can we guarantee the level of quality of software during the « coding » phases?The same ways as in the industryFactory inspections: “static code analysis” in ITIncremental improvements: “release soon, release often” in ITTests, tests, tests, tests, tests, tests, …16 June 2011Agile Mëtteg – Continuous Integration31

GUARANTEEING CODE QUALITYFocus on Unit Tests and Test Driven Development (TDD)Unit TestsThe first tests to writeWritten by the developers before the codeWrite the code afterward to make the tests succeedMust run in isolation, without any infrastructureMust be fast to executeHow many unit tests per method ?One test per degree of “cyclomatic complexity”16 June 2011Agile Mëtteg – Continuous Integration32

GUARANTEEING CODE QUALITYCyclomatic complexity of a method?the number of linearly independent paths in the methodIf .. and .. thenIf .. or .. thenIf .. thenIf .. then .. elseDo .. WhileWhile .. DoSwitch16 June 2011Agile Mëtteg – Continuous Integration33

GUARANTEEING CODE QUALITYNecessity to put in place the supporting Structures (practices):Unit testingIntegration testingPerformance testingRegression testingAcceptance testingInfrastructures (tools):Source Code managementIssue trackingBuild toolsContinuous Integration serverQuality reporting toolsAgilityBuild IndustrializationBuild IndustrializationPlatformAgility16 June 2011Agile Mëtteg – Continuous Integration34

GUARANTEEING CODE QUALITYHow to put in place the supporting Structures (practices):Define and prioritize the quality requirementsRefine and adapt the relevant quality criteria to the objectivesCommunicate rules and best practices: sharing, training and mentoringVerify the correct usage and level of adoptionReview the results and improve the processesInfrastructures (tools):Select the tools adapted to the defined quality requirementsSet them up based on the selected criteria (define measurements)Communicate on their usage: sharing, training and mentoringGenerate quality reports and metricsAnalyze the conformance of the results and adapt the toolsAgilityAgility16 June 2011Agile Mëtteg – Continuous Integration35

Ci Rules and pre-requisites16 June 2011Agile Mëtteg – Continuous Integration36

CI RULES AND PRE-REQUISITES (1/3)maintain a code repositoryautomate the buildthe build must be self-testingregular code sharingi.e. frequent commits16 June 2011Agile Mëtteg – Continuous Integration37

CI RULES AND PRE-REQUISITES (2/3)self-contained modificationsi.e. commits don’t break the build processthe build must be fastintegration tests (for the least) in a clone of the production environment16 June 2011Agile Mëtteg – Continuous Integration38

CI RULES AND PRE-REQUISITES (3/3)latest deliverables easily available to anyone who needs themeasy access to the results of the testsautomated deployments to a live test servercontinous deployment to production is the ideal achievement16 June 2011Agile Mëtteg – Continuous Integration39

BUILD INDUSTRIALIZATION PLATFORM16 June 2011Agile Mëtteg – Continuous Integration40

BUILD INDUSTRIALIZATION PLATFORM16 June 2011Agile Mëtteg – Continuous Integration41

SOURCE CODE MANAGEMENT16 June 2011Agile Mëtteg – Continuous Integration42

SOURCE CODE MANAGEMENTWhat 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 mode16 June 2011Agile Mëtteg – Continuous Integration43

SCM RULES FOR CONTINUOUS INTEGRATIONTag your releases

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 2011Agile Mëtteg – Continuous Integration44

SCM RULES FOR CONTINUOUS INTEGRATIONCommit “atomically”

all the files related to a single task/issue in one operation or, if really not possible, max a few operationsdon’t mix changes from different tasks/issues in the same commit

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

the task/issue identifier (first line)

status (first line)« completed » or « in progress »short description from the issue tracking system (first line)

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

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

SCM RULES FOR CONTINUOUS INTEGRATIONThe idea isto be able to easily link back a modification (with all its related changes) to an issue from the issue tracker

to be able to take out easily a modification

that should not be included in a specific release

that blocks the other developers

that conflicts with other changes

keep your code agile ! 16 June 2011Agile Mëtteg – Continuous Integration46

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

Filter: show only files worked onfor the currently active task

Modified files grouped by tasks (“atomic” commits)

ISSUE TRACKER16 June 2011Agile Mëtteg – Continuous Integration55

AUTOMATED BUILD TOOLS16 June 2011Agile Mëtteg – Continuous Integration60

AUTOMATED BUILD TOOLS16 June 2011Agile Mëtteg – Continuous Integration61

AUTOMATED BUILD TOOLS : REPOSITORIES

CONTINUOUS INTEGRATION SERVER16 June 2011Agile Mëtteg – Continuous Integration64

QUALITY ANALYSIS AND REPORTING16 June 2011Agile Mëtteg – Continuous Integration67

Continuous Integration

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Continuous Integration (20)

Recently uploaded (20)

Continuous Integration

Editor's Notes