Rolling Deployment Manually

Updating your game servers with a rolling update means that you update game servers as soon as they exit naturally or when they are empty and unallocated.

Initial situation sketch

We have a fleet with 1 ApplicationBuild in its deployment template. 100 game servers have been deployed.

This chapter assumes you already have created a new ApplicationBuild for your updated software.

Actions to perform

• open the GameDeploymentTemplate for the Fleet whose game servers you want to update.

• replace the existing ApplicationBuild ID in the DeploymentTemplate with the new ApplicationBuild ID.

Every game instance that is in a free state, or goes into a free state will be re-deployed with the new build. Note that our platform does not update all free instances at once, but does this in batches so that there will always be free instances that can still be allocated during the rolling update period.

Eventually (almost) all game instances will have been updated. To finalize the update process you will want to forcefully update any remaining game instances running the old build. This heavily depends on whether your game uses short or long lived matches / sessions / game play. Games that use matches of a specific maximum length usually rotate fairly quickly, but games that have long running sessions that do not have a particular ending might need a forceful update at some point.

API example

Step 1: get Fleet details

We need to get the Fleet object so that we can see which GameDeploymentTemplate is assigned to it.

HTTP request

GET /fleet/988194285688223011

Response body

[
    {
        "id": "988194285688223011",
        "name": "Exmaple Fleet",
        "deploymentEnvironmentId": "1528510395058174656",
        "deploymentProfileId": "2641748478114564847",
        "gameDeploymentTemplateId": "6629032387499739571",
        "utilityDeploymentTemplateId": "0",
        "operationalStatus": 2
    }
]

Step 2: get the GameDeploymentTemplate

Using the Fleet.gameDeploymentTemplateId property from the previous call, we can now get the GameDeploymentTemplate itself.

HTTP request

GET /deploymentTemplate/game/6629032387499739571

Response body

[
    {
        "id": "6629032387499739571",
        "fleetIds": [
            "988194285688223011",
            "8080951566089961859"
        ],
        "name": "Example Game Deployment Template",
        "inUse": 1,
        "createdAt": 1563526808,
        "gameDeploymentTemplateBuild": [
            {
                "applicationBuildId": "1459775459116568767"
            }
        ]
    }
]

Step 3: replace applicationBuildId

We see that the currently active ApplicationBuild ID is "1459775459116568767". Let's replace it with our new ApplicationBuild ID "817092209556457642".

HTTP request

PUT /deploymentTemplate/game/6629032387499739571

Request body

{
  "gameDeploymentTemplateBuild": [
    {
      "applicationBuildId": "817092209556457642"
    }
  ]
}

Response body

[
    {
        "id": "6629032387499739571",
        "fleetIds": [
            "988194285688223011",
            "8080951566089961859"
        ],
        "name": "Example Game Deployment Template",
        "inUse": 1,
        "createdAt": 1563526808,
        "gameDeploymentTemplateBuild": [
            {
                "applicationBuildId": "817092209556457642"
            }
        ]
    }
]

Now you can sit back and see inactive / available game servers being updated in batches.