I’m Jonny Cavell, Technical Lead for the Registered Traveller exemplar at the Home Office. This is a post about how we shared code between two exemplar projects – Visas and Registered traveller – the successes, the difficulties, and everything in between.
One early success from the Registered traveller exemplar was the reuse of existing code from the Visas exemplar. This saved time and got the project up and running more quickly than if we had developed the application from scratch. At later points in the development process, we merged our code with that of the 'visit visas and immigration' (VVI) team’s alpha; a process with many benefits and lessons.
Even before the Registered traveller project began, we were keen to use existing code from the product catalogue that the VVI team developed for their alpha. The Visas applications project was a great starting point.
First merge
We spent about two weeks working on and adapting the VVI team’s code. In that time the VVI team continued to make enhancements and improvements to their own alpha.
To take advantage of these developments, we decided to merge our code with theirs. This process took 24 hours. We agreed not to merge code again while we developed our alpha, because we needed to focus on delivering our own user stories.
The drawback of developing our alpha independently was a nagging feeling that the VVI team were continuing to make code improvements, bug fixes and architectural enhancements which we were missing out on. This sense was compounded when the VVI team developed a payment solution that was virtually identical to the one we needed.
Merging after finishing the alpha
As soon as we finished work on our alpha, we decided to merge our code with the VVI’s again. This would give us the benefit of the following extra features that had been developed since the last merge:
-
payment code, robustly tested
-
architectural improvements, bug fixes, test enhancements
-
multiple aliases (‘additional names’)
-
navigation back to previous forms using breadcrumbs
-
improved performance
-
application ‘health checks’
We also wanted to keep the option of merging code in future to incorporate improvements and bug fixes to e.g. processing payments with Worldpay and the product catalogue. If we hadn’t merged at this point, merging in the future would have become impossible.
We knew that this merge would be more troublesome than the first because at least five weeks had passed since we’d last done it. In that time, the VVI team had added, taken away, renamed and changed code. However, for the benefits we would gain, we felt it was worth doing.
Success
We went ahead with the merge. It took 3 days and was a great success. We gained all the benefits, saved ourselves a lot of time and celebrated accordingly. We later did a couple more merges following further developments to the original code.
Challenges
Although the merges were very successful and brought hugely useful benefits (such as improvements to the product catalogue code), each new merge was time consuming and brought its own disadvantages, for example:
-
a risk of regressions – this was serious and seemed to increase over time
-
‘code bloat’ – the incorporation of code we didn’t need and didn’t understand
-
changes to JavaScript and the CSS, which affected the look, the feel and even the functionality of the Registered Traveller website
It became more difficult to merge without creating issues. We only merged code in one direction – from the VVI team’s alpha to ours, and not the other way round. Along with increasing ‘code bloat’ and a risk of regression, there was the knowledge that If VVI did a large refactoring, we’d be stuck.
Future plans - cherry picking features for merging code
I’m not sure we’ll do a ‘full’ merge again. We still want to share code, but we think we’ll need to do it in other ways. This might be by cherry-picking certain features. It might be by recommending that we split off various components (like payment) into libraries which we can include.
Merging has been great for us in the short term but we knew it wouldn’t be a long-term solution. Opinions vary but one longer-term vision for sharing involves the product catalogue becoming a separate, centrally maintained service. This, though, would require versioning and shared environments as well as increased complexity in communication and management. We are also thinking about using a ‘plugin’ architecture so that different products can be added without affecting the core functionality.
Jonny Cavell is Technical Lead for the Registered Traveller exemplar at the Home Office. Contact him for more information.
Leave a comment