The Hue team development process

04 May 2016 in Development / News - 3 minutes read

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 ūüôā

SUMMARY=$(curl -s${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 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!

comments powered by Disqus

More recent stories

13 November 2019
Visually surfacing SQL information like Primary Keys, Foreign Keys, Views and Complex Types
Read More
31 October 2019
Missing some color? How to improve or add your own SQL syntax Highlighter
Read More
24 October 2019
How to create a HBase table on Kerberized Hadoop clusters
Read More