Patch Creation and Publishing Schedules

The steps that should go into the publishing process can be outlined as follows :

1. Creation of a live production plan. The plan should include the following:

   • Bug list: Bugs detected and to be fixed

   • Balance issues: Fixing out-of-balance regions , items, and classes

   • New features: Interface capabilities, bells , and whistles

   • New content: New mechanics, dungeons, skills, crafts, and so on

   • New tools: To assist members of the live team

   • Tentative schedule of patches by date

     • Regular schedules for fixes

     • Regular schedules for new content

2. Development and documentation of changes. This phase should include the following:

   • Version control of changes and additions to the code

   • Change control process (CCP) documentation of changes

   • Commenting of new code, recommending of changed code

3. QA plan. This includes the following:

   • CCP vetting of new content and features

   • Internal test server implementation

   • Live test server implementation

   • Fix problems found in testing and retest

4. Publishing the patch: Patch day! Substeps include the following:

   • QA sign-off

   • Producer sign-off

   • Authorization to initiate a publish

   • Emergency patch procedures

Step 1 is the planning and design stage: when the fixes and new content are planned, prioritized, and scheduled for publishing. It is important to note that this document will change frequently as problems are fixed, new concepts and content are planned, and previously planned content and features are created, tested , patched to the game, and removed from the schedule. There is also some tentative scheduling of when the game patches will be published and what will be in each patch.

NOTE

It is recommended that you schedule "fix" patches separate from new content and feature addition patches. Mixing them can be convenient , but imagine what would happen if a "fix" isn't really fixed or causes unanticipated problems and has to be rolled back to an earlier version? If the new content is critical to the ongoing storyline or is highly anticipated by the subscribers (as it almost always is), being forced to revert to former versions will cause a major hoo-rah, guaranteed .

Step 2 is the development phase, when the changes and additions are developed and documented.

Step 3 is the testing process, controlled by QA. QA should perform initial tests in-house on a closed server, perhaps assisted by a small crew (2550) of trusted outside testers. Once problems detected in this testing have been fixed and retested, the changes can be placed on a live test server, with open access to the subscribers. The process should be fairly rote from that point: find the bug, fix the bug, retest to make sure the bug is really fixed, repeat until finished.

Step 4 is the actual publishing of the patch to the live player servers. Once QA and the producer have signed off on a patch, authorization is given to initiate the "publish" according to the schedule.

Occasionally, nasty problems with the code will develop out of nowhere and require an emergency fix to stabilize the game or eliminate a particularly nasty bug. Following the dictates of The Law of the General Perversity of the Universe, an emergency will usually happen at 3 a.m. on the Saturday morning of a four-day holiday weekend . If an emergency patch is needed, there should be an authorization process documented, even if it is just a panicked junior engineer calling the producer for permission to make a quick fix and reboot the servers.