title: The Hue team development process
author: admin
type: post
date: 2016-05-04T14:34:51+00:00
url: /the-hue-team-development-process/
sf_thumbnail_type:
- none
sf_thumbnail_link_type:
- link_to_post
sf_detail_type:
- none
sf_page_title:
- 1
sf_page_title_style:
- standard
sf_no_breadcrumbs:
- 1
sf_page_title_bg:
- none
sf_page_title_text_style:
- light
sf_background_image_size:
- cover
sf_social_sharing:
- 1
sf_sidebar_config:
- left-sidebar
sf_left_sidebar:
- Sidebar-2
sf_right_sidebar:
- Sidebar-1
sf_caption_position:
- caption-right
sf_remove_promo_bar:
- 1
categories:
- Development
- News
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 🙂
{{< highlight bash >}}#!/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}"{{< /highlight >}}
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!