Continuous integration using Jenkins and Sonar

6,627 views
6,210 views

Published on

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 time

Published in: Technology

Continuous integration using Jenkins and Sonar

  1. 1. CONTINUOUS INTEGRATION TEST AND DEPLOYMENT AUTOMATION
  2. 2. FOCUS • WHY CONTINUOUS INTEGRATION • HOW TO INTEGRATE CONTINUOUS INTEGRATION IN YOUR WORKFLOW • GET TO KNOW JENKINS AND SONAR • DEPLOYMENT PIPELINE - DEMO
  3. 3. WHY CONTINUOUS INTEGRATION
  4. 4. THE PROBLEM OF DELIVERING SOFTWARE IF SOMEBODY THINKS OF A GOOD IDEA, HOW DO WE DELIVER IT TO USERS AS QUICKLY AS POSSIBLE WITHOUT BREAKING EVERYTHING?
  5. 5. BEHAVIOUR OF SOFTWARE PROJECT • 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
  6. 6. RELEASE ANTI-PATTERNS - MANUAL DEPLOY SIGNS: EFFECTS: • DETAILED DEPLOYMENT PROCEDURE • ERRORS WILL OCCUR EVERY TIME THEY ARE PERFORMED. THE ONLY QUESTION IS WHETHER OR NOT THE ERRORS ARE SIGNIFICANT • MANUAL REGRESSION TESTING • RELEASE THAT TAKE MORE THAN A FEW MINUTES • UNPREDICTABLE RELEASE - HAS TO BE ROLLED BACK • DEPLOYMENT WINDOWS ! ! ! • NOT REPEATABLE OR RELIABLE • MANUAL DEPLOYMENTS DEPENDS ON DEPLOYMENT EXPERTS • BORING AND REPETITIVE • EXPENSIVE MANUAL TESTING • NOT AUDITABLE
  7. 7. CAN WE DO BETTER? SOFTWARE RELEASES CAN AND SHOULD BE: • LOW-RISK • FREQUENT • CHEAP • RAPID • PREDICTABLE
  8. 8. HOW? • 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
  9. 9. BENEFITS • 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
  10. 10. “ THE FIRST TIME YOU DO AUTOMATION, IT WILL BE PAINFUL — BUT IT WILL BECOME EASIER AND THE BENEFITS WILL BE INCALCULABLE ”
  11. 11. HOW TO INTEGRATE CI INTO YOUR WORKFLOW
  12. 12. “ IN SOFTWARE, WHEN SOMETHING IS PAINFUL, THE WAY TO REDUCE THE PAIN IS TO DO IT MORE FREQUENTLY, NOT LESS ”
  13. 13. PRINCIPLES OF SOFTWARE DELIVERY SOFTWARE CAN BE BROKEN DOWN INTO 4 COMPONENTS: • HOST ENVIRONMENT • CONFIGURATION • CODE • DATA KEEP EVERYTHING IN VERSION CONTROL!!!
  14. 14. HOST ENVIRONMENT • 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
  15. 15. CONFIGURATION 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
  16. 16. “ IT SHOULD ALWAYS BE CHEAPER TO CREATE A NEW ENVIRONMENT THAN TO REPAIR AN OLD ONE ”
  17. 17. CODE • MUST BE IN VERSION CONTROL • MUST HAVE A TESTING STRATEGY ( > 70% COVERAGE) • USE MEANINGFUL COMMIT MESSAGES • BRANCH BY ABSTRACTION • USE DEPENDENCY INJECTION • TDD
  18. 18. “ TEST DRIVEN DEVELOPMENT IS ESSENTIAL TO ENABLE THE PRACTICE OF CONTINUOUS DELIVERY ”
  19. 19. DATA • 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
  20. 20. ESSENTIAL PRACTICES • 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
  21. 21. PRACTICES TO CONSIDER • 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
  22. 22. GET TO KNOW JENKINS AND SONAR
  23. 23. JENKINS • 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
  24. 24. JENKINS - INSTALLATION 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
  25. 25. JENKINS - CONFIGURE JENKINS-PHP.ORG
  26. 26. JENKINS - JOBS
  27. 27. JENKINS - JOBS
  28. 28. JENKINS - BUILD & POST-BUILD
  29. 29. JENKINS - NODES
  30. 30. JENKINS - DASHBOARD
  31. 31. JENKINS - POST-BUILD
  32. 32. JENKINS - RESULTS
  33. 33. JENKINS - TEST COVERAGE
  34. 34. JENKINS - ACCEPTANCE TEST - BEHAT & PHANTOMJS
  35. 35. JENKINS - PERFORMANCE TEST
  36. 36. JENKINS - CHUCK NORRIS
  37. 37. SONAR - INSTALLATION 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
  38. 38. SONAR - CONFIGURE
  39. 39. SONAR - QUALITY PROFILE
  40. 40. SONAR - QUALITY PROFILE
  41. 41. SONAR - DASHBOARD
  42. 42. DEPLOYMENT PIPELINE DEMO
  43. 43. REFERENCES JENKINS-PHP.ORG

×