Patch

Patch Note (otherwise known as Client Version, Patch are the set of information in which a patch is delivered.

A quick introduction: my name is Udyr and I’m an Associate Producer for League of Legends. My primary role is acting as the Release Manager for all of the patches that we release. You can catch me on the Release Notes threads, in the Server Status and Test Realm forums, and around General Discussion from time to time.

Given our breakneck cadence for releasing new patches, I wanted to explain how we decide what goes out in a given patch. Before I get into how everything comes together, here is a general breakdown of what a patch will contain:

Balance Changes: Bi-weekly changes to even out the power balance between Champions

League of Legends and PVP.net features: Anything new that you will experience on PVP.net or in the game

New content: New or remade Champions, Items, or Skins

Bug Fixes: Both from the forums and internally

Backend/development changes: Technology or configuration changes that go on behind the scenes

Now that we’ve established what a patch usually consists of, let’s get down to how everything comes together.

As soon as a new patch goes out, I begin forming the structure of the next patch. We have a ton of different teams working on a variety of different features, some of which that have been in development for weeks or even months. In order to know what we can push out in a patch, I need to know which features are finished being developed and are ready to be released. I talk to all of the producers and understand what is ready, so I can create a set of mock release notes that represents the patch.

Every day throughout the next two weeks, all of the producers and relevant contributors get together early in the morning to talk through all of the items that we want to push out in the next patch. It’s about 15 minutes each day to get status updates about the progress that the teams have been making, as well as to talking through any changes that don’t appear to be ready. Although new features and content have usually been in development for a while, new bugs can arise that prevent them from being released. QA also participates in this daily meeting to give updates about what features and content has been verified and any bug fixes that are important to track.

After the meeting, we move into our company playtest off the daily 9am build. Everyone in the company participates and plays the game, focusing on the new changes that we are pushing out in the patch. We’ll run several simultaneous games, and then break out into groups to gather feedback and bugs. After I have the compiled feedback, I’ll go though and figure out which bugs need to be fixed or need further investigation. Bugs in the code will go to an engineer like Lima Beans or hohums while a new Champion bug would get passed to Coronach, Brackhar, Ezreal, or whichever designer is making that particular Champion. In addition to making sure that all of the bugs have someone designated to work on them, I work with the various producers to make sure that their features and changes are on track. For example, I might work with RiotJeffJew (the Content producer) to understand the status of the new Champions and figure out when any missing sounds or icons will be ready, or I might talk to Volibar about what remaining bug fixes from the forums we will be able to get in.

After the patch has gone through the internal playtesting and fixing cycle for a week, we push it to the Test Realm to expose it to a group of external users for supplementary feedback and testing. The feedback and bugs from the Test Realm are then fed into the daily fixing cycle to continue to rapid iteration. We update the Test Realm a few more times with the newest builds to get as much outside exposure as possible before release.

The Friday night before we plan to push out a patch is considered the cutoff date for any last minute changes. We do this to make sure that QA can verify all of the content against the running list of changes that we have made and to prevent any bugs from getting injected at the last minute. At this point, most, if not all, of the bugs have been squashed, all the content and features are ready, and we’ve made all of the balance changes we were able to complete within the patch window.

Over the course of the 2 weeks leading up to the patch, release notes are written by each team to describe the different features we are pushing out. These release notes are all compiled by me and then passed to QA to verify that the notes match what is actually in the patch.

After the patch is ready, and the release notes have been compiled, we schedule an internal deployment meeting. This includes representatives from Operations, Production, Engineering, QA, and anyone else who has a role in deploying a patch. We discuss and plan the different pieces of the downtime, deployment, and testing. This allows us to make a time estimate based on the total amount of work we need to do, which then determines the maintenance window. Once we have an estimated downtime, we compare that to our concurrency history to determine the optimal time for downtime so that it affects the smallest number of users.

At this point, we are ready to publish the downtime, post the release notes, start the maintenance, and release the patch into the wild!