Workflow: Difference between revisions

From Empires Wiki
Jump to navigation Jump to search
Line 25: Line 25:


== Creating a Merge Request ==
== Creating a Merge Request ==
# Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in [https://git.empiresmod.com gitlab] and click on the New Merge Request button under the Merge Request tab.
# Give the merge request a descriptive title and mention the issue number in the description as follows: <code>#123</code>
# If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with <code>WIP: </code>. This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
# Try to describe in the description field what you had to change and why.
# Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.


== Reviewing a Merge Request ==
== Reviewing a Merge Request ==

Revision as of 20:31, 26 August 2017

This page describes the workflow from a concept until release. Try to follow this when developing a new feature or releasing a new Empires version.

Creating an Issue

To ensure we don't duplicate effort and to allow team members to see what we're working on we add a short description of the thing we're trying to fix / achieve to an issue on the internal issue tracker.

When adding an issue, try to stick to formulating it as a user story. This makes it easier to evaluate whether a proposed change actually fixes the issue. To help discoverability you can add relevant tags.

If you plan on working on the issue yourself, be sure to assign yourself to it. For more information on how you can effectively use issues you can refer to the official issue documentation.

Cloning the Relevant Repository

If you've already performed this step in the past you can ignore this section

  1. Make sure you have an account on the internal gitlab and have received the appropriate permissions.
  2. Make sure you have added your public key to your acccount.
  3. Clone git@git.empiresmod.com:empires_assets/empires_build.git in a location of your choosing. Make sure you have at least 30gb free space.
  4. Double click the setup.bat file on Windows or the setup file on Linux and wait for the process to finish.
  5. Double click the preview.bat file on Windows or the preview file on Linux and wait for the process to finish.
  6. You should now have a development version of Empires you can run in your preview folder.

Creating a New Branch

  1. Figure out which repository you should be editing. The repos folder contains a list of all the repositories you have access to.
  2. Figure out if the issue you're working on should be categorized as a bugfix or as a feature. Bugfixes are changes which don't change the intended behavior of the game but purely fix a previous mistake. The rest are features.
  3. Create a new branch named bugfix/your-description or feature/your-description based on the master or develop branch. (Not all repositories have a develop branch, use master in that case)
  4. Start working on this branch and regularly commit your changes. You can create a new preview for testing by clicking the preview script again. This will include the changes you just made.

Creating a Merge Request

  1. Push your changes to the remote server. In the console output you'll see a link you can visit to create a new merge request. If there is no link you can also manually go to the project in gitlab and click on the New Merge Request button under the Merge Request tab.
  2. Give the merge request a descriptive title and mention the issue number in the description as follows: #123
  3. If your changes are not yet done or they don't yet pass all the build tests it's recommended to prefix the name of your merge request with WIP: . This is a signal to reviewers that they should wait a bit until they spend time reviewing the change.
  4. Try to describe in the description field what you had to change and why.
  5. Configure the merge request to delete the source branch when it is merged. If you don't know how to do this you can skip this step.

Reviewing a Merge Request

Preparing a Beta Release

Preparing a Full Release

Releasing a New Version