Our team supports nine applications out of the same code base (achieved by a combination of configuration, feature toggles and CSS magic). This code base has been evolving continuously over the last five years and we do at least one release every week and often more than that. Given this scenario, you can imagine how vital a role that unit tests play.
We depend a lot on our unit tests (among other things, of course) to ensure that releases go smoothly and that, when we add that shiny new feature that enables the customer to change her seat, it does not break the feature that lets her get the ticket on her mobile! To achieve this, our team adheres strictly to TDD and we have over 10,000 unit test cases that are run every time a commit is pushed to github and this number keeps on growing with every new feature development that we do.
How could we run our unit tests faster?
OK, so we have great unit-test coverage. However, the side effect of this is that it usually took more than 5 minutes to run the unit tests. Now that is not a very big number by itself but it does become an irritant when we run tests on our developer boxes multiple times a day before we push our commits to git. On a given day, a developer could have spent 15-30 minutes waiting for the tests to run and the build to finish. So how could we spped up this process?
It turns out that NUnit-3 test engine has the ability to run tests in parallel. We hoped that it would reduce our test execution time. In addition, we looked at how Rake Multitask could help us reduce our overall build times. Read on to see what happened…
At Trainline our development teams have moved on a lot from what we were doing a while back to what and how we are doing things today. Here are just a few of the things that have completely changed in just the last couple of years: moving to continuous delivery, massive increase in automation testing, new infrastructure, green-blue deployments, load balancing, alerting and monitoring.
What has taken my interest in the last year is the extent of the monitoring that we have available now and how we need to choose what to look at and what not to. Continue reading
At Trainline we embarked on an ambitious cloud migration journey to AWS around a year ago and as part of this we’ve adopted AWS CodeDeploy as our deployment management mechanism.
I recently presented at the DevOps Exchange Meetup in London on this topic. I discussed where we’re up to with a focus on some interesting challenges we’ve faced getting CodeDeploy to play nicely with our hosting model.
Here are the slides from my talk: Continue reading
One of the biggest problems with a lengthy release cycle for a software system is that you build up an inventory of changes which, if released more quickly, could have yielded some return on investment sooner. By introducing a continuous delivery process which allows teams to release changes as soon as they’re ready there is potential for ROI benefits but also some other, less tangible, benefits.
Later this week, we’re excited to be hosting the second New Relic meet-up at our London offices, and we’ve been given the opportunity to talk about our experiences using their products. For those that don’t know, New Relic is a suite of monitoring products that we’ve been using to get near real-time monitoring of end-user, application and server performance, and we’ve been using it across our entire stack of products and services for more than a year.
This post is part 3 in a series. Read part 1 and part 2.
Part 2 finished detailing our relatively recent move to Product teams, a change that has had a big impact on our delivery process.
While this is definitely an exciting change, with product teams having a lot more responsibility from development to live, it highlights the fact that Development and Test environments have some needs that are similar to the Live environment, but also differences that must be clearly understood and supported, potentially in a different way to the Live environment:
This post is part 2 in a series. Read part 1.
thetrainline’s Journey in Improving Throughput
From a very early point in thetrainline’s journey it was clear that the web site was only the tip of the iceberg and that there would need to be a continued programme of development to: improve customer experience; adapt as web technology evolved; and as more automation was implemented in back office processing from initially fulfilment to most recently refunds. In the past 14 years rail travel has doubled in size and the customer’s expectations have also risen. Although journey planning and advanced purchase ticketing are well planned and carried out in advance the immediate future will see more innovation in ticketing from smart cards supporting multiple train operators to NFC payment and potentially ticketing. In order to be able to provide the required levels of service at the relevant price for the product and across all channels and devices thetrainline will need to continue to improve the throughput of ideas through to production implementation.
DevOps is a part of the natural evolution of Agile Development and Continuous Delivery. Where quick feedback from the use of a system by its users in the production environment helps to drive the next phase of the product; maintain or improve the rate of change and the total cost of ownership. But the fundamental principles of DevOps are not new. Developers have been seeking an understanding of how their code behaves from the first line of code written. This post summarises the DevOps journey at thetrainline.com and how Operations have embraced the principles of DevOps with the goal of achieving Continuous Delivery. DevOps is a key part of the answer to improving product throughput BUT it is a small part. This post details my 12 year journey with thetrainline.com but, more importantly, the wider need for Developers to learn from others involved in a product’s life-cycle, both from a historical view point as well as the capabilities available today. For the continued growth of a business the tools and processes required to reduce the time taken for feedback from live use of a product are essential to both a start-up and an enterprise. Continue reading
At thetrainline.com we are always striving to deliver the best user experience for our customers. We want to get great ideas from conception to the customer as quickly as possible, to enhance our offerings and streamline our processes. This post talks about how we helped achieve this by harnessing Continuous Delivery.
Following on from the post (Moving to Multiple Deployments Per Week at thetrainline.com) that Matt Richardson and I published in December 2013 we have since evolved our deployments to allow us to achieve automated continuous delivery of our components from development through to production – with zero downtime.
Here at thetrainline.com we have several useful online tools for helping our customers plan and manage their train travel, including Train Times and Live Departure Boards. We recently changed the way we build, test, and deploy these kinds of applications to enable us to release new features much more frequently and easily; in fact, we shortened the deployment cycle from one deployment every few months to multiple deployments per week. These changes have produced a sea change in team culture, with a marked increase in product ownership by the team. This post describes what we’ve done so far, and where we want to go over the coming months.