For a team developing an innovative product, collaborative work represents a true challenge. If each team member works alone in his corner, this is clearly a recipe for disaster. So the team spends hours on endless meetings, this is valuable time wasted for the project, sometimes conducting to delay the delivery of a key feature.
Atlassian tools, such as Hipchat, offer to agile teams who pays high attention to the quality of their product a true collaborative solution. In this article, we have invited Joel Cogen & Stephane Amant from Belighted to share with you the toolset their developers use to work efficiently together.
For a few months here at Belighted, we are all committed to release what could be a new breakthrough into the service related ERP world! We crafted it using such amazing tools as AngularJS and other trending ones!
But in our way to achieve such a challenge, we needed to put in place a workflow which needed to be as complete as possible in order to allow a high quality level of crafted code as well as traceability and as easy and lean as possible in order to focus only on features development.
In order to make things as smooth as possible for everybody, we rely on a few great tools, integrated together so everything that can be is automatic.
Starting a feature
As with any agile project, features of Nomad Suite are described as stories, ordered by priority on the popular Pivotal Tracker.
The first step is therefore to start the first story in the backlog. This lets everybody know who is working on what and, because we use HipChatfor internal communication and we hooked both tools together, all stakeholders are notified.
Next, we create a new feature branch, with a clear and concise name — it is destined to be pushed, so it shouldn’t confuse other developers. Some of us like to add the story ID from Pivotal, but the truth is we don’t really have a strict pattern. Feature branches are extremely important to us because they allow you to experiment at will, commit, share your changes, and rollback if need be, all without disrupting the work of other and, most importantly, staging and production deployments.
On rare occasions, we do commit directly on master, but the change must then meet two conditions:
- It doesn’t need review by another developer. This is true for very small bugs, typos and some settings changes, but not much else.
- It must be trivial enough that if you get interrupted, it can be stashed or discarded, and easily applied when you come back to it.
Continuous reporting
At every push to GitHub, the team is notified on HipChat. This is a great way to let everybody interested know how the feature progressing.
Our CI, Semaphore, is also notified, and will let you know if all tests are green through — you guessed it — HipChat. This allows developers to not run the entire test suite, as some tests can take a few minutes. It is perfectly OK to break a feature branch.
Finishing up
Once the feature is implemented, tested, and all tests are green, the feature branch is ready to be merged into master.
Or is it? Now is the time to look at the commits, and squash the branch if necessary.
As for branch names, we don’t have explicit guidelines on commits and messages, but here are a few things we hate to see, from bad to worst:
- Incomplete (not functionnal) feature
- Untested feature
- Broken tests
- “wip”
All commits should reference the Pivotal Tracker story ID and the last one should say it finishes it, so GitHub can update the tracker for us. The story is now automatically marked as finished, but it still needs review. Time to open a Pull Request on GitHub.
Review
Because we want to make sure this is the best code we can write, and we can all learn something from somebody else, all changes need to be reviewed by another developer. It can be anybody — the important thing, like with pair programming, is to have another pair of eyes, but we will sometimes ask someone with particular expertise to do the review.
After a little back and forth (with amended commits and forced pushes), the reviewer can finally decide to merge the feature. He is also reassured by Semaphore, which tested the branch and reports status on the Pull Request.
Deployment
After the merge, Semaphore will run tests on the new master. They should all be green, so it will deploy on Heroku for us (and yes, notify HipChat). Our custom deploy script also uses the tracker-git gem, so stories will now automatically be delivered.
Time for the next story!..
Hoping this post could help people looking for an efficient way of organizing their job !
A warm thanks for the Belighted team for sharing this with us! If you liked this article, please support their project. You can like them on facebook, follow them on twitter or just visit their website.
