The Hue team development process

Published on 04 May 2016 in Development - 3 minutes read - Last modified on 19 April 2021

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

03 May 2023
Discover the power of Apache Ozone using the Hue File Browser
Read More
23 January 2023
Hue 4.11 and its new dialects and features are out!
Read More