Continuous integrations - Basics
1 like518 views
The document discusses continuous integration, which is a software engineering practice where a project is built and tested frequently, such as each time a change is committed to the main code repository. It recommends using a revision control system, a dedicated build server, and getting an open-minded team. Key aspects of continuous integration include automated building, testing, code quality analysis, and having the project always be in a deployable state. Tools mentioned that can help with continuous integration include Jenkins for building and testing, Gerrit for code reviews, and SonarQube for code quality analysis.
Continuous integrations - Basics
- 1. Continuous Integration Barış İNANÇ ARDIC AR-GE Release Engineer
- 2. Who am I? • Release Engineer in ARDIC INC. • Maintaining build operations for 3 years • Trying to automate everything 2
- 3. Agenda • Catastrophic Failure Step by Step • Continuous Integration • Why it is important? • What is needed? • Build ▫ What ▫ When ▫ How • My Toolbox and Workflow • 7 Step for Success 3
- 4. Catastrophic Failure Step by Step • Crowded Team • Multi module project • No revision management system / wrong usage of revision management system • Manual testing • Compile only on finish • Binary deployment from developer computer • … 4
- 5. Continuous Integration • Software engineering practice, where project is builded frequently • Emerged as Extreme Programming technique • 2000, Continuous Integration, Martin Fowler • Became Agile Process standard 5
- 6. Why it is important? (1) • Fixing bugs late can be costly 6
- 7. Why it is important? (2) • To Improve Team Collaboration ▫ “Changes are conflicting how to merge now?” ▫ “When did this code changed/removed/added” ▫ “It was working two days ago” 7
- 8. Why it is important? (3) • To Improve Code Quality (Before production/catastrophic failure) ▫ “Same code over and over why not make a function” ▫ Why did you write this code: … if(foo==true) return true else return false … return foo 8
- 9. Why it is important? (4) • To know Project history/future ▫ What was in version 1.2.129? ▫ Which tests are failing? 9
- 10. Why it is important? (5) • Always ready for deployment ▫ “It works on my computer” ▫ “Customer is coming, ready for a demo?” 10
- 11. Fix before not try during flight 11
- 12. What is needed? • Revision Management System (GIT/SVN) • Dedicated Build Server • Open-minded team 12
- 13. Term: Build • Learn real meaning of Build Build != Compile 13
- 14. Build • Compilation sucessfully • Test Execution • Database Integration • Code Inspection • Automated Deployment • Document Generation repeatable Upgrade/downgrade scripts Health check Always ready Up-to-date 14
- 15. Build When? • Full project build regularly (nightly) • Build module in every commit • Full Build if a module changes dependencies 15
- 16. Build How? • Generate building scripts • Unattended building • Do not use IDE for building • Use CI server not developer computer • Generate build report for immediate feedback • Accessible for team 16
- 17. Jenkins CI • Easy to use Continuous Integration tool • Building/Testing/Monitoring can be done from same application • Ready for scaling and parallel building • Can integrate with SCM and Code Quality tools easily 17
- 18. 18
- 19. Gerrit Code Review • Code Review system for GIT SCM • Each patchset can be reviewed before merging to release branch • Fix before build 19
- 20. 20
- 21. SonarQube • Code Quality tool • Automated code quality analysis • Over 20 programming languages • Coding rules, potential bugs, duplications can be anlyzed via this tool 21
- 22. 22
- 23. Let’s integrate Everything 23 Submit changes Submit changes it is applicable Get changes and build Analyze changes GIT Repo Report Output
- 24. Let’s integrate Everything • Never commit a code to master repository directly • Send patchset to review regularly • Patchset will be automatically builded and sent to analysis to SonarQube • SonarQube runs analysis and generated report • Build and Analysis reports will be linked to patchset in Gerrit Code Review system • Merge code to release branch after manual review 24
- 25. Let’s integrate Everything • Jenkins CI can build project regularly • After compilation completed tests can be run via Jenkins • Daily sonar analysis can be started during this build • All reports will be ready for the morning 25
- 27. Conclusion • For ▫ Better quality Code ▫ Fast Development Time ▫ Less cost on money or time • Use Continuous Integration techniques 27
- 28. Thank you for listening Any Questions… 28
- 29. References • http://www.slideshare.net/drluckyspin/continuous-integration • https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins • http://www.sonarqube.org/ • https://code.google.com/p/gerrit/ • http://martinfowler.com/articles/continuousIntegration.html 29