Downloaded 157 times
Uploaded byJulian Simpson
Continuous Integration, the minimum viable product
The document outlines principles of continuous integration and discusses key practices, such as testing everything including databases and ensuring regular code checks. It emphasizes the importance of using database migrations and avoiding common pitfalls in production environments. Additionally, it covers topics related to DevOps, production scripting, and continuous delivery to enhance software deployment efficiency.
More Related Content
Similar to Continuous Integration, the minimum viable product
Continuous Integration, the minimum viable product
- 1. Continuous Integration The Minimum Viable Product Julian Simpson - @builddoctor Chris Read - @cread
- 2.
- 3.
- 4.
- 5.
- 6.
- 7. http://www.flickr.com/photos/mainmanwalkin/3074193461/ mainline release branches
- 8.
- 9.
- 10. CI Principles • Buildand test everything, when it changes
- 11. CI Principles • Buildand test everything, when it changes • The database schema counts as everything
- 12. CI Principles • Buildand test everything, when it changes • The database schema counts as everything • Tests count as everything
- 13. CI Principles • Buildand test everything, when it changes • The database schema counts as everything • Tests count as everything • And JavaScript
- 14. CI Principles • Buildand 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 • Buildand 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.
- 17.
- 18.
- 19. Databases • Use databasemigrations
- 20. Databases • Use databasemigrations • Don’t write your own tool
- 21. Databases • Use databasemigrations • Don’t write your own tool • Don’t mix DDL and DML
- 22. Databases • Use databasemigrations • 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.
- 26.
- 27. Notifications • Email isevil • IDE or tray tools are OK
- 28. Notifications • Email isevil • IDE or tray tools are OK • Big Visible tools are awesome
- 29.
- 30.
- 31. Scaling • Solid StateDisks are your friend
- 32. Scaling • Solid StateDisks are your friend • Scaling tests is a different concern: http:// test-load-balancer.github.com/
- 33. Scaling • Solid StateDisks are your friend • Scaling tests is a different concern: http:// test-load-balancer.github.com/ • Don’t fake infrastructure to make it fast
- 34.
- 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’ttest them, validate them
- 39. Though testing is better
- 40.
- 41.
- 43.
- 44. DevOps • most misunderstoodmeme of recent times http://www.flickr.com/photos/shaggypaul/193098324/
- 45. DevOps • most misunderstoodmeme of recent times • agile approach to systems admin http://www.flickr.com/photos/shaggypaul/193098324/
- 46. DevOps • most misunderstoodmeme of recent times • agile approach to systems admin • developer-sysadmin collaboration http://www.flickr.com/photos/shaggypaul/193098324/
- 47. DevOps • most misunderstoodmeme of recent times • agile approach to systems admin • developer-sysadmin collaboration • provides feedback to the business http://www.flickr.com/photos/shaggypaul/193098324/
- 48.
- 49. Production • Deployment scriptsshould be rehearsed in CI
- 50. Production • Deployment scriptsshould be rehearsed in CI • CI servers should be built the same way as prod
- 51. Production • Deployment scriptsshould be rehearsed in CI • CI servers should be built the same way as prod • Tools like Puppet and Chef help you do that
- 52.
- 53. New server: 45seconds 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? MyISP 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
- 57.
- 58. http://www.flickr.com/photos/rsgranne/179321532/ Continuous Delivery ...satisfy the customer through early and continuous delivery of valuable software ... (ask Jez)
- 59.
- 60. Thank you Any Questions? @builddoctor julian@build-doctor.com
Editor's Notes
- #2 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
- #3 Explain Chris\nDo the experience check\nAsk for questions\nTake a deep fucking breath\n\n
- #4 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
- #5 \n
- #6 This is CM done wrong\n
- #7 Which leads to this\n
- #8 it should be this\n
- #9 The 1840&#x2019;s called, they want your CI status back\n
- #10 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
- #11 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
- #12 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
- #13 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
- #14 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
- #15 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
- #16 \n
- #17 \n
- #18 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
- #19 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
- #20 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
- #21 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
- #22 \n
- #23 \n
- #24 Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- #25 Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- #26 Don&#x2019;t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
- #27 \n
- #28 \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
- #29 \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
- #30 \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
- #31 Web application testing is a core driver of CI pain\n
- #32 Web application testing is a core driver of CI pain\n
- #33 Web application testing is a core driver of CI pain\n
- #34 \n
- #35 \n
- #36 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
- #37 \n
- #38 \n
- #39 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
- #40 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
- #41 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
- #42 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
- #43 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
- #44 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
- #45 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
- #46 \n
- #47 \n
- #48 \n
- #49 \n
- #50 \n
- #51 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
- #52 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
- #53 \n
- #54 \n