Difference between revisions of "Workflow"

From Empires Wiki
Jump to: navigation, search
(Creating a Merge Request)
(Reviewing a Merge Request)
Line 32: Line 32:
  
 
== Reviewing a Merge Request ==
 
== Reviewing a Merge Request ==
 +
# Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
 +
#* Feature Completion (Does this change actually address the issue referenced)
 +
#* Side Effects (Does this change only impact the issue or does it negatively influence other features)
 +
#* Readability and Maintenance (The codebase is now 10 years old and will probably have to be used for a long time, make sure we don't reduce our [https://en.wikipedia.org/wiki/Velocity_%28software_development%29 velocity])
 +
#* Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
 +
#* Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using [https://msdn.microsoft.com/en-us/library/ms182372.aspx profiling]).
 +
#* Simplicity (Simpler code is usually better, even when it reduces performance)
 +
#* [https://en.wikipedia.org/wiki/Code_reuse Reuse] of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
 +
#* Source Files (Make sure we have source files for all compiled assets that are in the merge request)
 +
# Test the code. Check out the code and create a preview to test with on a local listen server.
 +
# If the code works add a thumbs up smiley as a response.
  
 
== Preparing a Beta Release ==
 
== Preparing a Beta Release ==

Revision as of 05:51, 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

  1. Start with a code review. A code review is meant to improve code quality and distributes knowledge about the codebase between team members. Code review is not meant to catch errors / bugs although it's not a problem if it does. Try to review the code on the following areas:
    • Feature Completion (Does this change actually address the issue referenced)
    • Side Effects (Does this change only impact the issue or does it negatively influence other features)
    • Readability and Maintenance (The codebase is now 10 years old and will probably have to be used for a long time, make sure we don't reduce our velocity)
    • Consistency (Does the code look the same as the surrounding code and does it solve problems in the same way as we do elsewhere)
    • Performance (If we can improve performance without impacting Readability and Maintenance or other side effects we should probably do so. When in doubt, measure the performance using profiling).
    • Simplicity (Simpler code is usually better, even when it reduces performance)
    • Reuse of Existing Code (A lot of our code looks copy pasted, we can reuse a lot more than we currently do. Try to review whether there is code that can be reused)
    • Source Files (Make sure we have source files for all compiled assets that are in the merge request)
  2. Test the code. Check out the code and create a preview to test with on a local listen server.
  3. If the code works add a thumbs up smiley as a response.

Preparing a Beta Release

Preparing a Full Release

Releasing a New Version