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