DilOS4 Development Workflow сконструирован для поддержки процессов разработки и сопровождения. Внутри процесса используются несколько типов тикетов:
...
Любой, у кого есть права Create Issue, ожет может создать тикет. Конечно, более подробная и полная информация об ошибке, новой фиче или задаче весьма приветствуется, но по крайней мере поля Description и Environment ДОЛЖНЫ быть заполнены, чтобы тикет создался. После этого тикет помещается в backlog, и ему присваивается статус OPEN. И он автоматически назначается кому-то в роли Development Lead, и после чего этому человеку высылается оповещение.
...
Development Lead может назначить тикет любому в роли Developer , кто может работать с этой темой (на его взгляд). Или любой Developer может взять этот тикет себе, просматривая backlog и нажав на тикете Assign to Me. После этого нужно поменять статус тикета на Assign to developer → ASSIGNED. После этого считается, что назначенный человек будет работать над этим тикетом.
...
Developer может вернуть тикет назад в backlog, если тикет был назначен по ошибке. Для этот этого нужно поменять статус на Unassign → OPEN и при этом обязательно вписать в Comment что-то в Comment, что может помочь понять причину возврата. После этого тикет возвращается в backlog.
...
Если в процессе анализа становится ясно, что другой человек должен работать над этим тикетом, 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.
...
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
...
Работа над кодом
Когда тикет находится в состоянии IN PROGRESS, считается, что Developer работает над кодом.
...
Если в процессе написания кода потребуется какая-то дополнительная информация, Developer или Development Lead может вернуть тикет назад в состояние IN ANALYSIS, чтобы задать кому-то дополнительные вопросы, попросить что-то сделать или просто ещё подумать . Для этого нужно поменять статус на Clarify → IN ANALYSIS и заполнить поле Comment, где указать причину такого возврата.
Когда работа над кодом закончена, Developer должен подготовить коммит, записать информацию о версии (возможно, ветке) и Environment в тикет и передать код на тестирование. При этом необходимо в поле Comment добавить информацию, которая поможет тест-инженерам провести грамотное тестирование. После этого Developer должен поменять состояние на Resolve → RESOLVED. Тогда тикет переводится в состояние RESOLVED и автоматически назначается человеку в роли Test Lead.
6. Тестирование изменений
Все тикеты в состоянии RESOLVED считаются готовыми для тестирования. Для группы тестирования это состояние сходно с состоянием OPEN для группы разработчиков: Test Lead получает уведомление, когда любой тикет переводится в это состояние, и может назначить любого в роли Quality Assurance для тестирования этого тикета. Также и любой тест-инженер может пройтись по списку таких тикетов и взять любой из них себе, нажав на Assign to Me. После этого состояние тикета нужно поменять на Verify → TESTING - и тикет будет считаться находящимся на тестировании.
...
По завершении тестирования тикет может быть закрыт, если всё работает правильно, или возвращён на доработку, если тестирование не прошло.
Для закрытия тикета инженерQuality Assurance или Test Lead должен поменять статус на Done → CLOSED. И очень желательно добавить в тикет любую информацию, которая может помочь владельцу тикета воспользоваться сделанными изменениями и/или проверить его работу. После этого тикет автоматически возвращается владельцу тикета.
Для возвращения тикета Developer-у для доработки инженер Quality Assurance или Test Lead должен сменить статус на Not fixed → ASSIGNED и заполнить, по крайней мере, поле Comment описанием того, что пошло не так. И очень желательно добавить в тикет любую информацию, которая может помочь Developer-у осознать проблему: прикрепить логи, добавить картинки, привести описание шагов для воспроизведения неправильного поведения etc. После этого тикет автоматически назначается на разработчика, который переводил тикет в состояние RESOLVED.
7. Как отвечать на вопросы
Чтобы ответить на заданные вопросы и вернуть тикет из состояния SUSPENDED, тот, на кого этот тикет был переназначен, должен добавить в тикет запрашиваемую информацию (как минимум, заполниить Comment) и поменять состояние на Resume → IN ANALYSIS. После этого тикет автоматически вернётся тому, кто его заморозил.
8. Переоткрытие тикета
Любой, у кого есть права Create Issue, может переоткрыть тикет из состояния CLOSED, если проблема возникла вновь, или появилась подобная. Для этого нужно статус тикета поменять на Reopen → OPEN и добавить в поле Comment описание проблемы. После этого тикет помещается в backlog и назначается человеку в роли Development Lead , точно так же, как это происходило при создании тикета.