Travis CI
Hosted Continuous Integration
for Open Source Projects
The Process of
Continuous Integration
“… a so!ware development practice where
members of a team integrate their work
frequently … verified by an automated build...
Run tests in an environment as
close to production as possible.
Builds are triggered by
pushing code.
Builds are automatic. The only
“change” is the developer’s habits.
Enforces requirements:
Enforces requirements:
Code conventions
Enforces requirements:
Best practices
Enforces requirements:
Minimum code coverage
Enforces requirements:
Maximum cyclomatic complexity
If a test fails, the build breaks.
When a Build Breaks
When a Build Breaks
Tables are flipped.
The team is notified.
Integration isn’t continued until
the problem is solved.
We learn from our mistakes.
It isn’t all fire and brimstone.
The Benefits of
Continuous Integration
You’ll be confident in the stability
of your so!ware.
You’re forced to ensure broken
code is never pushed or deployed.
Everyone on the team must
practice code cleanliness.
Continuous Deployment
is a step away.
It manages itself.
Your users will thank you.
Travis CI with
Open Source Projects
It takes less than 10 seconds to
investigate the stability of a gem.
It takes less than 10 seconds to
investigate the stability of a gem.
It takes less than 10 seconds to
investigate the stability of a gem.
Pull requests demand less
inspection on GitHub.
Tests can be run on
multiple Ruby versions
and implementations.
It’s completely free.
(a short demo)
If you’re reading this on
Slideshare… ಠ_ಠ
Etiquette
Push changes frequently
(multiple times per workday).
Troll your teammates when they
break a build.
Take responsibility for builds
broken by your commits.
Closing Thoughts
Always passing builds could be a
sign of Continuous Ignorance.
Implementing CI for a
single developer startup might
be too much.
Questions?
Upcoming SlideShare
Loading in …5
×

Travis CI

740 views
658 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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
740
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Travis CI

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

×