The Hue team development process

Hello potential Hue developers! 🙂

We want to share with you the development process we've been refining during the past years. This is what makes the Hue team ultra fast and efficient.

Ready? Go!

• All the changes (new features, improvements, bugs) need to be tracked. We use JIRA.
• The changes should have a pseudo-mnemonic short ID (ie: HUE-123). That comes for free on JIRA but it requires a bit of programming on other systems. On Pivotal Tracker, for instance, you can use webhooks
  
• When a developer picks or gets assigned to a change, on her development environment she creates a branch specifically for that change. Our naming convention is DATE-SHORTID, so in the case of the previous example it would be git checkout -b 20160425-HUE123
  There are some tools that with a keystroke combination can expand text to the current formatted date (ie: Typinator on Mac)
  
• After the developer is done with changing the code, she makes sure to have just one commit, so squashing all the others if she needed more that one commit. For instance, if you have three commits you want to squash together git rebase -i HEAD~3
• The commit message should include the same short id of the story. ie: git commit -m "HUE-123 Bla bla bla". It's also a good practice to divide the code into "theoretical" modules, so if I work on the UI, let's say the "editor" module, i would do git commit -m "HUE-123 [editor] Bla bla". That should be reflected as a tag or in the title of the original story too 🙂

#!/bin/bash

SUMMARY=$(curl -s https://issues.cloudera.org/rest/api/2/issue/HUE-${1} | jq -r '.fields | .summary')

git commit -m "HUE-${1} ${SUMMARY}"

A trick is also to use above script to automatically add the commit message. Then just do ‘commit XXXX’.

• When committed, submit the code for review to http://review.cloudera.org/. There are many tools for that, but we use Reviewboard. You can install it yourself or have it as SaaS. Everything can be automated from the command line so there's no need to create a diff, a new review etc.
• Keep the target review time under 10 hours. if there's at least one 'Ship it', the code gets into master
• In case of 'Ship it', from the local story branch, do a git rebase origin/master, fix eventual rebase issues, and then git push origin HEAD:master
  
• Mark the story as resolved and paste into a comment the review URL + the commit URL of Github
• Here is a link to the jira HUE-3767 we used in this example
• Keep the stories small enough to go with rapid dev/review/push cycles
• Have fun!
  

Please feel free to comment or share your own development process!

pps: for lightweight issues, Github pull requests are also welcomed!