From Reddit all credit goes to pjmara5.
"1) Bug is found by the Development team or the community.
2) Production and Community Management work with QA to reproduce the bug. Engineering adds tools into the build that help determine the main cause of the bug.
3) With the bug fully tracked down (reproduced and root cause is found), Production teams up with Engineering (and possibly design depending on the issue) to come up with a list of potential solutions.
Solutions are graded based on risk.. Which is very important because the last thing you want to do is break more things.
4) Engineering and design create fixes that they test locally. (on their work computers)
This is to make sure that obvious issues are immediately found before QA does deeper testing.
5) With a potential fix in place, Production OKs the creation of a build containing the fix. This build is given to the QC/QA team for testing.
Engineering/Design sends change notes and details to Production.. Which is then forwarded to QC/QA in an effort to help them strategize how to test the fix.
6) QC/QA receives the build and starts creating a plan.
TRG group assesses the fix for potential violation(s) of any TRCs and runs tests to ensure that all checklist requirements are met. This process takes a while as a diligent team runs the ENTIRE checklist to make sure that nothing is overlooked. A Single Failure of a compliance requirement usually results in rejection at 1st party submission. More on this later.
Functional team starts executing a test plan to ensure that the fix correctly addresses the issue at hand. Halo testers start enumerating and testing aspects of the game that may be affected by the fix. (e.g. Specific fix for Suros Regime’s rate of fire. Halo testers look at other auto rifles within the same family to ensure that none of them were negatively affected by the fix. Tests are also done to ensure that none of the Suros Regime’s other features were affected.)
This process takes time as everyone ALWAYS aims to be thorough and get the Patch approved upon initial submission.
6A) Production and Engineering teams discuss other issues and determine other fixes that can potentially be included in the patch.
This discussion may likely occur earlier (and quite often to be honest).
There’s 2 key goals here.
Make sure the other fixes to create more issues.
Make sure that the collection of fixes create a file size that is acceptable to 1st Party.
7) With Fixes and potential features fully tested, a Release Candidate Build is created and sent to QC/QA for Final Release testing.
One Final full pass on checklists and testing is done to ensure that this version is fit to be sent out for approval.
Engineers make sure that this build has configurations that emulate the environment that end users will experience when the patch launches. In simple terms, it’s making sure we’re like testing the game on the console we have at home.. Not some development kit or special computer.
NOTE : If the fix results is new bugs, either :
A) Dev team abandons the fix and works on a new one
or
B) New bugs are fixed and sent to QA for testing)
8) QC/QA Signs off on the build as READY TO GO. Production contacts 1st Party and fills in the paper work for a Submission. The Release Candidate build is uploaded to 1st Party servers.
9) 1st Party receives the Submission and does the following.
Makes sure paperwork is in order and correctly filled up.
Makes sure the build is downloadable and testable.
Gives Production an estimate of when the approval process would start and a tentative end date for when a verdict of PASS or FAIL will be given. This… could take up to a full week or a week and a half. (Mostly due to the fact that 1st party deals with EVERYBODY who submits games/patches/DLC for approval)
Think of it like getting a ticket at the deli line and waiting for your number to be called before you can get your order fully processed.
10) 1st Party provides a “Verdict”.
FAIL - The whole process starts again. :( The reasons for failure are given.. And the team needs to address all issues before re-submitting a Release Candidate. You lose your place in the Queue.. So yeah.. You start from the end of the submission line.
PASS - An private server version of the patch is provided by 1st Party so the Development team can simulate the act of Downloading the Patch to a console and playing the game. QC/QA is heavily involved in this process as they do yet another testing pass on this version to make sure end users experience it as intended. Production and Community Management start to engage with the community at this point to give some sort of estimate as to when the patch will release.
11) QC/QA Signs off on the private server version and Production gives the go ahead to deploy the patch. Production and Community Management finalize the release date and inform the community.
12) We get the patch on the day of release.
13) Community finds new issues.. AND THE WHOLE PROCESS STARTS AGAIN.
So as you can see, the process is quite arduous and lengthy. No game in history has shipped without bugs and often times, Producers are forced by Stakeholders (People who supply the development budget) to meet stringent deadlines for marketing and financial reasons. This results in a lot of known bugs being shipped with the game. It’s an unfortunate yet unsurprising process as it would take an absurd number of years to fix every single bug.. An endeavor that’s honestly unrealistic.
So what else do I hope impart on my fellow guardians aside from all that I’ve written? Well, it’s a plea to do a couple things.
Submissions cost THOUSANDS of dollars. We may have the tendency to say "Hey but these big companies have GIGANTIC budgets", but at the end of the day cost is cost.. and Finance teams allocate a specific amount to project maintenance. Producers usually handle this budget with care so they TRY to facilitate the release of patches that address multiple issues as much as possible to save on submission costs.
Don’t stop being vocal about issues that plague the game, but take time to offer a suggestion for how you would deal with the problem. Development usually determines the solution from a pool of potential fixes that they’ve put together internally, but that doesn’t mean they value suggestions from the community. After all, a big part of their motivation is to make your experience as pleasant and memorable as possible.
When an issue occurs, take time to “raise your hand” and honestly acknowledge when you’ve been affected, especially issues relating to Griefing/Cheating or your game Crashing. (and other bugs in general of course) Companies like Bungie have advanced analytics and teams that monitor the game 24/7 so reporting a cheater, someone for bad connection or contributing details to a forum post all enable them to ultimately help our community. TLDR : Helping them, helps us as a community)
Spread the knowledge around. If you see someone getting upset about issues and calling Bungie out for being idle or taking too long, refer them to this thread. The hope is that they learn about the process.. And who knows, maybe it helps them in a future career.. Or give more productive feedback in the short term.
Thanks for taking time read this lengthy post. I hope you learned something.
[b]TLDR: Making games takes times. Patching/Hotfixing games is an elaborate process that is a collaboration between multiple Groups within a Development Team + the Console Manufacturer.[/b] "
-
It doesn't come down to the process of patching. That's not the issue. The issue is the engine their using. Called, "tiger" if I remember right. Or maybe that was the engine used for Halo. Can't remember exactly. In a conference, they admitted that their engine is borderline too complicated or much more complicated than they had expected.