Since my talk at AWS re:Invent in December, we’ve had a lot of questions about how we tackled our Oracle Exadata migration to AWS.
This post goes through our Oracle migration journey in more detail and also includes some general tips for moving large databases to the Cloud. Continue reading
From Change Control to Assumed Approval: how we first managed the operational visibility of Continuous Delivery and how it’s still in use 2 years later
Trainline has changed in many ways over the last 2½ years and, as a 4-year veteran, I have been ideally placed to watch and help enable that change. One of the big changes was from a project-led to a product-led organisation. Along with that comes lots of things, one of which is Continuous Delivery (CD). The advantages of this are well known, and one excellent stat was recently produced that showed that we have achieved a:
122-fold improvement in deployment agility!
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…
Trainline is Europe’s leading independent Rail ticket retailer, selling £2.3bn tickets per year and enabling our customers to make more than 100,000 smarter journeys every day. We have 150 development staff who are constantly improving our user experiences, and our need to innovate means that we cannot allow the underlying infrastructure to be a constraint on time to market.
This desire for infrastructure agility recently led us to migrate 100% of our Development, Staging, UAT and Production environments from legacy private data-centre to Amazon’s public Cloud. Simply lifting and shifting components into the Cloud would have improved agility somewhat, but for us this was just the starting point. Continue reading
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
Whenever I read about DevOps (which admittedly should be more but my job keeps me challenged in the office and my kids keep me challenged at home, so when I get downtime I prefer to switch off) it’s pretty much always by those from a Development background – we all know that the DevOps movement has its roots in Development, but how rewarding can it be for the Operations guys? (hint: very) 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
During the planning stages of our migration to AWS, we identified the need to create custom images (AMI’s) as the base for new instances. While we are relatively experienced with Chef, we found that running Chef at instance launch time was much longer than acceptable. Creating custom AMI’s that are preconfigured (known as baking) allowed us to shift the heavy lifting from instance launch time to an earlier, out-of-band time.
In designing this process, we came up with multiple goals – we needed to have a reliable, repeatable, auditable and tested process with a fast spin-up time. This post explores our recent infrastructure automation efforts in this area.
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.
For several years, much of the code for the systems at thetrainline.com has been versioned and deployed together as a single ‘platform’. Recently, we have begun to divide up the platform into smaller chunks, to enable us to deliver some parts more frequently and rapidly, leaving other parts to evolve more slowly (as needed). Moving from a single version number for all subsystems to multiple version numbers for independent subsystems has implications for how code is built and released; this blog post outlines some of the work we have done so far in this area.
My colleague Owain Perry and I recently presented on this topic at the London Continuous Delivery meetup group (http://londoncd.org.uk/) and the slides we showed relate to the details in this post: