Your SlideShare is downloading. ×
Travis CI
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Travis CI

436
views

Published on

A brief introduction to continuous integration (what it is, its purpose, and how it helps teams in terms of efficiency and product stability) and how to use it with your open source projects.

A brief introduction to continuous integration (what it is, its purpose, and how it helps teams in terms of efficiency and product stability) and how to use it with your open source projects.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
436
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Travis CI Hosted Continuous Integration for Open Source Projects
  • 2. The Process of Continuous Integration
  • 3. “… a so!ware development practice where members of a team integrate their work frequently … verified by an automated build (including test) to detect integration errors as quickly as possible.” –Martin Fowler, May 1, 2006
  • 4. Run tests in an environment as close to production as possible.
  • 5. Builds are triggered by pushing code.
  • 6. Builds are automatic. The only “change” is the developer’s habits.
  • 7. Enforces requirements:
  • 8. Enforces requirements: Code conventions
  • 9. Enforces requirements: Best practices
  • 10. Enforces requirements: Minimum code coverage
  • 11. Enforces requirements: Maximum cyclomatic complexity
  • 12. If a test fails, the build breaks.
  • 13. When a Build Breaks
  • 14. When a Build Breaks
  • 15. Tables are flipped.
  • 16. The team is notified.
  • 17. Integration isn’t continued until the problem is solved.
  • 18. We learn from our mistakes.
  • 19. It isn’t all fire and brimstone.
  • 20. The Benefits of Continuous Integration
  • 21. You’ll be confident in the stability of your so!ware.
  • 22. You’re forced to ensure broken code is never pushed or deployed.
  • 23. Everyone on the team must practice code cleanliness.
  • 24. Continuous Deployment is a step away.
  • 25. It manages itself.
  • 26. Your users will thank you.
  • 27. Travis CI with Open Source Projects
  • 28. It takes less than 10 seconds to investigate the stability of a gem.
  • 29. It takes less than 10 seconds to investigate the stability of a gem.
  • 30. It takes less than 10 seconds to investigate the stability of a gem.
  • 31. Pull requests demand less inspection on GitHub.
  • 32. Tests can be run on multiple Ruby versions and implementations.
  • 33. It’s completely free.
  • 34. (a short demo)
  • 35. If you’re reading this on Slideshare… ಠ_ಠ
  • 36. Etiquette
  • 37. Push changes frequently (multiple times per workday).
  • 38. Troll your teammates when they break a build.
  • 39. Take responsibility for builds broken by your commits.
  • 40. Closing Thoughts
  • 41. Always passing builds could be a sign of Continuous Ignorance.
  • 42. Implementing CI for a single developer startup might be too much.
  • 43. Questions?