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
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
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
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/
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
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
60. Thank you
Any Questions?
@builddoctor
julian@build-doctor.com
Hinweis der Redaktion
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“Toyoda’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”\nBut CI is not about machines, it’s about peopl;e\n
\n
This is CM done wrong\n
Which leads to this\n
it should be this\n
The 1840’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’t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
Don’t use email\nIf you use IDE or desktop widgets\nYou need to communicate the state to all\n\n\n
Don’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’re not a bloody devop\nThese are the people who didn’t want to be left behind\nCollaboration is #1\nPimp our other talk\n
You’re not a bloody devop\nThese are the people who didn’t want to be left behind\nCollaboration is #1\nPimp our other talk\n
You’re not a bloody devop\nThese are the people who didn’t want to be left behind\nCollaboration is #1\nPimp our other talk\n
You’re not a bloody devop\nThese are the people who didn’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’re only done when you’re in prod\nvenn diagram?\nsits on pillars of previous\n