Introduction

This wiki page is intended to guide developers through the process of a release in Server Duels. We will go through every step of the process starting from a completely new JIRA board to a complete release merged into the main branch. The ultimate goal is to have Server Duels releases occur quarterly (every 3 months). However, TYPO Studios recognizes this is not always possible, so consider the quarterly timeline to have a very soft deadline.

Another quick note is the term release and sprint should be considered synonymous while reading this article. They will be utilized interchangeably throughout the wiki.

Phase 1 - Development

This phase of a release involves Server Duels developers updating the product with new features and bug fixes. Developers will have assigned tasks on a JIRA board for each release, and the release is considered code ready* whenever all JIRA tickets have been set to MERGED status.

I say code ready with an * because it is very likely developers will have more coding to do during the testing phase unless miraculously no bugs are discovered.

Phase 2 - Pre-Testing

At this point of the sprint, developers have completed all their tasks and all JIRA tickets associated with the release are set to MERGED status. The next step is for an assigned developer to create the release branch. Testing will be based off of this release branch, all bug fixes made during testing will be merged into this branch, and this is the branch that will be merged into main for the release.

After all outstanding pull requests have been merged into development, the assigned developer should create a branch named x.x-release off of development where "x.x" is the version number of the current sprint.

In addition to creating the release branch, a changelog should be drafted and posted in the Server Duels text channel in the TYPO Studios Discord. Developers should make suggestions on the proposed changelog and edit it as necessary.

Lastly, a developer will be assigned to build an original release candidate from the source code on the release branch. The release candidate binaries should be posted in the Server Duels text channel of the TYPO Studios Discord once built.

Phase 3 - Testing

Arguably the most important phase of a release, developers will now undergo the process of trying to break the latest version of Server Duels. Developers should conduct all of their tests from the latest release candidate.

Tests are created and associated with each JIRA ticket completed during the Development phase. These tests should be created in Testiny and linked in all pull requests during the Development phase. A wiki page on creating Testiny test cases will be available soon and linked here when created. Testiny will have all of these tests organized into test cases that developers can access and record whether or not they pass or fail. All failing test cases must have associated JIRA tickets created for them and linked in the comment section of the test case.

After all test cases have been conducted, the release can go one of two different routes. If all test cases have a passed status, then the release moves into Phase 4. If there are failing test cases, developers now must resolve all associated JIRA tickets with those test cases, create pull requests, and merge those pull requests into the release branch. Then, once all newly created JIRA tickets have the MERGED status, a new release candidate will be built with the latest source code from the release branch. Developers will then repeat any failing tests on the latest release candidate and repeat this process as long as there is failing tests.

Phase 4 - Release

Once all tests have reached the passed status, this means the latest release candidate is a code ready version of Server Duels and that the source code on the release branch is production level (at least we hope so :wink:).

This stage of the release should be relatively short and consists of updating the version number in our pyproject.toml file, finalizing the changelog, and opening a pull request to merge the release branch into main. Note that we DO NOT merge the release branch into development first because that branch could have additional code that is not intended for a specific release.

After the release pull request is approved, a GitHub administrator should create a new release tag for the GitHub repository with an associated version number and changelog.

Phase 5 - Post Release

There is some cleanup to be done after the release branch has been merged into the main branch and published on the GitHub repository. A pull request needs to be opened to merge main into development.

Lastly, the JIRA sprint board should be marked as completed and a new one should be created for the next release. Any JIRA tickets in the backlog scheduled for the next release will then be dragged into the new board. Then, it is time for a senior developer to start the next sprint and the whole release process starts all over again!