DilOS 4 Development Workflow (English)

Owned by Vitaly Shaburov
Last updated: Oct 31, 2022
6 min read

DilOS4 Development Workflow is designed to support development and maintenance processes. There are several types of issues that are used in this workflow. They are:

The development team working on this workflow consists of people in the following roles:

  • Developers

  • Development Leads

  • Quality Assurance engineers

  • Test Leads

The full development workflow looks like this:

1. Issue creation

Everybody who has Create Issue permissions can create an issue. However more full information about the bug, feature or task is helpful, but at least Description and Environment fields MUST be filled to create the issue. After this issue is placed to the backlog with OPEN status, it is automatically assigned to one of Development Lead and notification is sent to the assignee.

2. Assigning issue to developer

Development Lead can assign the issue to any Developer who can work on this issue. Or Developer can take this issue by looking through backlog and clicking on Assign to Me. After this he/she should change the issue status to Assign to developer → ASSIGNED. And now it is supposed that this person will work on this issue.

3. Beginning to work on issue

Developer can return the issue back to the backlog if the issue has been assigned to him/her by mistake. To do this he/she should change status to Unassign → OPEN and definitely put any Comment to describe the reason why the issue is returned. After this the issue is placed to the backlog.

To start working on the issue Developer has to change the issue status to Start Working → IN ANALYSIS. When this is done the issue is treated as processed and the Start Date is set for this moment.

4. Analyzing the issue

In this state Developer should understand what has to be done for this issue, clarify all not clear questions etc.

If on this stage it becomes clear that another person should work on the issue Developer can return the issue back to the backlog. To do this he/she MUST fill at least the Comment field with information why the issue is returned and change status to Not for me → OPEN. After this the issue is placed to the backlog and assigned to Development Lead with an appropriate notification.

If on this stage it becomes clear that this issue just a clone of any other issue Developer can close the issue by changing status to Duplicate → CLOSED with mandatory filling Linked Issue field with the identifier of a duplicated issue and Comment field with description why it is so.

If by any reason this issue will not be fixed Developer can also close the issue by changing status to Reject → CLOSED with mandatory filling Comment field with description of the reason why the issue will not be fixed.

If Developer understand that the issue is already fixed in process of fixing another issue he/she can just put it to Already fixed → RESOLVED state with at least mandatory writing about the place and version of the fix in Comment field.

The issue can be suspended for a while if any question should be clarified from outside or same actions should be fulfilled outside or may be the issue is just frozen. To do this Developer or Development Lead can change status to Suspend → SUSPENDED with writing the Comment and assigning issue to the person who will answer the question or will responsible for the required action - it this case this person will receive notification about this. To be more informative Developer can put Resolution field to the appropriate value as well.

When everything is clear and analysis is done Developer can start writing code. To do this he/she has to change status to Create fix → IN PROGRESS.

5. Working on code

It is supposed that Developer works on the code when an issue is in IN PROGRESS state.

If in process of working on the code some additional clarification becomes required Developer or Development Lead can return the issue back to IN ANALYSIS state to ask any question or any action from other persons. To do it he/she should change status to Clarify → IN ANALYSIS and write Comment where the reason of this transition is described.

When the fix is done Developer has to prepare the commit, put information about the fix and Environment to the ticket and provide the code for testing. He/She also has to write a Comment with description of steps for testing the fix. When this information is ready Developer should change status to Resolve → RESOLVED. After this the issue is put to RESOLVED state and automatically assigned to Test Lead.

6. Fix Testing

All issues in RESOLVED state are ready for testing. This state for the quality assurance team is similar to OPEN state for the development team: Test Lead receives notification when any issue is put to this state and he can assign any Quality Assurance person for testing the issue. Test engineer can walk through the list of resolved issues and take it by clicking on Assign to Me as well. After this the issue should be transit to Verify → TESTING. After this the issue is treated as processing by the quality assurance team.

When testing process is finished the issue can be closed if everything works fine or can be returned to the developer for further processing if this fix doesn’t work as expected.

To close the issue Quality Assurance engineer or Test Lead should change the issue status to Done → CLOSED. And it is very desired to put any additional information that will help the issue reporter to use and to verify the code. After this the issue is automatically returned back to the reporter of the issue.

To pass the issue back for Developer for further processing Quality Assurance engineer or Test Lead should change the issue status to Not fixed → ASSIGNED and at least put Comment with description what is going wrong. And it is highly desired to put any additional information like attaching logs, pictures etc. to help Developer to understand the problem. After this the issue is automatically assigned to the developer who put the issue to the RESOLVED state.

7. Answering the questions

To answer the question and to return the issue from SUSPENDED state the current assignee has to put all required information (at least Comment) and change status to Resume → IN ANALYSIS. After this the issue will be automatically assigned to the person who suspended the issue.

8. Reopening the issue

Everybody who has Create Issue permissions can reopen already CLOSED issue if similar problem appeared or the problem is appeared again. To do this he/she has just to change status to Reopen → OPEN and provide Comment with the problem description. After this the issue is placed to the backlog and assigned to Development Lead like it is done when issue is created.