Skip to content

Latest commit

 

History

History
75 lines (51 loc) · 5.49 KB

DEPLOYMENTS.md

File metadata and controls

75 lines (51 loc) · 5.49 KB
Raw

CnCNet Yuri's Revenge Client Package Deployments

This describes the workflow for release/deployments.

Deployments are currently set up for Continuous Deployment. Versioning is auto incremented. Builds and deploys are triggered by new code pushed to the following branches:

  • develop
  • feature/*
  • hotfix/*.

Versioning

Publishing a release:

When a release is created, the corresponding tag name should be created in the format yr-X.Y or yr-X.Y.Z, where X is major, Y is minor, and Z is an optional patch. When a tag is created in this format, a deployment will occur for that exact version.

Examples:

  • If the tag yr-8.7 is created, the next deployed version in this case will be 8.7
  • If the tag yr-8.7.1 is created, the next deployed version in this case will be 8.7.1

New develop/feature versions:

After a tag has been created, any commits to either the develop branch or a feature/* branch will created a new version that is an incremented Minor version of the that most recent tag. Additionally:

  • The full version string will have the branch name appended to the end.
  • The full version string will have a commit counter number appended to the end.

Examples:

  • If the latest tag is yr-8.6, a single commit to the develop branch will create the version 8.7.0-dev.1. Two more commits (three total after the latest tag) will create the version 8.7.0-dev.3.
  • If the latest tag is yr-8.6, a single commit to the /feature/my-feature branch will create the client version 8.7.0-my-feature.1. Two more commits (three total after the latest tag) will create the client version 8.7.0-my-feature.3.

Hotfix versions:

Similar to develop/feature versions, any commits to a /hotfix/* branch will auto increment the Patch version based on the latest tag version.

Examples:

  • If the latest tag is yr-8.6, a commit to a hotfix branch my-fix will create the client version 8.6.1-my-fix.1.

GitHub Workflow

This section describes the proper workflow for publishing new versions of the client. Below is an example of a "current state" scenario.

Current state: Example 1

The client is on version 8.6 and a git tag of yr-8.6 exists.

  1. A PR of new code is created and merged OR code is committed and pushed directly to the develop branch.
  2. The deployment Github Action is triggered and creates the version directory /updates/games/yr/updates/8.7.0-dev on the server. The version file generated by VersionWriter.exe will have the version of 8.7.0-dev.1.
  3. The /updates/games/yr/dev is created automatically (if necessary) on the server and linked to the /updates/games/yr/updates/8.7.0-dev folder. This version is now live for dev testers.
  4. Another PR of new code is created and merged OR code is pushed directly to develop.
  5. The deployment Github Action is triggered and deploys an updated version of 8.7.0-dev to the server. The version file generated by VersionWriter.exe will have the version of 8.7.0-dev.2. This should trigger a client update notification for anyone testing dev versions.
  6. The version 8.7.0-dev.2 has been determined to be stable and is tagged in Github as yr-8.7 (manual process).
  7. The release Github Action is triggered. This then triggers the deployment Github Action which deploys the version 8.7.0 to the server.
  8. The /updates/games/yr/live folder/link on the server is the manually linked to 8.7.0. This version is now live for all.

Current state: Example 2

The client is on version 8.6 and a git tag of yr-8.6 exists.

  1. A PR of new code is created and merged OR code is committed and pushed directly to the feature/my-feature branch.
  2. The deployment Github Action is triggered and creates the version directory /updates/games/yr/updates/8.7.0-my-feature on the server. The version file generated by VersionWriter.exe will have the version of 8.7.0-my-feature.1.
  3. The /updates/games/yr/my-feature is created automatically (if necessary) on the server and linked to the /updates/games/yr/updates/8.7.0-my-feature folder. This version is now live for testers.
  4. Another PR of new code is created and merged OR code is pushed directly to feature/my-feature.
  5. The deployment Github Action is triggered and deploys an updated version of 8.7.0-my-feature to the server. The version file generated by VersionWriter.exe will have the version of 8.7.0-my-feature.2. This should trigger a client update notification for anyone testing dev versions.
  6. The version 8.7.0-my-feature.2 has been determined to be stable and is tagged in Github as yr-8.7 (manual process).
  7. The release Github Action is triggered. This then triggers the deployment Github Action which deploys the version 8.7.0 to the server.
  8. The /updates/games/yr/live folder/link on the server is the manually linked to 8.7.0. This version is now live for all.
  9. Code from feature/my-feature is merged to develop branch.

Security and Approvals

For security reasons, the develop branch has protection rules in place to prevent unauthorized pushes/merges to develop and thus unauthorized deployments.

  1. Pushes directly to develop are disabled for non admins. Changes to develop must be made through a PR.
  2. PRs for non admins require a minimum of 1 approval.
  3. Approvals on PRs that are "updated" by new commits are immediately dismissed. These PRs must be re-approved.