Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

How the Evernym team will deal with tickets in Jira:

  1. Put a task into IN PROGRESS column
  2. Make sure your understand the requirements and acceptance criteria (if there are any questions - ask @Richard Esplin / @alexander.shcherbakov / @Sergey Minaev)
  3. Write a Plan of Attack (PoA) describing how you are going to implement the task or fix the issue. The PoA should also include description of tests (especially integration ones)
    1. The PoA can be created as a comment in Jira ticket.
    2. Sometimes the task is so big or essential that it's worth to create a PR with a Design (to design folder), or even a HIPE.
    3. Send a link to the PoA to the team so that it is reviewed by other team members.
  4. Do the implementation following Test Driven Development (TDD) and write sufficient amount of unit and integration tests.
  5. Raise a PR. make sure the tests pass.
    1. If there are a lot of changes expected - raise multiple PRs with small chunks.
    2. Try to raise a PR as soon as possible for earlier review (for indy-node: use [Skip CI] prefix in PR name to not run tests if you are sure that this is a WIP and they will fail.
  6. Add a comment to the ticket according to the template below
  7. Move the ticket to the Code Review column
  8. Send a link to the PR to the team, so that it's reviewed by other team members.
  9. Once it's merged, the ticket goes to Validate column, and QA engineer performs the validation (writing system tests as needed)


When a ticket is moved to the Code Review phase, it needs a comment that follows a specific template. This is useful for:

  • Code Review
  • Those doing testing
  • Coming back to the issues/changes in future to understand what exactly have been done, how and when.

Template

Problem reason/description: 

- list of reasons

Changes: 

- list of changes

PR:

- link to PR on github

Version:

- build number

Risk factors:

- ....

Risk:

- Low/Med/High

Covered with tests:

- Test ref on github

Recommendations for QA

- how to test

  • No labels