Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Adopting Continuous Integration in an Ops Group
1.
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
6.
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
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
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
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
35.
36. Changing the engine while
driving
• Lint tests (internal)
• Publicly exposed lint tests
• Uploads
• Tests
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
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