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.

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?