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
2. FOCUS
• WHY CONTINUOUS INTEGRATION
• HOW TO INTEGRATE CONTINUOUS INTEGRATION IN YOUR WORKFLOW
• GET TO KNOW JENKINS AND SONAR
• DEPLOYMENT PIPELINE - DEMO
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
”
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
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
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