1. Improving your product
development process
A view on the tools that help us improve

2. Roelof Reitsma
Lead developer Coconut 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 challenges we encountered
developing our product
Demonstrate how two tools help us improve
(which might be useful for you)

4. Contents
● An introduction to 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
Start of the project
● The first release syndrome
● Novice level developers
● The 80% done developer
Lead to some “pretty horrifying code”

7. Hall of shame
Examples?

8. Hall of Shame

9. Hall of Shame

10. Hall of Shame

11. Hall of Shame

12. Hall of Shame

13. Hall of Shame

14. Hall of Shame

15. Hall of shame
And sometimes 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
Introduce Jenkins (prev. Hudson)
● Open source tool for CI
● Java webapplication
● Highly configurable
● Easy to create your own scripts

19. Challenge 1: reliability
Main advantage of CI:
Instant feedback!

20. Challenge 1: reliability
What do 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 git branch has a build

22. Jenkins: build queue

23. Jenkins: commits per build

24. Jenkins: review builds

25. Jenkins: review login page

26. Jenkins: review site

27. Jenkins: Chuck Norris plugin!
Build failed? Chuck's not happy

28. Jenkins: Chuck Norris plugin!
Build succeeded?

29. Challenge 2: changeability
You are 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
Introduce Gerrit
● Open source code review tool
● Java webapplication
● Highly configurable
● Jenkins integration available

34. Challenge 2: changeability
Main advantage of code reviews
You learn a lot by reading other
people's code!

35. Gerrit: list of reviewable commits

36. Gerrit: list of reviewable commits

37. Gerrit: list of reviewable commits

38. Gerrit: commit view

39. Gerrit: commit view

40. Gerrit: commit view

41. Gerrit: diff patchsets

42. Gerrit: diff patchsets

43. Gerrit: grade commit

44. Gerrit: DONE!

45. Oh no! We've abandoned HENK?

46. Conclusion
● We drastically improved 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.