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

13. DOB still exists...
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

18. What didn’t work?

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

28. Creating a cookbook

29. 10 minutes later...

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

39. Before pull requests

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