Patching Processes
The ONE Game Hosting platform has a patching mechanism that makes it easy for you to update builds for already running application instances. You can perform updates in different ways, using different patching methods. Each method has a different purpose and performs different actions. To learn more about each patching method, choose one of the following:
When creating a new Patch Job, you can choose one of these methods and make a selection of which application instances to update. You can run the Patch Job right away, or schedule it to run at a later time. Reporting emails will be sent to any email addresses you submit inside the Patch Job. Reporting will start as soon as the Patch Job begins giving you an overview of which instances will be affected. During the patching process itself we keep sending report emails to show you the patching progress. When all is done, a final report will be sent. More details about the different patching method and all the Patch Job settings can be found in this and the following chapters.
There is a different procedure for patching utilities. For more information, see the Utility Patching Process documentation.
Patch Job Instance Selection
A Patch Job is always applied to a certain selection of application instances (game servers only). To make a selection, you must configure a number of options when creating a Patch Job:
Option | Description |
---|---|
DeploymentEnvironment | The DeploymentEnvironment within which you want to perform a build update |
Application | The Application that you want to patch |
ApplicationBuild | The currently running ApplicationBuild you want to replace with a new build |
Fleet(s) | One or more Fleet elements within which we look for the given ApplicationBuild to update |
Patch Job Details
After creating a selection of Instances, you can configure the Patch Job itself and provide some details:
Option | Description |
---|---|
Name | The Patch Job Name |
Method | The patching method, e.g. Forced deployment, Rolling deployment, A/B deployment |
Start time | The desired start time of the Patch job |
Graceful stop(-timeout) | Whether or not to send a graceful stop command as opposed to an immediate stop. Comes with a maximum-drain-timeout value |
Comments | Any comments you would like to add to the Patch Job - maybe for other viewers to see |
Reporting email addresses | You will receive start, progress and final reports on the email addresses you provide |
Patch Job Reporting
You can accompany the Patch Job with a list of email addresses to which we will send start, progress and final reports. You can indicate for each email address whether to receive start & final reports and / or progress reports.
The Patching Process
5 minutes before the start time of a Patch Job, distribution of the new build towards all the relevant hosts begins, allowing for a quicker patching process later on.
Once the start time has been reached, the Patch Job will begin to run. First it collects information on all the application instances in your Patch Job selection and generates an initial report about it, which is sent to all relevant email addresses stored within the Patch Job.
Then the patching process itself begins. Which actions are performed depend on the selected patching method and are described in their respective chapters:
Once the Patch Job is complete, a final report is generated and sent to all relevant email addresses.
Canceling a Patch Job
You can cancel a Patch Job for as long as it's not finished yet. If you cancel a running Patch Job, we stop issuing new commands and update the Job's status. Then we revert all the already performed actions by creating an inverted Patch Job which will start running immediately.
Patching Related API Elements
The patching process introduces a few elements, used by all patch options:
- PatchJob - the element representing a scheduled patching process
- PatchJobProgressReport - the element containing information about an ongoing PatchJob
- PatchJobFinalReport - the element containing a summary of a completed PatchJob