back a pageBACKback to top
TBR Global Chauffeuring
2nd April 2019

Change control and code review at TBR Global

A key objective for us here at TBR is to work closely with our customers to ensure we are providing the very best software and technological solutions, to support a wide range of travel booking experiences. This has been our core ethos since we started operating in 1991, and now in 2019 this innovative way of thinking remains firmly rooted in our DNA.

Since the very beginning, we have been designing, creating and developing our own in-house technological solutions, to cater to the needs of our diverse and wide-ranging client base across our three service lines – Corporate, Events and Roadshows.

Our system is highly bespoke, which helps us stand out from the crowd. It is customisable to business requirements, enabling our tools, from the MyTBR App to V Book, to perform its core function and more. Beyond this, we continually extend and adapt our systems, to manage rapidly evolving business requirements across a range of fast-paced industries.

To ensure a smooth-running process all of our tools, we have implemented varying levels of quality controls. The system evolves all the time and we need to know why a specific line of code has changed and who changed it. We also need to ensure that we follow coding standards. To facilitate change control across our tools, we use a customised version of Redmine to track our user stories and bug reports. All source code is managed via git and the amazing frontend tool, Gitlab.

Gitlab provides us with the ability to review individual lines of merge requests. It allows us to track open and closed discussions, capturing negative and positive sentiments. We have configured Gitlab to prevent merging into our main branch as long as there are open discussions and the publishing developer may need to resolve any potential issues. See an example of the system below:

We have also developed an in-house bot called radar which helps us to analyse merge requests for common errors and assign sub-system labels. These labels are very beneficial to us as it enables us to do a quick optical characterisation of our open merge requests.

Additionally, using tools like Gitlab allows every developer to read code and add comments. This ensures that we can deliver the greatest possible transparency on what will get released into the next deployment. This in essence means that each line of the solution can be tracked back to a specific story, revealing what department and user caused the initial change:

The solution has been version-controlled since 2005, and thanks to our expertise in this space, we can work quickly to diagnose issues across our tools and systems.

‘Born to innovate’ has been a core value at TBR since day one. As we evolve, we constantly seek to drive new ways of working to deliver client-led solutions, through our in-house propriety software and more.

Find out more about our in-house propriety technological solutions and how we can support you, by visiting the Innovation page of our website.