Continuous Integration, the minimum viable product
•Download as KEY, PDF•
8 likes•4,350 views
What does it mean to 'do' Continuous Integration? It used to be enough to execute your unit tests in CI. But the bar is steadily raising for engineering practices. In the last decade we've seen tremendous improvements inacceptance testing. JavaScript is now a platform in it's own right. Cloudcomputing is now vital. There's growing interest in deployment to prod.So Continuous Integration is under more pressure than ever. As the bar slowly raises for engineering practices, we ll present 2011's minimum viable feature set for Continuous Integration
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Continuous Integration, the minimum viable product
Similar to Continuous Integration, the minimum viable product (20)
More from Julian Simpson
Recently uploaded
Recently uploaded (20)
Continuous Integration, the minimum viable product
- 1. Continuous Integration The Minimum Viable Product Julian Simpson - @builddoctor Chris Read - @cread
- 7. http://www.flickr.com/photos/mainmanwalkin/3074193461/ mainline release branches
- 10. CI Principles • Build and test everything, when it changes
- 11. CI Principles • Build and test everything, when it changes • The database schema counts as everything
- 12. CI Principles • Build and test everything, when it changes • The database schema counts as everything • Tests count as everything
- 13. CI Principles • Build and test everything, when it changes • The database schema counts as everything • Tests count as everything • And JavaScript
- 14. CI Principles • Build and test everything, when it changes • The database schema counts as everything • Tests count as everything • And JavaScript • Check in often and early
- 15. CI Principles • Build and test everything, when it changes • The database schema counts as everything • Tests count as everything • And JavaScript • Check in often and early • Builds are feedback
- 16. Simple CI Demo
- 18. Databases
- 19. Databases • Use database migrations
- 20. Databases • Use database migrations • Don’t write your own tool
- 21. Databases • Use database migrations • Don’t write your own tool • Don’t mix DDL and DML
- 22. Databases • Use database migrations • Don’t write your own tool • Don’t mix DDL and DML • Data can cause migrations to fail in prod
- 23. 1 class CreateTheGems < ActiveRecord::Migration 2 def self.up 3 create_table :the_gems do |t| 4 t.string :name 5 t.timestamps 6 end 7 end 8 9 def self.down 10 drop_table :the_gems 11 end 12 end
- 24. 1 class AddGemStatus < ActiveRecord::Migration 2 def self.up 3 add_column :the_gems, :status, :string, :default => "pending" ## at least there are 3 values. pending, declined & approved 4 end 5 6 def self.down 7 remove_column :the_gems, :status 8 end 9 end
- 25. Notifications
- 26. Notifications • Email is evil
- 27. Notifications • Email is evil • IDE or tray tools are OK
- 28. Notifications • Email is evil • IDE or tray tools are OK • Big Visible tools are awesome
- 29. XFD Demo
- 30. Scaling
- 31. Scaling • Solid State Disks are your friend
- 32. Scaling • Solid State Disks are your friend • Scaling tests is a different concern: http:// test-load-balancer.github.com/
- 33. Scaling • Solid State Disks are your friend • Scaling tests is a different concern: http:// test-load-balancer.github.com/ • Don’t fake infrastructure to make it fast
- 34. Testing the Web
- 35. Testing the Web • You can make your application easier to test
- 36. Testing the Web • You can make your application easier to test • Don’t forget to test everything
- 37. Testing the Web • You can make your application easier to test • Don’t forget to test everything • Be damn careful when you parallelize tests
- 38. If you can’t test them, validate them
- 39. Though testing is better
- 41. Sauce Labs Demo
- 44. DevOps • most misunderstood meme of recent times http://www.flickr.com/photos/shaggypaul/193098324/
- 45. DevOps • most misunderstood meme of recent times • agile approach to systems admin http://www.flickr.com/photos/shaggypaul/193098324/
- 46. DevOps • most misunderstood meme of recent times • agile approach to systems admin • developer-sysadmin collaboration http://www.flickr.com/photos/shaggypaul/193098324/
- 47. DevOps • most misunderstood meme of recent times • agile approach to systems admin • developer-sysadmin collaboration • provides feedback to the business http://www.flickr.com/photos/shaggypaul/193098324/
- 48. Production
- 49. Production • Deployment scripts should be rehearsed in CI
- 50. Production • Deployment scripts should be rehearsed in CI • CI servers should be built the same way as prod
- 51. Production • Deployment scripts should be rehearsed in CI • CI servers should be built the same way as prod • Tools like Puppet and Chef help you do that
- 52. Puppet Demo
- 53. New server: 45 seconds knox:infrastructure jsimpson$ rake puppet:remote bundle exec lib/instance.rb Node ready at 44.457065 bootstrapping at 44.457127 setting the ssh hostkey at 44.457141 copying the code over at 44.828861 about to make code dir at 44.828986 About to rsync at 45.731777
- 54. Slowest part? My ISP Rsync done at 327.996322 bootstrapping rubygems at 327.997617 updating system config Extracting templates from packages: 100% Successfully installed bundler-1.0.15 1 gem installed Building native extensions. This could take a while... Successfully installed json-1.5.3 1 gem installed bootstrapped rubygems at 366.733525 bootstrapping at 366.733569 bootstrapped at 366.733608 bootstrapped at 373.198161
- 58. http://www.flickr.com/photos/rsgranne/179321532/ Continuous Delivery ... satisfy the customer through early and continuous delivery of valuable software ... (ask Jez)
- 59. Further reading
- 60. Thank you Any Questions? @builddoctor julian@build-doctor.com
Editor's Notes
- Explain that chris is not an imaginary friend\nDo the experience check\nExplain the vagueness in pitching\nask them to ask questions\nexplai\n \n\n\n
- Explain Chris\nDo the experience check\nAsk for questions\nTake a deep fucking breath\n\n
- This is the existing metaphor for CI\n&#x201C;Toyoda&#x2019;s automatic loom stopped whenever the thread of the warp was snapped, .. the loom could not produce defectives, because it had an automatic stopping device&#x201D;\nBut CI is not about machines, it&#x2019;s about peopl;e\n
- \n
- This is CM done wrong\n
- Which leads to this\n
- it should be this\n
- The 1840&#x2019;s called, they want your CI status back\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- 1. CI Principles\nBuild everything, whenever it changes\nSingle Source of Truth\nthe database schema counts as everything\nthe tests count as everything\nCheck in frequently\nWe all build together (ie Branching is Bad!)\nFEEDBACK!\n\n
- \n
- \n
- AR migrations, dbdeploy, dbdeploy.net, tarantino, dbmigrate, et al\nDML and DDL must never meet\nReference data may depend on a schema\ntest it realistically - test against a real dataset if you can\n\n \n\n
- AR migrations, dbdeploy, dbdeploy.net, tarantino, dbmigrate, et al\nDML and DDL must never meet\nReference data may depend on a schema\ntest it realistically - test against a real dataset if you can\n\n \n\n
- AR migrations, dbdeploy, dbdeploy.net, tarantino, dbmigrate, et al\nDML and DDL must never meet\nReference data may depend on a schema\ntest it realistically - test against a real dataset if you can\n\n \n\n
- AR migrations, dbdeploy, dbdeploy.net, tarantino, dbmigrate, et al\nDML and DDL must never meet\nReference data may depend on a schema\ntest it realistically - test against a real dataset if you can\n\n \n\n
- \n
- \n
- Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- \n
- \n\nNext is scaling your tests (Jules can allude to his current client on this one...)\n\nScaling your CI infrastructure:\n\nAOL incident \n\nAfter that you need to make sure your software can scale in production (twitter...) you can \n\nThen comes the feedback loop of testing scaling, and making sure that your test environment reflects all the moving parts of production accurately enough without trying to match the scale...\n\n
- \n\nNext is scaling your tests (Jules can allude to his current client on this one...)\n\nScaling your CI infrastructure:\n\nAOL incident \n\nAfter that you need to make sure your software can scale in production (twitter...) you can \n\nThen comes the feedback loop of testing scaling, and making sure that your test environment reflects all the moving parts of production accurately enough without trying to match the scale...\n\n
- \n\nNext is scaling your tests (Jules can allude to his current client on this one...)\n\nScaling your CI infrastructure:\n\nAOL incident \n\nAfter that you need to make sure your software can scale in production (twitter...) you can \n\nThen comes the feedback loop of testing scaling, and making sure that your test environment reflects all the moving parts of production accurately enough without trying to match the scale...\n\n
- Web application testing is a core driver of CI pain\n
- Web application testing is a core driver of CI pain\n
- Web application testing is a core driver of CI pain\n
- \n
- \n
- Key message. Have this proportion of tests.\nYou might not use the same tools for each tier\nA tool for testing the DOM is not a general purpose testing tool\nYou can make your application easier to test by disabling GUI features (e.g. ads, painful ajax interactions)\nGUI tests ideally will take a slice of functionality rather than logging in, testing and logging out.\nMost CI builds are slow because of GUI tests.\nParallelizing GUI tests is dangerous unless you attempt to optimise first\nSome browsers are assloads slower than others\n\n\n\n\n\n\n
- \n
- \n
- You&#x2019;re not a bloody devop\nThese are the people who didn&#x2019;t want to be left behind\nCollaboration is #1\nPimp our other talk\n
- You&#x2019;re not a bloody devop\nThese are the people who didn&#x2019;t want to be left behind\nCollaboration is #1\nPimp our other talk\n
- You&#x2019;re not a bloody devop\nThese are the people who didn&#x2019;t want to be left behind\nCollaboration is #1\nPimp our other talk\n
- You&#x2019;re not a bloody devop\nThese are the people who didn&#x2019;t want to be left behind\nCollaboration is #1\nPimp our other talk\n
- The ultimate scaling - production\n\nThere is a lot we can talk about here about actually getting code in to production. Simple stuff like making sure your deployment scripts are treated as the top level code it is and tested accordingly...\n
- The ultimate scaling - production\n\nThere is a lot we can talk about here about actually getting code in to production. Simple stuff like making sure your deployment scripts are treated as the top level code it is and tested accordingly...\n
- The ultimate scaling - production\n\nThere is a lot we can talk about here about actually getting code in to production. Simple stuff like making sure your deployment scripts are treated as the top level code it is and tested accordingly...\n
- \n
- \n
- \n
- \n
- \n
- Demo of the build pipeline plugin\nVery engineer-focused approach\nSetting up the CD system is easy, retro-fitting all the tests to your app: hard\nNo excuse not to deploy all the time to staging systems\n\n\n
- Focus on driving down cycle time\nGreater emphasis on app releases\nUsing all of the pluming of CD\nYou&#x2019;re only done when you&#x2019;re in prod\nvenn diagram?\nsits on pillars of previous\n
- \n
- \n