continuous integration using jenkins and sonar

CONTINUOUS INTEGRATION

TEST AND DEPLOYMENT AUTOMATION

• WHY CONTINUOUS INTEGRATION• HOW TO INTEGRATE CONTINUOUS INTEGRATION IN YOUR WORKFLOW• GET TO KNOW JENKINS AND SONAR• DEPLOYMENT PIPELINE - DEMO

FOCUS

WHY CONTINUOUS INTEGRATION

IF SOMEBODY THINKS OF A GOOD IDEA,HOW DO WE DELIVER IT TO USERS AS QUICKLY AS POSSIBLE

WITHOUT BREAKING EVERYTHING?

THE PROBLEM OF DELIVERING SOFTWARE

• FOR LONG PERIODS OF TIME DURING DEVELOPMENT, THE APPLICATION IS NOT IN A WORKING STATE

• NOBODY IS INTERESTED IN RUNNING THE WHOLE APPLICATION UNTIL IT’S FINISHED

• NOBODY TRIES TO RUN THE APPLICATION IN A PRODUCTION-LIKE ENVIRONMENT

• DOUBLY TRUE OF LONG LIVED BRANCHES OR UAT TESTING THAT’S DEFERRED TO THE END

BEHAVIOUR OF SOFTWARE PROJECT

RELEASE ANTI-PATTERNS - MANUAL DEPLOYSIGNS:• DETAILED DEPLOYMENT

PROCEDURE• MANUAL REGRESSION TESTING• RELEASE THAT TAKE MORE THAN A

FEW MINUTES• UNPREDICTABLE RELEASE - HAS TO

BE ROLLED BACK• DEPLOYMENT WINDOWS!!!

EFFECTS:• ERRORS WILL OCCUR EVERY TIME

THEY ARE PERFORMED. THE ONLY QUESTION IS WHETHER OR NOT THE ERRORS ARE SIGNIFICANT

• NOT REPEATABLE OR RELIABLE• MANUAL DEPLOYMENTS DEPENDS

ON DEPLOYMENT EXPERTS• BORING AND REPETITIVE• EXPENSIVE MANUAL TESTING• NOT AUDITABLE

SOFTWARE RELEASES CAN AND SHOULD BE:

• LOW-RISK

• FREQUENT

• CHEAP

• RAPID

• PREDICTABLE

CAN WE DO BETTER?

• AUTOMATED - IF THE BUILD, DEPLOY, TEST AND RELEASE IS NOT AUTOMATED, IT IS NOT REPEATABLE. IT WILL BE DIFFERENT EVERY TIME. RELEASING SHOULD BE AN ENGINEERING DISCIPLINE

• FREQUENT - IF THE RELEASE IS FREQUENT, THE DELTA BETWEEN RELEASE WILL BE SMALL.

• EASIER TO ROLL BACK

• FASTER FEEDBACK

HOW?

• REPEATABLE, RELIABLE, PREDICTABLE RELEASE PROCESS

• ERROR REDUCTION - NO HUMAN BEING OR TEAM OF HUMAN BEING CAN SPOT A BREAKING CHANGE IN MILLIONS OF LINES OF CODE - LET THE COMPUTER DO THAT

• LOWERING STRESS - PEACE OF MIND THAT THE FEATURES WORK

• FLEXIBLE DEPLOYMENT SCHEDULES - DEPLOY AT THE PUSH OF A BUTTON —YES EVEN ON FRIDAY @ 1:30PM

BENEFITS

“”

THE FIRST TIME YOU DO AUTOMATION, IT WILL BE PAINFUL — BUT IT WILL BECOME EASIER

AND THE BENEFITS WILL BE INCALCULABLE

HOW TO INTEGRATE CI INTO YOUR WORKFLOW

“”

IN SOFTWARE, WHEN SOMETHING IS PAINFUL, THE WAY TO REDUCE

THE PAIN IS TO DO IT MORE FREQUENTLY, NOT LESS

SOFTWARE CAN BE BROKEN DOWN INTO 4 COMPONENTS:

• HOST ENVIRONMENT

• CONFIGURATION

• CODE

• DATA

