Переглядайте доставку Taiga на основі доказів

Почніть із результату ініціативи

Вигаданий сервіс обладнання тепер дозволяє працівникам переглядати власні запити. Почніть перегляд із результату та обсягу ініціативи. Визначте, що має бути істинним і що зміна має залишити незмінним.

Для цієї доставки працівник не повинен читати запит іншого працівника. Менеджери мають зберегти визначений доступ. Тест, що лише відкриває сторінку, не встановлює жодної з умов.

Пов’яжіть записи

Сторінка Runs записує спроби, включно з невдалими. Кожен запуск визначає план, який виконував. Сторінка запуску — запис для дослідження; рішення, що змінюють роботу, належать ініціативі.

Прочитайте докази кроків щодо тестів і форматування. Taiga робить невдалі або невиконані перевірки видимими. Не перетворюйте «не виконано» на «успішно» в підсумку перегляду.

Перевірте припущення та межі

Шукайте припущення щодо моделі доступу, схеми, середовища та зовнішніх сервісів. Порівнюйте їх з опублікованим наміром і фактичним кодом.

Для сервісу обладнання перевірте, де перевіряється власник запиту. Протестуйте дозволений запит, запит іншого працівника та відсутній запит. Перевірте, що журнали не розкривають конфіденційного вмісту запитів.

Також переглядайте зміни тестів. Успішний результат має обмежену цінність, якщо зміна вилучила твердження тесту, що виявляло б дефект. Включайте зміни робочого процесу та конфігурації тестів до сфери перегляду.

Надавайте відгук, за яким можна діяти

Визначте поведінку, очікуваний результат і потрібні докази. Наприклад: «Endpoint перевіряє вхід, але не належність запиту. Додайте серверну перевірку доступу та тест із запитом іншого працівника».

Taiga може реагувати на відгуки перегляду pull request і невдалі перевірки змінами в тій самій гілці. Після оновлень перевірте новий commit і його перевірки. Ранніші докази можуть не охоплювати зміненого артефакту.

Якщо запуск зупинився через неповний план або послаблену перевірку, прочитайте вказану причину. Не вилучайте статус чернетки лише через зелений видимий підсумок перевірок.

Ухваліть правильне рішення про прийняття

Запишіть, які критерії перевірено, а які залишаються невирішеними. Нехай потрібні перегляди та перевірки репозиторію забезпечують межу merge. Зберігайте кожне окреме рішення про випуск.

Taiga спостерігає за розгортаннями вашого pipeline. Перевірте середовище та артефакт до повідомлення користувачам про доступність зміни. Невдале розгортання може залишити попередню успішну версію обслуговувати трафік.

Підтвердьте результат перевіркою на рівні сервісу: працівник може використовувати функцію, несанкціонований доступ відхилено, а відповідальний за експлуатацію може спостерігати збої. Продовжіть з опрацювання переривання.