We’re kicking off a brand new series on the blog. In “BHL and its developers”, we meet some of the staff dedicated to setting up the technical components needed for the project. First up: Chris Sleep from the Natural History Museum in London!
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.
Can you give some more info on the GitHub issue tracker?
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.
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!