Build it👷 and Ship it 🚢 in 1 day [Version 2.0]
If at first you don’t succeed, call it version 1.0 and try again.
Last time I wrote an article here, it was all about a Vodafone team attempting to build and release to production in the same day. You can read the full article here: https://medium.com/vodafone-uk-engineering/build-it-ship-it-in-1-day-40e4f309c052
If you haven’t read it, then, [Spoilers] it wasn’t a complete success, but we had a good go at it and learnt a lot.
Now we’re back, with a new epic adventure of a Vodafone team daring again to realise that dream.
What is In a day 📅?
This is where a team plans to get together and deliver a set of work within 1 day. There should be a specific goal to the day, something big/cool/amazing which the team can feel proud of delivering. It can be ambitious, but needs to be achievable 🏆.
The work needs to be well understood before-hand and well broken down to make it easy to progress through the work.
Then it’s a case of getting a suitable room, having some music 🎵 and plenty of food 🍪.
The New Challenge
A lot has changed since the last attempt I was involved in. We’ve made progress towards our continuous delivery goal 🥅, but we’re not there yet. I’m also involved with a backend Java team now called Galaxy, so the work is a bit different this time around.
Importantly, we’re also not repeating ourselves; we have a new big goal this time. Our ambition is to fully automate 🤖 the testing of our services, thus being ready for continuous delivery of our work.
The moment we’re ready with an update, we want to be able to put it in a test environment, and to have it immediately, fully, and reliably tested to ensure our changes are good before going to production.
We took a good look at our services, and chose one which we felt was a good candidate for full test automation. We also had a suitable, small business requirement which we could plan to release straight to production. This was just to change the ordering of a list of products, and so the change would filter through to the frontend without any need for another team.
The perfect candidate for our second attempt
Let’s get to it
We broke down the work required to fully automate the testing on the required service, and soon found there was quite a bit to do. But we were able to pick out the key areas to test for the business change. We got these completed within 2 sprints and planned our delivery for the end of the second.
We would make the change in the morning 🌅 and release to production in the afternoon.
Unfortunately, due to an important big release being delayed, we had to put off our release. However, we accepted this delay as long as our plan still offered the quickest route to production.
Eventually, just before the Black Friday change freeze, we got our opportunity to proceed.
The day starts, we have the room, we have the developers, the automated tests are written, we have a single user story to deliver and… of course a plentiful supply of ̶h̶e̶a̶l̶t̶h̶y̶,̶ ̶n̶u̶t̶r̶i̶t̶i̶o̶u̶s̶,̶ ̶b̶r̶a̶i̶n̶ ̶p̶o̶w̶e̶r̶i̶n̶g̶ ̶f̶o̶o̶d̶ biscuits.
New catalogue loaded in environments
First step for us was to ensure the catalogue with the latest data was loaded in all the environments. We requested this from the appropriate team who jumped on it and we soon had everything the same as production.
A simple step which we thought was all sorted, but when are simple things ever so easy!!!
Mobbing it
The team used the mob programming technique to complete the work, ensuring the standard was good. They made sure new automated tests were in place for the new work.
We were looking good ✅
The work was pretty much the easy part this time.
Next, we needed to release through the test environments. There was another release going out just before us, but we were soon clear to go ahead. As well as our automated tests, we did thorough manual testing to ensure our automated tests were doing their job correctly.
All was going well and then… DISASTER!!! 🔥 One of our automated tests failed in the Pre-Production environment.
What had gone wrong? Well, we quickly realised that the release which had gone out just before us had changed the catalogue slightly and one piece of data behind a test was no longer correct. 😞 Doh!
We knew this could be a problem but had used recent, popular products in the hope of keeping the data valid for longer.
A quick adjustment and we were quickly working our way through the environments again.
Approaching 5pm 🕔, we made it into Production.
SUCCESS!!! 🎉
Everything was working great, and we had now proved our ability to automate the testing of our service.
But what to do about the failing automated test? 🤔
We have worked out a solution and have now planned a piece of work to auto generate the test data every time a new catalogue is loaded. This will be a bit of an ongoing experiment, so we’ll have to see how it works out.
A different approach
This time around the focus was very much on testing the release process, and the work to be done was quite small. Therefore, the work was done as a mob session and then we all worked through the release.
My thoughts on this, having done the 2 different styles, the mob wasn’t so effective nor enjoyable. It was like any other single mob session, and lost the special feeling of all being a piece of really driving forward to achieving the goals. Maybe it would have worked for part of the day, but not the whole thing.
This was possibly also affected by the small amount of work planned. It was easily achievable in a day, whereas in the last one, we’d planned loads more, but ultimately didn’t achieve the release to production.
Now that we’ve well and truly cracked the quick release to production, I would want to focus more on the excitement of trying to achieve big ambitions work wise, and allow the release to slip to the following day if it has to. There are so many factors outside the team which affect the ability to release to production, which makes it more of a tedious process, rather than an exciting team challenge.
What’s next?
We will release every one of our features ourselves, with full automated testing!
