DilOS4 Development Workflow сконструирован для поддержки процессов разработки и сопровождения. Внутри процесса используются несколько типов тикетов:
Команда разработки, работающая по этому процессу, состоит из сотрудников, которым назначены следующие роли:
Developers
Development Leads
Quality Assurance engineers
Test Leads
Полный процесс выглядит так:
1. Создание тикета
Любой, у кого есть права Create Issue, ожет создать тикет. Конечно более подробная и полная информация об ошибке, новой фиче или задаче весьма приветствуется, но по крайней мере поля Description и Environment ДОЛЖНЫ быть заполнены, чтобы тикет создался. После этого тикет помещается в backlog, и ему присваивается статус OPEN. И он автоматически назначается кому-то в роли Development Lead, и этому человеку высылается оповещение.
2. Назначение тикета разработчику
Development Lead может назначить тикет любому в роли Developer , кто может работать с этой темой (на его взгляд). Или любой Developer может взять этот тикет себе, просматривая backlog и нажав на тикете Assign to Me. После этого нужно поменять статус на Assign to developer → ASSIGNED. После этого считается что назначенный человек будет работать над этим тикетом.
3. Начало работы с тикетом
Developer может вернуть тикет назад в backlog, если тикет был назначен по ошибке. Для этот нужно поменять статус на Unassign → OPEN и при этом обязательно вписать что-то в Comment, что может помочь понять причину возврата. После этого тикет возвращается в backlog.
Для начала работы с тикетом Developer должен поменять статус на Start Working → IN ANALYSIS. Когда это будет проделано, тикет будет считаться находящимся в работе, а в поле Start Date будет занесён текущий момент.
4. Анализ тикета
Когда тикет находится в этом состоянии, Developer должен проанализировать всю имеющуюся информацию, прояснить все неясные моменты и понять, что нужно делать.
Если в процессе анализа становится ясно, что другой человек должен работать над этим тикетом, Developer может вернуть тикет назад в backlog. Для этого ОБЯЗАТЕЛЬНО нужно заполнить по крайней мере поле Comment, чтобы объяснить причину возврата, и поменять статус на Not for me → OPEN. После этого тикет возвращается в backlog и назначается Development Lead-у с соответствующим уведомлением.
Если на этой стадии становится ясно, что этот тикет дублируется каки-то другим тикетом, Developer может закрыть тикет, поменяв статус на Duplicate → CLOSED с обязательным заполнением поля Linked Issue идентификатором дублирующего тикета и поля Comment с пояснением, почему это так.
Если по какой-либо другой причине тикет не будет выполнен, Developer тоже может закрыть его, сменив статус на Reject → CLOSED с обязательным внесением в поле Comment описания причины, почему тикет не будет выполняться.
Если в процессе анализы выясняется, что тикет уже выполнен в процессе выполнения другого тикета, Developer может просто перевести его в состояние Already fixed → RESOLVED с обязательным внесением информации о версии и ветке, где этот тикет выполнен, в поле Comment.
Тикет может быть временно замороржен, если нужно прояснить дополнительно какие-то вопросы, или по какой-либо другой причине. Для этого Developer или Development Lead должен поменять состояние на Suspend → SUSPENDED с заполнением поля Comment и назначением тикета человеку, который должен ответить на вопрос или выполнить какое-то действие - в этом случае этому человеку будет выслано соответствующее оповещение. Если есть необходимость дать более полную информацию, то Developer может изменить поле Resolution в соответствующее значение.
Когда всё становится ясно, и все вопросы прояснены, Developer может приступать к написанию кода. для этого статус нужно поменять на Create fix → IN PROGRESS.
5. Working on code
It is supposed that Developer works on code when the 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.