Back To The Sources – eXo Tooling: Code Edition, Review and Version Control
To interoperate with our sources presented before we are are using various tools. Let’s take a tour of them.
Code edition
At eXo, our developers are free to use the IDE or editor they like (Eclipse, IntelliJ, Netbeans, ….). The only thing we ask is that they must follow the rules we defined to format the code.
- The code contained within braces will be indented by the value defined by 2 spaces.
- A maximum line-length of 130 characters will be used, so when an expression can not fit on one line, you can spread it over several lines. The break is allowed after a comma, an operator or after a closing parenthesis. So as not to confuse the code with a new statement, we choose to indent the following line from the beginning of the instruction.
- It’s allowed a single declaration or statement per line, as it’s allowed to comment on the same line too.
- Tabs are not allowed, we will use only spaces to make the indentation so that the layout is the same regardless the editor used.
On top of that they are able to check the compliance of the code they are writing with IDE plugins that are integrating Checkstyle and friends. These rules are available on our Sonar server which is controlling them (we’ll discuss about it on another post).
Versions control
Even if all IDE are proposing an integration for Git, I really advice for Windows and MacOS developers to use the Atlassian SourceTree tool. It proposes a really clean UI to manage the major part of GIT operations even complex ones like an interactive rebase.
Also as it is often easier to use Git from the command line we are using these really useful extensions :
- git-flow provides a collection of Git extensions to provide high-level repository operations for Vincent Driessen’s branching model.
- hub is a command line tool that wraps git in order to extend it with extra features and commands that make working with GitHub easier.
Code review
One important thing in our development practices is to ensure the review of all the code developed by someone by several of his teams members.
For that we used to do a code review on our instance of Atlassian Fisheye/Crucible (3.2.4 while I‘m writing these lines). Now with Github we have also the ability to use its pull requests and even if they are powerful and really useful our teams are always preferring Crucible for its integration with Atlassian Jira our issues tracker and its ability to manage reviews across several sources repositories at a time..
The goal of these reviews are to improve our global knowledge of the codebase, to share best development practices and to ensure a good quality of the code. This is as important for the software we are developing as for the knowledge sharing between team mates.
Our process is to develop each new feature in a dedicated branch of the development repository. On this branch the code review is done using Crucible. When the team has validated the feature they merge it into the master branch.
Github pull requests are often used when we have to propose a fix on a maintenance branch. The team is preparing the patch in a fix branch on the development repository. They may use Crucible to sanitize it and operate the review. When the team validates it they proposes it to the maintenance team as a pull request which will validate it (or no).
Note : As responsible of the exploitation of all these tools I regret that Fisheye/Crucible doesn’t propose a better integration with github to automatically configure all repositories from an organisation (like it is possible in Jira with its >DVCS plugin). The administrator has to manually reference all repositories manually which is a pain to do (happily Fisheye keeps these settings in a configuration file in XML file that I was able to generate to declare all repositories from an extract using Github APIs).
Make the most out of eXo Platform 4
Register to the next webinar and get a complete overview of what you can do with eXo Platform 4. Reserve your seat now!