Everything I learned about Continuous Integration, I learned from Systems Administration
•Download as KEY, PDF•
0 likes•876 views
DevOpsDays Gothenburg presentation where we explain how an earlier career in Systems Administration helped us kick ass in running Continuous Integration.
Recommended
More Related Content
Similar to Everything I learned about Continuous Integration, I learned from Systems Administration
Similar to Everything I learned about Continuous Integration, I learned from Systems Administration (6)
Recently uploaded
Recently uploaded (20)
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 don’t you suggest one?
- 27. Continuous Integration is about Collaboration
- 28. If you’re not a sysadmin, buy yours a beer.
- 29. Questions? The Doctor is in. @tomsulston @builddoctor julian@build-doctor.com
Editor's Notes
- \n
- - 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
- \n
- - 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
- Tom talks about why he’s here\n
- Daily Windows builds: Windows 95\nMozilla Tinderbox: 1999 -- https://github.com/mozilla/puppet-manifests\nMartin’s paper: 2000 CruiseControl: 2001\n\n\n
- next page\n- \n
- “Ci-but”: sans database, sans proper app deployment\n“Slow feedback loops”\nSucky tests\n\n
- I get to complain about things, to you\n\n
- \n
- \nExplain that you need to do CI first\n
- 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
- See notes on slide\n\n
- \n
- \n
- \n
- Operating system packages rock - explain sums\nPuppet and Chef - we know configuration management\nYou have to understand something /before/ you automate it\n\n
- We understand Disk I/O\nAnecdote of Sam’s CI server\nCI is a CPU/RAM/disk intensive activity\n\n
- CI outages cost money\n6 developers * 300/day\nthey should do without without servers\nbut who does\nCI is a production system\n
- Trouble shooting skills: strace, lsof, apptrace, dtrace, top,iostat\nBuilds are meant to break\n
- It’s the gateway to production\nYou’d be crazy not to do so\n
- \n
- We’ve been coding in Ksh,bash,perl, ruby for years\n
- \n
- “in the brains of your developers”\n“everything from source, to test, to commit to behaviour”\n
- \n
- \n