Downloaded 13 times
Uploaded byPatrick Mizer
CI
Continuous Integration (CI) is a software development practice where developers regularly merge their work into a central repository. This allows for automated builds and tests which catch errors early. CI helps reduce integration problems, improves code quality, and allows for more frequent deployments. The document discusses implementing CI with tools like Jenkins, build scripts, unit testing, code analysis, and notifications to improve the development process.
CI
- 1. Continuous Integration Stop procrastinatingand build often!
- 2. Who am I? PatrickMizer Chief Architect at SpareFoot ZCE: PHP4, PHP5, and ZF patrick@sparefoot.com github.com/maximizer
- 3. We help consumerssearch, compare, and book self storage online. I’m not supposed to say this but… Think Hotels.com, but for self storage.
- 4. We have beenusing a Continuous Integration workflow since 2009
- 5. SpareFoot in 2009 ❏20 Visits per day ❏ 1 RackSpace cloud instance ❏ 2 Developers ❏ 1 Application ❏ 5-10 builds per day ❏ Deployed whenever -> % svn up
- 6. SpareFoot Today ❏ 2million visitors per month ❏ > 50 AWS EC2 instances ❏ 35 developers ❏ 7 product teams. ❏ 100-200 builds per day ❏ Continuous Delivery
- 7. What I willcover... ❏ What is CI? ❏ Why do it? ❏ The Jenkins CI Server ❏ What does a CI workflow look like? ❏ Build Tools ❏ Testing and Analysis ❏ Notification ❏ Lessons Learned
- 8. I want toclarify something..
- 9. Continuous something... Continuous Integration ContinuousDelivery Continuous Deployment
- 10.
- 11. Continuous something... Version Control Deploy to Staging Automated Tests AUTOAUTO Continuous Integration Continuous Delivery Continuous Deployment
- 12. Continuous something... Version Control Deploy to Staging Automated Tests Acceptance Tests Deployto Production AUTO AUTO AUTO MANUAL Version Control Deploy to Staging Automated Tests AUTO AUTO Continuous Integration Continuous Delivery Continuous Deployment
- 13. Continuous something... Version Control Deploy to Staging Automated Tests Acceptance Tests Deployto Production AUTO AUTO AUTO AUTO Version Control Deploy to Staging Automated Tests Acceptance Tests Deploy to Production AUTO AUTO AUTO MANUAL Version Control Deploy to Staging Automated Tests AUTO AUTO Continuous Integration Continuous Delivery Continuous Deployment
- 14. Continuous something... Version Control Deploy to Staging Automated Tests Acceptance Tests Deployto Production AUTO AUTO AUTO AUTO Version Control Deploy to Staging Automated Tests Acceptance Tests Deploy to Production AUTO AUTO AUTO MANUAL Version Control Deploy to Staging Automated Tests AUTO AUTO Continuous Integration Continuous Delivery Continuous Deployment
- 15. What is ContinuousIntegration? CI is a software development process in which developers integrate their work frequently. Each integration is built and verified by automated tests so that errors and inconsistencies are detected and fixed as quickly as possible.
- 16. What is ContinuousIntegration? CI originated with Extreme Programming CI is a process. It dictates no specific tooling.
- 17. So, why doit?
- 18. So, why doit?
- 19. Finding bugs lateis costly Local Development Staging Production Developers QA & Stakeholders Your Customers
- 20. Finding bugs lateis costly
- 21. Integration Hell “Your changesto the booking service are incompatible with mine. How do we merge now?” “When did we start using Guzzle 2.0? The SDK requires 3.0 and composer won’t let us use both!”
- 22. Integration Hell Mainline Developer C DeveloperA Developer B
- 23. Integration Hell Mainline Developer C DeveloperA Developer B
- 24. Integration Hell Mainline Developer C DeveloperA Developer B
- 25. Integration Hell Mainline Developer C DeveloperA Developer B
- 26. Integration Hell Mainline Developer C DeveloperA Developer B
- 27. Integration Hell Mainline Developer C DeveloperA Developer B
- 28. Poor Quality Codebase “Whothe #$@# is using tabs instead of spaces!?” “We have 2 classes doing the exact same thing”
- 29. Poor Project Visibility “Whatis our test coverage?” “How is our app performing?”
- 30. No Deployable Code “Itworks on my machine!” “I don’t know why it’s not working on staging, sounds like an ops problem.” “We need to push a fix for this immediately.”
- 31. CI attempts tomitigate these ❏ Finding bugs late is costly ❏ Integration hell ❏ Poor quality code base ❏ Poor project visibility ❏ No deployable code
- 32. Better code, fasterdevelopment Better code ❏ Code is tested early and often ❏ Standards enforced on every commit
- 33. Better code, fasterdevelopment Better code ❏ Code is tested early and often ❏ Standards enforced on every commit Faster development ❏ Integration issues are found earlier ❏ Testing becomes part of everyone’s process ❏ Building is a non-event
- 34. Continuous Integration Implementing aCI solution is pretty straightforward.
- 35. Continuous Integration ❏ Maintainan SCM code repository
- 36. Continuous Integration ❏ Maintainan SCM code repository ❏ Create and automate the build
- 37. Continuous Integration ❏ Maintainan SCM code repository ❏ Create and automate the build ❏ Everyone commits to mainline (at least daily)
- 38. Continuous Integration ❏ Maintainan SCM code repository ❏ Create and automate the build ❏ Everyone commits to mainline (at least daily) ❏ Every commit to mainline is built
- 39. Continuous Integration ❏ Maintainan SCM code repository ❏ Create and automate the build ❏ Everyone commits to mainline (at least daily) ❏ Every commit to mainline is built ❏ Tests verified on a prod-like environment
- 40. Continuous Integration ❏ Maintainan SCM code repository ❏ Create and automate the build ❏ Everyone commits to mainline (at least daily) ❏ Every commit to mainline is built ❏ Tests verified on a prod-like environment ❏ Notify everyone of the results
- 41. Excuses “We're not bigenough” “Too much work” “We don't have devops” “We don't have tests”
- 42. The CI Server ❏Polls for changes ❏ Manages and monitors builds ❏ Notifies team of results
- 43. Jenkins ❏ Free OpenSource (MIT License) ❏ Built on Java ❏ Fork of Hudson ❏ Plugins for everything ❏ Lots of resources Easy to get going: % sudo apt-get install jenkins % sudo apt-get install jenkins-cli
- 44. Jenkins-php.org Jenkins template forPHP projects put together by Sebastian (yes, that Sebastian) Bergmann Step-by-step Instructions: ❏ Template w/ plugins ❏ Build file ❏ Log formats ❏ Jenkins config
- 45. The CI workflow ❏Developer commits code ❏ CI Server polls SCM for changes ❏ CI Server integrates and builds code to the Integration Environment ❏ CI notifies team of result
- 46.
- 47.
- 48.
- 49.
- 50.
- 51. The Build ❏ Builddependencies ❏ Tests ❏ Static analysis ❏ Artifacts (docs, phar, etc) ❏ ...
- 52.
- 53. Build tools... “But buildfiles are only for compiling.”
- 54. Build tools... Use aproper built tool ❏ Apache Ant (Java) ❏ Phing (PHP)
- 55. Apache Ant ❏ build.xml ❏Targets and depends ❏ Java = threads ++
- 56. Anatomy of build.xml <?xmlversion="1.0" encoding="UTF-8"?> <project name="some-php-project" default="build"> <target name="build" depends="phpunit"/> <target name="phpunit" description="Run unit tests"> <exec executable="phpunit" failonerror="true"/> </target> </project>
- 57. SCM polling andbuild
- 58. The Integration Machine ❏A reasonable facsimile of production ❏ Every commit is built here ❏ By yourself? Use Vagrant
- 59. Verifying the Build UnitTests Functional Tests
- 60. Selenium “But setting upselenium is hard...”
- 61.
- 62.
- 63. Testing is justthe beginning
- 64. Static Analysis Analysis ofsoftware without actually executing the code.
- 65. Check your PHPsyntax PHP Lint php -l foo.php find . -name “*.php” -exec php -l {};
- 66.
- 67. Coding Standards PHP CodeSniffer phpcs --standard=pear foo.php
- 68.
- 69. DRY Copy page detector phpcpd-min-lines=5 /src/service/*
- 70.
- 71.
- 72. Performance - Bonus Phantomjsis a headless browser based on Webkit with JS API YSlow is a tool that analyzes web pages and why they’re slow based on Yahoo’s rules. Phantomjs + YSlow = Awesomeness
- 73. Performance - Bonus phantomjsyslow.js -i grade -threshold "A" -f junit http://staging.sparefoot.com > results.xml
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80. Lessons Learned Version allof you CI Config. We didn’t and now we’re going back and rewriting it.
- 81. Lessons Learned Building theDB ❏ Put your schema changes under version control. ❏ Incorporate them into the build ❏ Fail when there’s a problem. Make this the only way to get schema changes to production.
- 82. Git feature branching Gitfeature branching solves a separate problem.
- 83. Git feature branching Master BranchC Branch A Branch B
- 84. Our Git Workflow commitcommit PUSH Branch Merge Pull request commit PUSHcommit commit commit Merge Pull request MASTER BRANCH B BRANCH A Branch + master built to dev environment and tested. Branch + master built to dev environment and tested. Master built to staging environment and tested.
- 85. Play with Jenkinstoday! github.com/ maximizer/vagrant-ci % git clone github.com/maximizer/vagrant-ci.git % vagrant up http://localhost:8282 http://jenkins-php.org
- 86.