continuous integration using jenkins and sonar
DESCRIPTION
Continuous Integration can help your to team release features faster. It reduces the risk of deployment issue and will speed up your development cycle. In this presentation we take a look at how Jenkins and Sonar can help you Test, Analyze, Deploy and gather performance metrics that will help your team increase their development quality and reduce deployment timeTRANSCRIPT
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