Skip to content

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.

Patch Job Instance Selection

A Patch Job is always applied to a certain selection of application instances (game servers usually, but you can patch utilities as well). 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
Table 1: Patch Job instance selection parameters

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
Table 2: Patch Job details and configuration parameters

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.

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