Skip to content

Development D-Eco Impact

Workflow

Developer:

  1. Move the jira issue you want to work on from "todo" into "in progress". (issue should be in the sprint, if not please discuss with product owner about changing the sprint scope).

  2. Create a development branch from the main branch with the name based on that of the issue
    feat[issue id] {summary of the issue}. For example: > feat[DEI-123] Improve functionality A

    Then switch your local copy to the development branch.

  3. Commit the necessary changes with clear messages on what has been done.

  4. Verify if all checks have passed (a green checkmark is shown, not a red cross).

    checks Is one or more checks fail, they must be fixed before continuing.

  5. Once all checks pass, control if there are any changes in the main branch. If so, merge them to the development branch and fix all possible conflicts in the code, if any, and then go back to point 4 of this list.

  6. Move the issue from In progress to In review and create a pull-request with the name of the branch previously assigned: > feat[issue id]{summary of the issue}.

Reviewer:

  1. Change the status of the issue from In review to Being reviewed. This should make you automatically the assignee.

  2. Look at the development details of the issue. detailsIssues

  3. Open the linked pull-request in GitHub.

  4. Change the reviewer to yourself if it didn't happen before, as indicated in point 1.

    reviewer

  5. Go to the Files changed tab to see the modifications implemented for the issue.

    filesChanged

  6. Add your review comments (see comment on a PR documentation ).

    Some points to analyse during the review are: * does the code work, including corner cases? * is the code in the right place? * is it readable? * is the code documented (all public methods and classes should have doc strings)? * are nameing conventions used properly? * is there any duplication of the code? * Is the code maintainable? * is the code covered by tests? * are all tests and checks green? * are the commit messages clear enough and do the satisfy the conventions?

    codeCoverage 7. Set the status of the issue (comment, approve or request changes). statusIssue 1. Change the status if the issue in Jira corrspondingly:

    • Approved -> In Test
    • Request changes -> To do
    • Comment -> In review (with the developer as assignee).

Tester:

  1. Change issue status from "in test" to "being tested". This should make you the assignee.

  2. For a bug or improvement, check out the main branch and try to reproduce the issue or to get familiar with the previous functionality.

  3. Change your local check-out to the development branch (from which the pull-request was created).

  4. Test now the new functionality or bug fix by running the main script from python in a clean python environment.

  5. Try to think of situations or conditions that may have been forgotten to implement properly, and test these as well.

  6. Add comments in the issue with your findings (ok or not because ...). Describe enough in detail so that other people can easily reproduce any problems found. If needed, provide any required (additioonal) data.

  7. Move the issue in Jira to the new corresponding state:

    • If the test is ok, to Merge.
    • If the test is not ok, move to To do.

If test is succesful

  1. Go to pull request on GitHub.

  2. Check if there will be merge conflicts (shown by GitHub) and if the development branch is up to date with the main branch. mergeCOnflicts

    • If any merge conflicts are reported, then check with developer to resolve the merge issues.
    • If the branch does not have any merge conflicts and is not up to date -> press the update branch button.

  3. If the branch is up to date and does not have merge conflicts you can merge the pull request to the main branch.

  4. Change issue status in jira from "merge" to "validate".

  5. Change your local checkout to the main branch and do a few checks to see if the merge was correct.

  6. If the merge was successful, change issue status in jira from "validate" to "done".

Agreements

Coding:

  • We use the PEP8 style guide for python development.
  • We use typing where possible.
  • We avoid using global variables.

  • We use encapsulation by only making the necessary imports and variables public.

  • For testing, we use the pytest module.

  • For checking the style guide, we use flake8 and pylint.

  • For managing external dependencies, we use poetry (.toml file).

  • We prefer to use VS Code for development (sharing settings using vscode folder) with the following plugins: