Improving your product development processA view on the tools that help us improve

Roelof ReitsmaLead developer Coconut team

Favorite gems:Bundler & Capistrano

Favorite tools:Gerrit & Jenkins

When I'm not working: cycling, running and creating an awesome meal!

Goal:

Show two challenges we encountered developing our product

Demonstrate how two tools help us improve (which might be useful for you)

Contents

● An introduction to Coconut● First challenge: reliability● Second challenge: changeability● Conclusion

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

Introduction to Coconut

Start of the project● The first release syndrome● Novice level developers● The 80% done developer

Lead to some “pretty horrifying code”

Hall of shame

Examples?

Hall of Shame

Hall of Shame

Hall of Shame

Hall of Shame

Hall of Shame

Hall of Shame

Hall of Shame

Hall of shame

And sometimes some weird structures as well

Challenge 1: reliability

● Application would break randomly● No way of telling up front if things are OK

or not● Fixing or creating bugs?

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!

Challenge 1: reliability

Introduce Jenkins (prev. Hudson)● Open source tool for CI● Java webapplication● Highly configurable ● Easy to create your own scripts

Challenge 1: reliability

Main advantage of CI:

Instant feedback!

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

Jenkins: each git branch has a build

Jenkins: build queue

Jenkins: commits per build

Jenkins: review builds

Jenkins: review login page

Jenkins: review site

Jenkins: Chuck Norris plugin!

Build failed? Chuck's not happy

Jenkins: Chuck Norris plugin!

Build succeeded?

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?

Challenge 2: changeability

● Less changeable if– Untested code

– Hard to read code

– Code duplication

– Invalid comments

– Unused code

– Bad naming

Challenge 2: changeability

Solution: do code reviews

But how?● First: define the process● Second: choose the tool

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

Challenge 2: changeability

Introduce Gerrit● Open source code review tool● Java webapplication● Highly configurable ● Jenkins integration available

Challenge 2: changeability

Main advantage of code reviews

You learn a lot by reading other people's code!

Gerrit: list of reviewable commits

Gerrit: list of reviewable commits

Gerrit: list of reviewable commits

Gerrit: commit view

Gerrit: commit view

Gerrit: commit view

Gerrit: diff patchsets

Gerrit: diff patchsets

Gerrit: grade commit

Gerrit: DONE!

Oh no! We've abandoned HENK?

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.