Everything I learned about Continuous Integration, I learned from Systems Administration
Download as KEY, PDF
0 likes877 views
DevOpsDays Gothenburg presentation where we explain how an earlier career in Systems Administration helped us kick ass in running Continuous Integration.
Everything I learned about Continuous Integration, I learned from Systems Administration
- 1. Everything I know about CI I learned from Systems Administration Julian Simpson, The Build Doctor Ltd with Tom Sulston, ThoughtWorks Ltd
- 5. Nothing is new Especially me
- 6. Especially me or Tom
- 7. Nothing is new Especially me or Tom
- 9. Yet ...
- 10. We still get it wrong
- 11. This is therapy for us
- 12. 10 reasons why systems admins rock at CI
- 13. Just CI?
- 15. Reason #2: Make
- 16. Ant: In theory, it is kind of like make, without make's wrinkles.
- 17. Is my command not executing because I have a space in front of my tab?!!
- 18. WTF?
- 19. Reason #3: We rock at deployment
- 20. Reason #4: We know systems
- 21. Reason #5: Do you code with the lights off?
- 24. Reason #8: Scale
- 26. Reason 10: Why dont you suggest one?
- 27. Continuous Integration is about Collaboration
- 28. If youre not a sysadmin, buy yours a beer.
- 29. Questions? The Doctor is in. @tomsulston @builddoctor julian@build-doctor.com
Editor's Notes
- #2: \n
- #3: - audience can ask questions\n- this is a loose structure to talk about CI. Ask questions if you like.\n- it’s about dev, but from ops point of view\n
- #4: \n
- #5: - infrastructures.org- cfengine - annoying guy on list- 2004: started running cruisecontrol\n- 2006: puppet - 2010: Started consulting in London- 2011: LondonCI meetup\n- Most things I see are broken\n
- #6: Tom talks about why he’s here\n
- #7: Daily Windows builds: Windows 95\nMozilla Tinderbox: 1999 -- https://github.com/mozilla/puppet-manifests\nMartin’s paper: 2000 CruiseControl: 2001\n\n\n
- #8: next page\n- \n
- #9: “Ci-but”: sans database, sans proper app deployment\n“Slow feedback loops”\nSucky tests\n\n
- #10: I get to complain about things, to you\n\n
- #11: \n
- #12: \nExplain that you need to do CI first\n
- #13: Doug McIroyThis is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.\nGreat design philosophy\n
- #14: See notes on slide\n\n
- #15: \n
- #16: \n
- #17: \n
- #18: Operating system packages rock - explain sums\nPuppet and Chef - we know configuration management\nYou have to understand something /before/ you automate it\n\n
- #19: We understand Disk I/O\nAnecdote of Sam’s CI server\nCI is a CPU/RAM/disk intensive activity\n\n
- #20: CI outages cost money\n6 developers * 300/day\nthey should do without without servers\nbut who does\nCI is a production system\n
- #21: Trouble shooting skills: strace, lsof, apptrace, dtrace, top,iostat\nBuilds are meant to break\n
- #22: It’s the gateway to production\nYou’d be crazy not to do so\n
- #23: \n
- #24: We’ve been coding in Ksh,bash,perl, ruby for years\n
- #25: \n
- #26: “in the brains of your developers”\n“everything from source, to test, to commit to behaviour”\n
- #27: \n
- #28: \n