Adopting Continuous Integration in an Ops Group
- 2. Adopting Continuous Integration in an Ops Group DANIEL WESTER • CHIEF ENGINEER • TURNER BROADCASTING SYSTEMS, INC • @DWESTER42a
- 3. Disclaimer All opinions stated are those of the presenter and does not necessarily reflect those of Turner or any of its affiliates or partners.
- 4. CI usage at TBS • Development occurs in a wide range of languages • A lot development teams • A lot of testing already in place • CI Server service offered by Infrastructure team
- 5. Why offer a CI Service? • Encourages Source Code Management usage/ practices • Creates a build-focused mentality • Standardizes the entry point to deployment
- 7. Some “tips” for scale, testing and deploys • Create modular artifacts • Avoid the kitchen sink type of applications • Be able to switch application versions • Reflected in our build plans
- 8. “ Please make sure that XXX can scale and handle traffic. Oh we’re ” launching tomorrow.
- 9. The problem • Limited resource availability (me) • Out of band checks usually don’t get fixed • Not popular with developers • Last minute requests — not popular with reviewers
- 11. DIB
- 12. Daniel Box
- 14. What is DIB? • Selenium backed • Canned version of “DOB” • Found 80% of DOB tests • 2 versions — Web-based and Maven plugin
- 15. Website versus in-build tests • Website version could be down for weeks • Tests in the build — reports in minutes • Developer relies on in-build tests • If in-build tests fails... There’s more time to fix...
- 16. What did it do? • New development teams asked for it to be added • Features added based on requests • Other tests were added by dev teams
- 17. Build stages
- 19. What didn’t work - fUnit
- 20. Lessons Learned
- 21. Lessons learned • In-process automated testing is key • Run tests as soon as commits are done • If you’re a downstream team, provide upstream team’s tests • CULTURE matters
- 22. What about Ops?
- 23. What is Chef? • Configuration Management system • Ruby-based • Easily expandable • Many ways of approaching things
- 24. User adoption
- 25. “ We need to have a script that gets triggered whenever there’s a ” commit and does stuff.
- 26. Enter CI
- 27. Cookbooks
- 31. Plan Stages • Lint • Test • Upload
- 32. Lint test • Code style guideline checker & more • Tabs versus spaces, “” versus ‘’ • Less objections to utilities reviewing code
- 33. Tests
- 34. Moving away from tagging • CI server generates artifacts and uploads • Avoid access issues • CI server becomes “trusted” source of what’s a “good” version
- 36. Changing the engine while driving • Lint tests (internal) • Publicly exposed lint tests • Uploads • Tests
- 37. Plan branches
- 38. Code Reviews
- 40. Pull requests • Lightweight review system • Engineers choose to use pull requests • Larger changes still go through Peer Review tool • End result: More core reviewed
- 41. Today’s Code Flow Commit on branch Plan branch triggered Master branch triggered Pull request Upload and ready for ‘trigger’
- 42. End Result • Faster throughput • Repeatable process • Audit trail of when changes were made • Lightweight process with large impact
- 43. Thank you! DANIEL WESTER • CHIEF ENGINEER • TURNER BROADCASTING SYSTEMS, INC • @DWESTER42a
- 44. Rate this Talk Adopting Continuous Integration in an Ops Group Text code below to 22333 or visit http://bit.ly/18zxBVY MEH = 3B NO T BA D = 3C P R ET T Y GO O D = 3D A WES O ME = 3E To join this session, send text 136888 to