Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Travis CI

847 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
  • Be the first to comment

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?

×