Begin with the end in mind: one team’s journey towards Continuous Integration
The eagle-eyed and well-read among you may recognise this title. It’s from a very successful book, ‘The 7 Habits of Highly Effective People’ by Stephen R. Covey, a self-help book in which Covey details seven habits that you can start exhibiting in order to make you effective in achieving your goals. I read the book about a year or so ago, and have read it again since, and it’s definitely helped make me more effective.
Anyway, this is the first in a series of blog posts that will detail how you can use this ‘habit’ in order to help deliver success. It will look at one team’s journey towards Continuous Integration (CI) and the troubles we encountered along the way. How keeping the ‘end in mind’ helped ensure that we stayed on track and reached our goals.
I actually delivered this series of blog posts as a talk at the Belgrade Test Conference. I thought I’d break it down for those unable to make it.
What does it mean?
I like doing jigsaw puzzles. My wife and I do jigsaw puzzles a fair bit, she’s far better than me, she can pick up a piece and knows instinctively where it goes… If, however, you’re like me, then you’re the type of person who picks up a piece of a puzzle, checks the box for the photo of the completed puzzle, and tries to fit in where you think it goes, based on the photo. Now imagine, if you didn’t have the box to help, or to guide you. The puzzle becomes infinitely more difficult. In fact, I was doing a puzzle the other week where we had no finished photo to look at, and it took a lot longer to complete.
On a similar note, I wasn’t much of a runner last year — I ran every now and then, about three miles, but I ran in my normal trainers (rookie mistake!). At the start of this year, as a New Year’s resolution, I decided that I would try to run 500 miles over the course of the year. This averaged about 10 miles a week, so, in my eyes, it was definitely achievable. I set out with a goal of what I wanted to accomplish, and this kept me on track. It kept me motivated when it was snowing and I was out running or when I was hungover and I was out running. I managed to achieve this by end of September. A target can help maintain momentum and focus.
This is what ‘Begin with the End in mind’ is all about. It’s about identifying what it is you want to achieve before you start anything. Where do you want to get to? What do you want out of it?
How does this apply to software development?
Over this series of blog posts, it will hopefully become clear how it applies. Before we go any further, let me talk a little bit about my role.
I am lucky as in my role I work outside and across multiple teams, which gives me a unique insight. I liken each team to living in a house. It may be a lovely house inside, wallpaper, mod-cons the whole shebang. They’re thinking they’ve got it good! They’re doing great stuff.
Now I’m sat outside walking down the street, I look at their house and it’s falling down. It’s looking worse for wear. Sometimes teams can be so inward focused. They are so intent on delivering software that sometimes the fundamentals can fall by the wayside. Sitting outside the team I can offer them an insight that perhaps can be difficult to come by from within the team.
About the team
The team themselves actually consist of four smaller sub teams — together they make up what we call the Content Platform Team. They look after some of the most requested pages on the ASOS site (homepage, banners etc.) They do a lot of work on an off-the-shelf Content Management System (CMS) called Sitecore. It’s a powerful tool and allows teams to build on top of the Sitecore foundation to add in customisation's based on customer requirements. When I talk about customers, they have two types of customers:
- Content Authors — These are people using the CMS system on a daily basis to create content that they feel the ASOS customer wants to see and interact with.
- ASOS Customers — These are the people using the ASOS website to buy clothing.
All of the four teams were working in an Agile way. This involves working in short sprints and breaking down stories into small tasks that the team can pick up and work on, and hopefully release. They were working on individual packages that will be deployed along with the Sitecore code, to allow it to have the customisation’s that were required.
How it was
As mentioned, the teams were all working in an Agile way. They released about once a month, but release cadence wasn't set in stone. Four days before it was time to release, all the teams’ individual packages would be deployed (along with Sitecore code) to an integration environment. The teams had a suite of automated checks that would run against the deployed application to check that functionality was working as expected.
This was the first time that all the integrated code would be deployed to an environment. It was the first time that the automated checks were run against the integrated code. It was also the first time that it would be deployed in the same manner that it was deployed to production, using TeamCity and Octopus Deploy.
This was all happening, just four days before a release. There were a number of things that could go wrong, and more often than not, they did. For example, we had:
- Failing automated checks
- Ignored/muted automated checks
- Failed deployments with a lot of manual intervention
- Rollbacks
This couldn’t go on for much longer. Things weren’t improving, and something needed to change.
What happened?
We realised that working in this way was not sustainable. People were working hard to get software out the door. It required so much effort that people got tired and mistakes could easily be made. A group of us got together — Software Engineers, Testers and Agile Delivery Managers and looked at the problem. We had a number of solutions, but ultimately it boiled down to one thing:
We wanted confidence in the following:
- 1. Automated checks — We wanted confidence that when our automated checks ran, any failures were genuine failures. Any failures would be investigated and the solution identified and implemented.
- 2. Integrated code — We wanted confidence that our integrated code was in a known state before we did any testing on it. We wanted this sooner than four days before a release.
- 3. Deployments — We wanted confidence that a deployment to any environment was repeatable, robust and rapid.
- 4. Software — By achieving the above, we could have a level of confidence in our software that meant it was in a known state at any given time.
So we knew what we wanted. Confidence. Over the next few blog posts I’ll explore how we achieved confidence in each of the areas, as well as looking at the future and what else we’ll be striving for.
About me
My name is Gareth Waterhouse and I’ve been at ASOS for over eight years. It’s been amazing seeing the company grow and I love helping the people that I work with reach their goals. If you ever fancy a discussion about testing, then get in touch on Twitter.
I’m a keen gamer, enjoy spending time with my family, and enjoy running and sports. I’m a season ticket holder at Sunderland, but the less said about that the better.
