Archive for the ‘ReviewBoard’ Category
MarkUs is entirely developed by undergraduate students. Since MarkUs is a web-application developed for and by undergraduate students, there are some challenges to overcome. Most notably there is high developer turn-around and development happens in a fairly distributed fashion. We try to overcome those challenges by instrumenting established means of quality assurance (QA) in the open source world. In order to keep code in shape and well tested some quite heavy tooling is involved at markusproject.org.
What started as a small project at University of Toronto is becoming more and more what one might call a classical open source organization. As FOSS (Free and Open Source Software) projects don’t have a lot of money, they use various other open source software for their development. And so is MarkUs.
MarkUs developers use a mix of method and tools for their development. Some of those tools are:
- Git (version control)
- GitHub (wiki, issues, pull requests)
- ReviewBoard (code review tool)
- Tests (functional, unit)
- Test Coverage Analysis
- Sandbox (MarkUs demo application)
- Blog (blog.markusproject.org)
- #markus IRC channel on freenode
A subset of those tools fall into the realm of QA.
Git as Source Control Management (SCM)
Git is a decentralized SCM. Every developer has its own local repository. We have chosen a decentralized workflow. Nobody pushes directly to the central repository. Instead, people push to their own public repository hosted on GitHub (fork) and notify core developers, by instrumenting GitHub’s pull requests, to get changes in to the main MarkUs repository. This ensures that only well vetted code goes into the main development repository. What’s more, every patch has to be reviewed before being applied to the main repository (see section ReviewBoard of this blog post).
GitHub as a Project Management Tool
In addition to providing public repositories, GitHub allows the team to manage issues and documentation (wiki). People can interact with the wiki using the Web interface, but also using Git. Several markup languages are supported. We chose to use the ReStructuredText syntax. The issue tracker is quite simple, but has labels rather than categories, which can come in handy in several cases. On a related note, GitHub allows for issues to be closed automatically.
GitHub also displays a graph of everyone’s forks and branches.
Before code goes into our main repository, it has to be reviewed by the team. This is an excellent way to improve code quality and to quickly spot common mistakes, especially in cases of high developer turn-around, which is the case for MarkUs. Another benefit is that it helps the whole team to keep an eye on every area of the project, even the ones they don’t code on. In other words it is an excellent tool to speed up getting familiar with the code base.
Once the code has been reviewed and/or revised, developers will check the “ship it” flag for a review request indicating that they are OK with submitting this code to the main development repository. Once the person who posted the review request received several “ship it”, the original poster can open a pull request on GitHub. After another once-over of a core developer the code in question gets merged into the main repository.
Unit Tests and Functional Tests
A great way to increase confidence if the code is doing what it is supposed to be doing is to write unit and/or functional tests for each piece of contributed code. We think we have been doing a quite good job at this. The number of tests increase almost on a daily bases. Functional and unit tests run every few hours and results are shown on on markusproject.org.
Code Coverage: How Well is MarkUs’ Code Exercised When Tests Run?
Trustworthy tests are essential. We think it’s important to check how well our code is tested. Tests coverage analysis provides us with good hints as to where our code lacks testing. Ruby Coverage a.k.a. RCov is an excellent tool to provide visual feedback as to what is tested and what is not.
A MarkUs Demo: Sandbox
A current version of MarkUs in action is available to anybody on markusproject.org to play with. We try to keep the running version as up-to-date as possible. Instructions as to how to use it are described in this blog post. Note that the underlying database of this instance is flushed on a daily basis. So please don’t expect your data to persist any longer than a day or two 😉
On our blog we describe progress, propose new features, announce new releases, post individual experiences related to MarkUs development (mostly including solutions too) and various other random things. Following our blog allows you to get a feel of the current state of the project, planned features and many more. For developers it is recommended to keep an eye on the blog every once in a while. You might find an elegant solution a problem you might have encountered. Keep reading it 🙂
#markus IRC channel
We have our IRC channel, #markus, on irc.freenode.net. That’s the place where you can meet developers and can get almost instant help for a MarkUs related problem you might have. You can also just drop by and say hello. It’s a friendly small community hanging out there. In short, it is a good place to chat with current and former developers or other lurkers, who tend to hang out on IRC. See you there! 🙂
Bryan Shen and I work together to get the following design(class diagram and database tables):
This is our final design, and we think it is pretty good to fit in our project, however suggestions are still welcome.=)
An additional feature of this design is that we can have different number of levels of rubric criterion if we want.
We have already started to update the whole MarkUs project to adopt this design.
Here’s a quick snapshot of what the team did yesterday:
- Lots of coding! Tickets were assigned, ReviewBoard was cookin’ with lots of activity
- A bunch of code from the new team got past review, and went straight into the repo! Excellent!
- A unexpectedly long lunch break
- All of the teams celebrated the end of the day by heading out to a Chinese restaurant. So much food!
Today is the last day of the sprint. We’re having a meeting later today to figure out the direction for the rest of term. We’ll keep you posted!
We’ve taken some effort to get ReviewBoard up and running. If you are not yet familiar with this tool, now is the time to do so. Please have a look at our “How to use ReviewBoard” document.