Download to read offline
Product development and tools
- 1. Improving your product developmentprocess A view on the tools that help us improve
- 2. Roelof Reitsma Lead developerCoconut team Favorite gems: Bundler & Capistrano Favorite tools: Gerrit & Jenkins When I'm not working: cycling, running and creating an awesome meal!
- 3. Goal: Show two challengeswe encountered developing our product Demonstrate how two tools help us improve (which might be useful for you)
- 4. Contents ● An introductionto Coconut ● First challenge: reliability ● Second challenge: changeability ● Conclusion
- 5. Introduction to Coconut ●An private social network ● Development in Ruby on Rails since 2008 ● Started as our intranet application ● Focus on sharing knowledge ● Competing with – Any other intranet solution – Enterprise social networks – Sharepoint
- 6. Introduction to Coconut Startof the project ● The first release syndrome ● Novice level developers ● The 80% done developer Lead to some “pretty horrifying code”
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. Hall of shame Andsometimes some weird structures as well
- 16. Challenge 1: reliability ●Application would break randomly ● No way of telling up front if things are OK or not ● Fixing or creating bugs?
- 17. Challenge 1: reliability Solution:do test driven development Then you must have CI! ● otherwise no-one will run tests ● or say: it works on my PC!
- 18. Challenge 1: reliability IntroduceJenkins (prev. Hudson) ● Open source tool for CI ● Java webapplication ● Highly configurable ● Easy to create your own scripts
- 19. Challenge 1: reliability Mainadvantage of CI: Instant feedback!
- 20. Challenge 1: reliability Whatdo we do in a Jenkins build? – Create sandbox – Check basics (bundle, database setup etc) – Run specs – Run integration specs – Run acceptance specs – Create review site – Check if site runs at all
- 21. Jenkins: each gitbranch has a build
- 22.
- 23. Jenkins: commits perbuild
- 24.
- 25.
- 26.
- 27. Jenkins: Chuck Norrisplugin! Build failed? Chuck's not happy
- 28. Jenkins: Chuck Norrisplugin! Build succeeded?
- 29. Challenge 2: changeability Youare going to write all code at least twice. And that's not even considering change. ● How hard is it to refactor? ● How fast can you change functionality?
- 30. Challenge 2: changeability ●Less changeable if – Untested code – Hard to read code – Code duplication – Invalid comments – Unused code – Bad naming
- 31. Challenge 2: changeability Solution:do code reviews But how? ● First: define the process ● Second: choose the tool
- 32. Challenge 2: changeability Goal:prevent erroneous or bad code to get into central repository 1)Developer submits commit 2)CI checks commit for errors 3)Other developer reviews code 4)When both OK: code submitted to main repository
- 33. Challenge 2: changeability IntroduceGerrit ● Open source code review tool ● Java webapplication ● Highly configurable ● Jenkins integration available
- 34. Challenge 2: changeability Mainadvantage of code reviews You learn a lot by reading other people's code!
- 35. Gerrit: list ofreviewable commits
- 36. Gerrit: list ofreviewable commits
- 37. Gerrit: list ofreviewable commits
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45. Oh no! We'veabandoned HENK?
- 46. Conclusion ● We drasticallyimproved quality by doing TDD and code reviewing ● Jenkins and Gerrit are nice tools that are free, offer lots of features and do the job well ● However, tools are less important. Choosing the correct process is.