KEEP EVERYTHING IN VERSION CONTROL!!!

PRINCIPLES OF SOFTWARE DELIVERY

• CAN I REPRODUCE ANY OF MY ENVIRONMENTS (OS, SOFTWARE INSTALLED, CONFIGURATION)

• CAN I MAKE AN INCREMENTAL CHANGE TO THESE ENVIRONMENTS

• CAN I TRACE BACK THIS CHANGE, WHO MADE IT AND WHEN THEY MADE IT

• IS IT EASY FOR EVERY MEMBER TO APPLY THESE CHANGES

HOST ENVIRONMENT

TREAT YOUR CONFIGURATION LIKE CODE• BASED ON APPLICATION AND ENVIRONMENT, IT SHOULD BE EASY TO

SEE WHAT THE OPTIONS ARE• USE CLEAR NAMING CONVENTIONS• MODULAR AND ENCAPSULATED• DRY / KISS• TESTED

CONFIGURATION

“”

IT SHOULD ALWAYS BE CHEAPER TO CREATE A NEW ENVIRONMENT

THAN TO REPAIR AN OLD ONE

• MUST BE IN VERSION CONTROL

• MUST HAVE A TESTING STRATEGY ( > 70% COVERAGE)

• USE MEANINGFUL COMMIT MESSAGES

• BRANCH BY ABSTRACTION

• USE DEPENDENCY INJECTION

• TDD

CODE

“”

TEST DRIVEN DEVELOPMENT IS ESSENTIAL TO ENABLE THE PRACTICE OF CONTINUOUS

DELIVERY

• VERSION YOUR DATABASE CREATION AND MIGRATIONS (DBDEPLOY, PHINX)

• STRIVE TO RETAIN FORWARD AND BACKWARD COMPATIBILITY

• TEST DATA IS CREATED AND MAINTAINED IN A DIFFERENT PARTITION

DATA

• DON’T CHECK-IN BROKEN CODE

• RUN TEST LOCALLY BEFORE COMMITTING

• WAIT FOR TEST TO PASS BEFORE MOVING ON

• FIX BROKEN BUILDS IMMEDIATELY

• ALWAYS BE PREPARED TO REVERT TO PREVIOUS VERSION

• DON’T COMMENT OUT FAILING TESTS

ESSENTIAL PRACTICES

• FAILING A BUILD FOR ARCHITECTURAL BREACH

• FAILING A BUILD FOR SLOW TESTS

• FAILING A BUILD FOR WARNING OR CODE STYLE BREACH

• FAILING A BUILD FOR PERFORMANCE

PRACTICES TO CONSIDER

GET TO KNOW JENKINS AND SONAR

• JENKINS IS AN OPEN SOURCE CONTINUOUS INTEGRATION SERVER WRITTEN IN JAVA

• JENKINS WAS ORIGINALLY DEVELOPED AS THE HUDSON PROJECT• JENKINS IS A FORK OF HUDSON WHEN ORACLE TRADEMARKED THE

PROJECT

JENKINS

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -!

sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'!

sudo apt-get update!

sudo apt-get install jenkins

JENKINS - INSTALLATION

JENKINS - CONFIGURE

JENKINS-PHP.ORG

JENKINS - JOBS

JENKINS - JOBS

JENKINS - BUILD & POST-BUILD

JENKINS - NODES

JENKINS - DASHBOARD

JENKINS - POST-BUILD

JENKINS - RESULTS

JENKINS - TEST COVERAGE

JENKINS - ACCEPTANCE TEST - BEHAT & PHANTOMJS

JENKINS - PERFORMANCE TEST

JENKINS - CHUCK NORRIS

sudo sh -c 'echo deb http://downloads.sourceforge.net/project/sonar-pkg/deb binary/ > /etc/apt/sources.list'!

sudo apt-get update!

sudo apt-get install sonar

SONAR - INSTALLATION

SONAR - CONFIGURE

SONAR - QUALITY PROFILE

SONAR - QUALITY PROFILE

SONAR - DASHBOARD

DEPLOYMENT PIPELINE

DEMO

REFERENCES

JENKINS-PHP.ORG