Quantcast
Channel: Hue, the self service open source Analytics Workbench for browsing, querying and visualizing data interactively
Viewing all articles
Browse latest Browse all 171

The Hue team development process

$
0
0

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
    Screenshot 2016-05-04 13.19.36
  • 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)
    Screenshot 2016-05-04 13.22.14
  • 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 🙂
  • When committed, submit the code for review. 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
    Screenshot 2016-05-04 13.24.34
  • 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!
    2015-10-13 17.31.41

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

ps: we are hiring a software engineer! http://gethue.com/?jobs=senior-engineer

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


Viewing all articles
Browse latest Browse all 171