My initial involvement with BHL-Europe was with respect to the hardware; the BHL-Europe services are run on an array of machines and storage which is physically hosted here at the NHM in London, where I was involved in the installation and initial configuration. Since then I’ve become more deeply involved with BHL-Europe with the departure of the previous Workpackage 3 leader I’ve up the technical side of the role working closely with Graham Higley the formal WP3 lead, and Lola Obajuluwa who provides our Project Management.
What has been the biggest challenge the developers have faced?
The biggest challenge for BHL-developers so far is the fact that we live in many countries around Europe. Most of the time, every office or institution in the different countries has just one developer – but in our work we all depend on each other. We all need clear sight of what each other are doing and what changes have been done, so that our work builds upon a common base.
So finding a way of raising issues and problems, and discussing and resolving them, was absolutely critical. And we had to do this in a fashion so that wherever we are (be it in a workshop, meeting, conference etc.), we all have access to the information we needed!
So what did you come up with to solve this problem?
The project is one of implementing best practice standards, so the choice for the development environment moved towards a best practice scheme. More specifically, we set up GitHub, which is a code repository where we keep all our source code. This repository is tied to a GitHub issue tracker, where we can raise issues and problems.
Basically, GitHub is a revision source control system. A developer works on the system on his own machine, and “commits” the code if it’s good. This means that changes they’ve made are written up in the GitHub repository, and GitHub keeps track of these changes and what has been done by whom and when.
This is all tied to a component called “Jenkins”, a continuous integration tool that is on the integration server here at the Natural History Museum. You could say that Jenkins “watches” GitHub, and that whenever a change goes through Github, Jenkins grabs it, refreshes the databases and puts the change live so that people can immediately see on the NHM server what the BHL-Europe portal looks like! Similarly, all developers can synchronize GitHub, i.e. pull back changes from GitHub to their machine and know that other developers will do so as well. So even if we’re out of office and working on different machines, we can always work with the other changes that have been done!
In short, the issue tracker is a database that’s related to the features we’re building and the bugs associated with them. Issues, such as bugs, are attached to particular milestones. When those issues are closed, they are moved to a test milestone and reopened for testers.
It’s also worth noting that GitHub is an Open Source Free License tool; it’s available to all members of the team and the public. Thanks to GitHub, testers can – if they want to - see the thinking that went on in the implementation. The background info is all there – and it’s not hidden in someone’s email inbox.
When was GitHub implemented?
We started moving the code in GitHub back in June 2011. In August 2011, we linked the code deployment up with Jenkins. We’ve been working with it for the last three to four months.
Before June 2011, we had to build both our integration site and our test site by hand. Developers worked locally on their machines, sent me their codes and then I put everything into place. This caused us a lot of waiting and delay before we could see the developed code. GitHub thankfully is a powerful tool that helps speed up development!
