Skip to content

Latest commit

 

History

History
40 lines (28 loc) · 3.32 KB

DEPLOYMENTS.md

File metadata and controls

40 lines (28 loc) · 3.32 KB

CnCNet Yuri's Revenge Client Package Deployments

This describes the workflow for release/deployments.

Versioning

Deployments are currently set up for Continuous Deployment. Versioning is auto incremented. There are two triggers for deployments and versioning:

  1. 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:

    1. If the tag yr-8.7 is created, the next deployed version in this case will be 8.7.0.
    2. If the tag yr-8.7.1 is created, the next deployed version in this case will be 8.7.1.

  2. Merging into master: When this happens, an auto incremented dev version of the client will be created and deployed. This auto incremented version will be the last tag version +1 patch. Examples:

    1. If the latest tag is yr-8.6, the next deployed version will be 8.6.1-dev.
    2. If the latest tag is yr-8.6.1, the next deployed version will be 8.6.2-dev.

Workflow

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

Current state: 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 pushed directly to master.
  2. The deployment Github Action is triggered and deploys the version 8.6.1-dev to the server. The version file generated by VersionWriter.exe will have the version of 8.6.1-dev.1.
  3. yrdev on the server is linked to 8.6.1-dev deployment (manual process). This version is now live for dev testers.
  4. Another PR of new code is created and merged OR code is pushed directly to master.
  5. The deployment Github Action is triggered and deploys an updated version of 8.6.1-dev to the server. The version file generated by VersionWriter.exe will have the version of 8.6.1-dev.2. This should trigger an update notification for anyone testing dev versions.
  6. The version 8.6.1-dev 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. yrdev on the server is linked to 8.7.0 (manual process)
    • This is optionally done for "smoke testing" purposes. However, if the tag was created from the latest commit in the master branch, which should have been the latest version deployed to 8.6.1-dev, the versions 8.6.1-dev and 8.7.0 are essentially the same.
  9. yr on the server is linked to 8.7.0. This version is now live for all.

Security and Approvals

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

  1. Pushes directly to master are disabled for non admins. Changes to master 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.