Это политика Политика — это именованный набор правил проверки с указанием версии. Политики привязываются к проектам; сами правила выполняются именно ими.
Чтобы разобраться в понятиях — блокирующие и рекомендательные правила, а также порядок их применения — прочитайте Правила проверки сначала. На этой странице рассказывается о том, как ими управлять.
Управляйте ими в Quality Control. В таблице отображаются настройки по умолчанию для организации и для каждого проекта. Выберите нужную запись, чтобы увидеть, как новые изменения проходят проверку, какие критерии учитываются при каждом изменении, уровень контроля качества и место выполнения проверок. Для каждой записи предусмотрен переключатель, который при активации сразу применяет настройки. Подтверждение позволяет отменить изменения, а параметры строки определяют способ работы конкретной проверки.
- Стандарт организации3 проекта используют эти настройки.2 из 5
- Интернет-магазинСобственная настройка4 из 5
- Сайт документацииИспользует стандартные настройки2 из 5
- Проверка API для биллингаИспользует стандартные настройки2 из 5
- Мобильное приложениеИспользует стандартные настройки2 из 5
- Anti-slopСистема отправляет изменение обратно, если оно приводит к ухудшению результатов тестов, скрытию ошибок, отправке плейсхолдеров или созданию технического долга.
- Модульные тестыПри каждом изменении система находит и запускает модульные тесты, предусмотренные в репозитории.
- Тесты в браузере2 из 3отличается от стандартных настроекСистема выполняет браузерные тесты для проверки корректности работы с изменениями.
- Переводыотличается от стандартных настроекПроверяется соответствие переведённых строк, а также правильность использования плейсхолдеров и форм множественного числа.
- Проверки репозиторияСистема выполняет собственные команды, включая форматирование кода, проверку размера файлов, миграции, интеграционные тесты и сканирование на предмет уязвимостей.
- Тщательная QA-проверкаТщательная проверкаРежим тщательного контроля качества собирает актуальные доказательства и скриншоты в соответствии со спецификацией. При его отключении применяется стандартный режим проверки качества.
Контроль качества: действующие правила и последний запуск проверки. Примерные данные.
Создание политики
Политика — это набор проверок, а также информация о том, блокирует ли сбой в одной из них процесс или лишь даёт рекомендацию.
Большинству организаций нужны две-три политики, а не одна на каждый проект:
- одна жёсткая политика для производственных сервисов
- одна стандартная политика для обычных задач
- иногда бывает и упрощённая политика для внутренних инструментов и прототипов
Если их будет больше, никто не сможет запомнить, какая политика применяется к какому проекту.
Настройки по умолчанию для организации и собственные настройки проекта
Проект использует настройки по умолчанию, пока вы не измените соответствующие переключатели. Такое изменение создаёт для проекта собственные настройки, скопированные из общих. Последующие изменения общих настроек на такой проект уже не повлияют. Из одной строки можно скопировать отдельную проверку обратно из общих настроек, а в меню проекта — сбросить все настройки до значений по умолчанию для организации. Полная информация о политике, включая ожидаемые результаты, зависимости между проверками, бюджеты на исправления и версии, открывается в том же меню, что и расширенный редактор. Для проекта, следующего общим настройкам, редактор открывается с копии этих настроек, и ничего не изменится для проекта, пока вы не опубликуете эту копию.
Установите в качестве значения по умолчанию вашу стандартную набор проверок, которые должны выполняться в большинстве проектов; самые жёсткие правила следует применять осознанно, проект за проектом.
Запросы на объединение изменений
Запросы на объединение изменений, создаваемые пользователями и другими инструментами, поступают в Coroid через приложение Coroid GitHub. Группа Запросы на объединение изменений в разделе Quality Control определяет, что с ними делать, как для настроек по умолчанию организации, так и для каждого проекта:
- Coroid Quality Control выполняет вышеуказанные проверки для каждого pull request и отображает результат как проверку Coroid Quality Control в GitHub.
- Coroid Review предусматривает, что рецензент Coroid прочитает каждый pull request и оставит комментарии к вызывающим сомнения строкам. Он анализирует запросы на объединение изменений, проверенные модулем Coroid Quality Control.
Настройки Coroid Review:
- Что он публикует. Режим рекомендаций — значение по умолчанию: комментарии публикуются, но проверка не считается неудачной, за одним исключением: при подтверждённой критической или высокой проблеме безопасности проверка завершается ошибкой, если в разделе Безопасность включён режим принудительного рецензирования (см. Сканирование кода и рецензирование на предмет безопасности). Режим блокировки приводит к остановке процесса при обнаружении проблемы, и проверка считается неудачной. Чтобы рецензирование стало обязательным этапом в GitHub, установите соответствующий флажок для Coroid Review, чтобы блокирующее рецензирование препятствовало объединению изменений.
- Какие запросы на объединение изменений. По умолчанию система ждёт, пока черновик не будет помечен как готовый, и игнорирует запросы на объединение изменений, созданные самим Coroid, так как рецензент Coroid уже рассмотрел их в рамках задачи. Также можно исключить запросы от ботов.
- Когда происходит рецензирование. Система ждёт периода тишины после последней загрузки кода — по умолчанию пять минут. Новая загрузка прерывает ещё не начавшееся рецензирование. При команде «Повторить проверку в GitHub» рецензирование запускается немедленно.
- Глубина рецензирования. Объём текста, который рецензент может прочитать и отредактировать за один раз.
Система придерживается правил рецензирования Coroid и правил, указанных в папке вашего репозитория.
review-rules Проект, следующий общим настройкам организации, использует их параметры, как и любой другой элемент управления.
Если что-то идёт не так
Три переключателя в разделе настроек по умолчанию организации превращают ошибки в задачи для всех проектов. Каждый переключатель запускает отдельную автоматизацию, перечисленную в разделе Factory под названием «Автоматизации»; агент анализирует код и создаёт задачу, которая проходит тот же этап спецификации, сборки, проверки и рецензирования, что и любая другая задача.
| Переключатель | Когда | Что делает агент |
|---|---|---|
| При сбое задачи создать задачу на исправление | Сбой задачи | Агент выясняет причину сбоя; если она связана с кодом, создаёт задачу на его исправление. |
| При сбое развёртывания — провести расследование | Сбой развёртывания | Агент анализирует изменения в этой версии и создаёт задачу с описанием ошибки и рекомендациями по её устранению. |
| При откате релиза — спланировать исправление | Откат релиза | Открывает задачу, в которой фиксируется информация о том, что было откатено, почему и что необходимо изменить перед повторной поставкой. |
Отключение автоматизации приостанавливает её работу; включение снова возобновляет её. Любое изменение можно отменить. На странице автоматизации в Factory указано, что ею управляет функция Quality Control. Приостановка там равносильна отключению; изменение инструкций делает её уникальной после подтверждения, и переключатель больше не включает и не выключает её.
Ранее это были шаблоны в разделе Новая работа. Автоматизация, созданная на основе одного из них, продолжает работать. Если вы её не меняли, включение соответствующего переключателя возьмёт её под свой контроль вместо запуска второй копии. Если же вы её изменили, она останется вашей: строка переключателя будет содержать её название, и вы сможете настроить его так, чтобы он управлял ею.
Безопасный релиз
Проблема механизмов проверок не в их слабости, а в том, что добросовестная блокирующая проверка может приостановить все задачи в организации одновременно.
Безопасная последовательность:
- Добавьте проверку как рекомендательную.
- Дайте ей поработать над реальными задачами в течение недели-двух. Изучите, что она выявляет.
- Настройте её с учётом полученных результатов.
- Переведите в режим блокирующей для одного проекта.
- Разверните её шире, когда она начнёт корректно работать.
- 1Добавить шлюзКонсультативный режим
- 2Понаблюдать за ним неделю-двеКонсультативный режим
- 3Настроить его под выявленные сигналыКонсультативный режим
- 4Блокировать на одном проектеБлокирующий режимОдин проект
- 5Расширить область примененияБлокирующий режимБольше проектов
Версионирование и откат
Политики версионируются. Каждый переключатель создаёт новую версию, а её подтверждение позволяет отменить изменения, вернувшись к предыдущей версии; старые версии можно восстановить из истории версий расширенного редактора.
Возможность отката — причина, по которой можно смело принимать решения о публикации. Если новая проверка окажется некорректно настроенной, откат займёт одно действие, а не превратится в сложный процесс восстановления данных.
Исключения
Блокирующую проверку может отменить лицо, имеющее соответствующие полномочия. Такое исключение фиксируется: кто, когда и против чего его применил.
Следите за частотой применения исключений. Если проверка чаще всего отменяется при срабатывании, она не выполняет свою функцию, а лишь создаёт препятствия и лишнюю документацию. Либо исправьте проверку, либо удалите её.