In the second part of this series on configuration and change management in the TfL hybrid Agile, DevOps & ITIL world, I’ll take a look at infrastructure as code and the CMDB.
Infrastructure as code – CloudFormation script for a virtual TfL server in the cloud
As expected, we saw very significant demand for digital services during this morning’s disruption as torrential rain and signal failures affected a number of Tube and Rail lines.
TfL website traffic during the June 23 morning peak, showing a significant increase on yesterday, and the same time last week
We have successfully adopted and transitioned into DevOps, Agile and continuous integration with weekly deployments of code, new features and functionality to the TfL website. This is the first in a series of posts looking at how we manage these processes behind the scenes.
Change, release, configuration & service transition is moving from gatekeeping to devolved, trusted & collaborative safe continuous delivery
If you still use our old countdown websites to check on live bus arrivals, you’ll notice a change from June 1 as you’ll be redirected to the main TfL website instead.
Many of you may have already seen the message about this change, which confirmed that the following websites will no longer be available from June 1:
http://accessible.countdown.tfl.gov.uk
Instead, you’ll be able to check for live bus information on the TfL home page, using the new favourites feature to get live arrivals for your stops.
Save your favourite bus stops in the 4 steps shown here: 1) Find a bus stop 2) Add it to your favourites 3) Select bus routes 4) Get live arrivals
When you visit our website, you’ll notice a star in the top right corner of the screen. Just click on it to enter a new space for your favourites on the website.
Save bus stop in the 4 steps shown here: 1) Find a bus stop 2) Add it to your favourites 3) Select bus routes 4) Get live arrivals
Once upon a time, back in 2012, the TfL website was visited by around 16 million users on a monthly basis and our customer satisfaction surveys would generally always show that our users were happy with the site.
It was also in 2012 that we decided to redesign our website. Many of my own friends would ask why we were doing that, since the website was really good the way it was. Yes, the website was doing its job, but it was time for us to change. But the question remains: Why?
As Phil Young, Head of TfL Online, stated in this post from June 2013, where he announced that TfL’s new website was coming soon,“you’ve told us our site needs to be great on all devices.”
With that in mind, we launched the beta version of our shiny new mobile-friendly website back in 2013.
Around two years later in February 2015, Google announced the following:
“Starting April 21, we will be expanding our use of mobile-friendliness as a ranking signal. This change will affect mobile searches in all languages worldwide and will have a significant impact in our search results. Consequently, users will find it easier to get relevant, high quality search results that are optimized for their devices.”
So, is the TfL website mobile friendly? As shown in the screen shot below, Google say it is, and you can test the TfL website and more pages at https://www.google.com/webmasters/tools/mobile-friendly/
We were determined to make the TfL website great across all devices, and it passes Google’s Mobile-Friendly Test
In my previous post on Roads Open Data I outlined the importance of providing quality data for London’s roads, particularly at a time when our Road Modernisation Plan is being implemented and we are urging drivers to check for disruption before they travel.
We continue to make improvements to our roads open data, with London Underground live car parking spaces availability now available through the Unified API, as well as live video JamCams that give a far better indication of how traffic is flowing in the Capital.
London Underground has over 60 car parks with over 11,000 spaces. With the help of our partners NCP and SmartParking, we have released live data showing available spaces for 25 of these car parks. We are seeing whether we can expand the feed to cover all London Underground car parks in the future.
We don’t have this showing on tfl.gov.uk yet, but we’ve made the feed available as open data in the Unified API so that the dev community can have a head start.
You can get the full list of Car Parks from the Places API, which can also be searched by lat/long bounding box or radius. For each car park, we return information such as the address, opening hours, payment methods and facilities, and in some cases, the live occupancy. In the example below, Barkingside Station car park, the OccupancyUrl is returned, indicating that live data is available.
{
"id": "CarParks_800491",
"url": "https://api.tfl.gov.uk/Place/CarParks_800491",
"commonName": "Barkingside Stn (LUL)",
"placeType": "CarPark",
"additionalProperties": [
{
"category": "Description",
"key": "NumberOfSpaces",
"sourceSystemKey": "CarParks",
"value": "46",
"modified": "2016-01-07T15:45:43.153"
},
{
"category": "Description",
"key": "NumberOfDisabledBays",
"sourceSystemKey": "CarParks",
"value": "2",
"modified": "2016-01-07T15:45:43.153"
},
{
"category": "Meta",
"key": "OccupancyUrl",
"sourceSystemKey": "CarParks",
"value": "https://api.tfl.gov.uk/Occupancy/CarPark/CarParks_800491",
"modified": "2016-01-07T15:45:43.153"
}...
The URL is based on the place id of the car park, for example “CarParks_800491” so if you know the Car Park id, you can go straight to the occupancy data. We use a separate URL because we have a much shorter time-to-live in our cache for the occupancy vs. the place data (60 seconds and 1 day respectively). In the example below, using Barkingside again, we can see that there’s no spaces available right now.
{
"id": "CarParks_800491",
"bays": [
{
"bayType": "Disabled",
"bayCount": 2,
"free": 0,
"occupied": 2
},
{
"bayType": "Pay and Display Parking",
"bayCount": 45,
"free": 0,
"occupied": 45
}
],
"name": "Barkingside Stn (LUL)",
"carParkDetailsUrl": "https://api.tfl.gov.uk/Place/CarParks_800491"
}
I get the honour of the final blog post of 2015, and it’s a pleasing one to be able to write as we look back on what the team in TfL Online have achieved during this year.
We started off the year accomplishing one deployment of new code to the website every two weeks, and that’s increased to the point where we’ve now managed our 57th release to the site in 2015. There are a lot of variables and moving parts that we monitor and co-ordinate simultaneously to deliver a safe, quality assured, zero defect, zero outage deployment to the website every single week.
For more detail, see my posts on Blue/Green deployments and Agile continuous delivery in the cloud (in 3 parts).
While we’ve successfully made these 57 separate releases of code, optimisations, reference data refresh, bug fixes, enhancements and new features to tfl.gov.uk, we’ve managed to do all this seamlessly without a single planned maintenance window, so our customers haven’t experienced any down-time at all while we’ve been making these improvements.
So, here’s how we believe we’ve fed into the ‘Every Journey Matters’ ethos:
It matters that you have access to new features and enhancements on the website quickly – WebCAT, Roads VMS, Unified API, Live Bus Arrivals, Integration of TfL Rail & West Anglia, to name but a few
In Part 3 of this series, I gave examples of finding the ‘Routes of Things’ using the Unified API. This post will focus on roads – how to find and make use of the traffic, road disruption and planned works information on London’s road network.
We’re really keen for customers to check for disruption before they travel on all forms of transport, including the capital’s roads. Developers working with our Unified API have a really important role to play in developing products that meet road users’ needs. This is particularly important as we implement our Road Modernisation Plan – £4bn of investment in improving London’s roads – so planning ahead during these works is crucial for businesses and drivers across the city.
This means that the apps developers create will be meeting a genuine need, and we’re keen to make this process as easy as possible by explaining what data is available, how it can be used, and by taking feedback so we can make improvements.
All of the API examples in this page are live, however they do not include API authentication tokens. This means that if you follow the link as is, you will be using anonymous access, which is throttled for fair use, so you may get a 403 response. It is recommended for your own development you obtain an ‘app_key’ and ‘app_id’ by registering here. The data in these examples will be in JSON format, so installing a JSON formatter plugin in your browser will help you read the data returned.
Let’s start with the most prominent example of the roads information, shown when viewing the Traffic status board.
The Traffic Status Board gives info on all TfL managed routes on the London road network
In Part 2 of this series, Dan gave examples of finding the “Locations of Things” using the Unified API. This week, I’ll focus on the “Routes of Things” – the lines, routes and services that join up the locations on the TfL network.
As before, all of the API examples in this page are live, however they do not include API authentication tokens. This means that if you follow the link as is, you will be using anonymous access, which is throttled for fair use, so you may get a 403 response. It is recommended for your own development you obtain an “app_key” and “app_id” by registering here. The data in these examples will be in JSON format, so installing a JSON formatter plugin in your browser will help you read the data returned.
Let’s begin with the most prominent use of routes on the website – the status board. In the Unified API a line is the top-level entity which groups the routes of a service together. The Line endpoint allows us to request all of the lines for a given set of modes, so is a useful starting point for navigating into the available routes. Showing the status of a line is such a common use case that the endpoint also includes an option to include the service status for each line by appending /Status to the URL:
https://api.tfl.gov.uk/Line/Mode/tube,dlr,overground,tflrail/Status
The status board requests the Tube, DLR, Overground and TfL Rail line status. A line can represent multiple routes around the TfL network.
