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

1. CONTINUOUS INTEGRATION
TEST AND DEPLOYMENT AUTOMATION

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

3. WHY CONTINUOUS INTEGRATION

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. 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. 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. CAN WE DO BETTER?
SOFTWARE RELEASES CAN AND SHOULD BE:
• LOW-RISK
• FREQUENT
• CHEAP
• RAPID
• PREDICTABLE

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. 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. “
THE FIRST TIME YOU DO
AUTOMATION, IT WILL BE PAINFUL
— BUT IT WILL BECOME EASIER
AND THE BENEFITS WILL BE
INCALCULABLE
”

11. HOW TO INTEGRATE CI INTO YOUR
WORKFLOW

12. “
IN SOFTWARE, WHEN SOMETHING
IS PAINFUL, THE WAY TO REDUCE
THE PAIN IS TO DO IT MORE
FREQUENTLY, NOT LESS
”

13. PRINCIPLES OF SOFTWARE DELIVERY
SOFTWARE CAN BE BROKEN DOWN INTO 4 COMPONENTS:
• HOST ENVIRONMENT
• CONFIGURATION
• CODE
• DATA
KEEP EVERYTHING IN VERSION CONTROL!!!

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. 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. “
IT SHOULD ALWAYS BE CHEAPER
TO CREATE A NEW ENVIRONMENT
THAN TO REPAIR AN OLD ONE
”

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. “
TEST DRIVEN DEVELOPMENT IS
ESSENTIAL TO ENABLE THE
PRACTICE OF CONTINUOUS
DELIVERY
”

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. 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. 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. GET TO KNOW JENKINS AND SONAR

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. 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. JENKINS - CONFIGURE
JENKINS-PHP.ORG

26. JENKINS - JOBS

27. JENKINS - JOBS

28. JENKINS - BUILD & POST-BUILD

29. JENKINS - NODES

30. JENKINS - DASHBOARD

31. JENKINS - POST-BUILD

32. JENKINS - RESULTS

33. JENKINS - TEST COVERAGE

34. JENKINS - ACCEPTANCE TEST - BEHAT &
PHANTOMJS

35. JENKINS - PERFORMANCE TEST

36. JENKINS - CHUCK NORRIS

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. SONAR - CONFIGURE

39. SONAR - QUALITY PROFILE

40. SONAR - QUALITY PROFILE

41. SONAR - DASHBOARD

42. DEPLOYMENT PIPELINE
DEMO

43. REFERENCES
JENKINS-PHP.ORG