Sigis jermolovicius chasing code quality in huge multi location team project

CHASING CODE QUALITY IN HUGE MULTI-
LOCATION TEAM PROJECT

October 15, 2012 www.ExigenServices.com

GLOBAL EXIGEN SERVICES

Riga St. Petersburg Nizhniy Novgorod Kazan
R&D Center R&D Center R&D Center R&D Center

San Francisco New York
Headquarters
Europe
Eastern Europe
Wuxi
US London Asia-Pacific R&D Center
Minsk Suzhou
R&D Center R&D Center
Frankfurt
Odessa
R&D Center Dnepropetrovsk
• Founded in 2000 R&D Center Adelaide
• 1’500 professionals
Vilnius Johannesburg
• Revenue approx. $70M San Paulo R&D Center

Christchurch

2 www.ExigenServices.com

EXIGEN SUITE COMPONENTS

Sales and Customer Service DISTRIBUTIONCORE Distribution Management

Business Invoice & Payment New
New Policy
Policy Product FNOL Adjudicaton
Business Servicing
Processes Collection Processes Business Servicing Management & Settlement
&
Core BILLINGCORE POLICYCORE CLAIMCORE
Functions
Bill Plan Payment PRODUCT Under- Claim
Claim Claims
Claim
FACTORY
Management Management Rating Writing Processing Financials
Processing Financials

Common Accounts Reporting & Tasks & 3rd Party Correspondence
Sub-Ledger
Services & CRM Compliance Decisions Mgmt Management

Data & Sys Billing Claims Commission Self-Service Reinsurance Analytics 3rd Party
Integration Interface Interface Interface Portal Interface Interface Interface Interface

Operations Configuration Document Content Business Process & Business
Security Activity
Management & Scheduling Generation Management Rules Task Mgmt Monitoring


WHEN YOU START FAILING

Agile works says:
 One location, team, scrum master and product owner
 Everybody are universal and senior;

But in sometimes we have
 Multi location, teams, scrum masters and PO’s
 And mixed level;

And here problems arise.


THIS PRESENTATION TOPIC

Stable Continuous Integration

Effective Code review

Useful Static code quality


TECHNOLOGIES WE SELECTED

 Source control (DSVC) - hg (Mercurial) mercurial.selenic.com

 Build tool - Jenkins jenkins-ci.org

 Review tool - Reviewboard reviewboard.org

 Static code quality - Sonar sonarsource.org


STABLE CONTINUOUS INTEGRATION


CI FOR ONE TEAM


CI WITH MULTIPLE TEAMS


WHAT TO DO?

Options

 Fight with continuous integration failures every day

 Fail fast. Setup your continuous integration to no accept failing
code.


FAILING FAST

 “Failing fast” for development means getting response about your
code quickly, from:
 compiler
 deployment
 unit and integration test
 UI tests
 static quality parameters

And all those answers should be given before code gets to source
control.


MULTIPLE TEAMS – MULTIPLE
CONTINUOUS ENVIRONMENTS


TEAM BRANCH


BENEFITS

 Team continuous integration environment is effected only by team
changes.

 Only finished and tested features will get to central. Gatekeeper
would be responsible to merge.


STILL TO BE IMPROVED

 There is still possibility that gatekeeper will push bad code

 We don’t reach our ultimate goal - STABILITY of central.


ONE STEP FURTHER - TEAM-MERGE

 To achieve our goal we created CI job that doesn't allow bad code.
It does automatic code merge, compile, test and push.
– rights write to central are revoked for anyone and only "special"
"team-merge" user can do merge.
– only possible way to commit code from team-branch to central
is through "team-merge" script.


HOW IT WORKS


HOW TO START IT


FINAL TIPS

 Your environment should be stable enough to do this approach.

 Better have small number of working test rather than huge number
of failing test.

 Each team has own CI plans – hardware is required


EFFECTIVE CODE REVIEW


CODE REVIEW OR NOT CODE REVIEW

 Code review, if:
– You plan long life cycle for your product
– Your customer insist on high quality and you have maintenance
contract.

Don’t code review, if:
– Your product has short life cycle (demos, POC, etc.)
– You don’t care about maintenance after it’s done 


CODE REVIEW

 There are various proposals on code review –
 Pair Programming

 Review about do less than 100%, with rules, like
Review only Selected commits.
Review only commits from juniors
Random reviews

 Review 100% of code

We chose 100% review.


CODE REVIEW AFTER COMMIT

 Guarantee that reviewed code is committed

 No special actions required if reviewed code passes

Issues:
 In case code doesn’t pass you have bad code in repository until it’s
fixed.
 Bad code effects others


CODE REVIEW BEFORE COMMIT

 Review patches or review branch.

 Bad code doesn’t effect others.

Issues:
 You have no guarantee that good code reviewed will get to
repository. As somebody needs to merge it.

What we needed is:
Automated merge on code review pass.


100% CODE REVIEW

What we want is

1. Work as a team.
2. Review all code changes
3. Do not effect others

Therefore we need code review systems what would assure 100%
review.

Other requirements:
 DVCS-backed review system
 Acts as a front end for to central DVCS-repo
 When review is complete auto merge with default branch

CODE REVIEW TOOLS

 For git users there is good tool called gerrit
http://code.google.com/p/gerrit/

 If you use mercurial (hg), it’s bit more complicated – as where is
no analogue for gerrit for hg.

 Our approach was to use reviewboard.org and mercurial enhanced
with python scripts what are mimicking gerrit approach.

 To initiate review you should call “hg postreview”


REVIEWBOARD


REVIEW CYCLE


USEFUL STATIC CODE CONTROL


CONTROL CODE QUALITY

 We want to control basic parameters of code quality
 Static code violation
 Code unit and integration test coverage
 Other code parameters

We can do it effectively with tool called Sonar


METRICS

 What you want to measure?
– Test Coverage?
– Static code violations?
– Code metrics?

Answer to this is SONAR
Automates metrics and creates reports.
Allows to analyze code to the code line details.

sonarsource.org


SONAR PROJECT VIEW


CODE COVERAGE


CODE DRILLDOWN


CODE VIOLATIONS


VIOLATION DRILLDOWN


WHAT’S NEXT WITH SONAR

 Good is that we have tool to control

 Bad is that what people are still people and tend to do crappy
code.

 number of violations is increasing.
 still repeating same errors.
 code is unmaintainable


OUR APPROACH

 Decide that violations are critical for you and what you can live
with.

 What we do:
 Using multistage commit we don’t accept code with blocker
violations.
 Commit is declined and developer should rework their code
before next commit.
 Use personal violations view to work with particular developers
coding style.


PERSONAL VIOLATIONS DRILLDOWN


PREVENT VIOLATIONS


TIPS

 Declare violations as critical first.

 Allow teams to fix them.

 Increase severity to blocker after all existing are fixed

 Decline new violations of same type


QUESTIONS?


Sigis jermolovicius chasing code quality in huge multi location team project

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Sigis jermolovicius chasing code quality in huge multi location team project

Similaire à Sigis jermolovicius chasing code quality in huge multi location team project (20)

Plus de Agile Lietuva

Plus de Agile Lietuva (20)

Sigis jermolovicius chasing code quality in huge multi location team project

Notes de l'éditeur