Существует ли инструмент КИ, который гарантирует отсутствие регрессии в уровне качества отрасли?

Традиционно системы CI осуществляют мониторинг уровней качества только в ветви интеграции, выполняя проверки QA на базе кода, где изменения уже зафиксированы, отслеживая регрессии и отправляя уведомления для вмешательства человека.

Но когда эти регрессии обнаружены, филиал уже испытывал проблемы, по крайней мере, с момента начала соответствующей проверки QA, и будет оставаться в таком состоянии (или даже ухудшаться!) До тех пор, пока не будут идентифицированы все виновные, исправлены их исправления и не произведена новая проверка QA. подтверждает, что уровень качества филиала был восстановлен. Все это время ветку можно считать заблокированной для нормального развития.

Существует ли инструмент CI, способный на самом деле предотвратить такие регрессии, который бы выполнял проверки QA перед фиксацией и разрешал коммиты только тогда, когда кодовая база, обновленная соответствующими коммитами, также проходила бы эти проверки QA до фиксации, таким образом гарантируя минимум уровень качества отрасли?

Обновление: предполагается, что подходящие автоматизированные проверки QA с соответствующим охватом, чтобы иметь возможность обнаруживать соответствующие регрессии, доступны для вызова с помощью инструмента (ов) CI.

Насколько я могу судить, вы ищете инструмент, который будет отклонять коммиты, которые нарушают сборку - инструмент CI, вероятно, не сможет предотвратить регрессию, фактически исправив ваш код, но он может помешать вам добавить плохой код в хранилище.

У Atlassian есть несколько интересных применений хитов Git :

Хуки предварительного приема на стороне сервера являются особенно мощным дополнением к непрерывной интеграции, поскольку они могут помешать разработчикам подтолкнуть код к мастеру, если код не удовлетворяет определенным условиям - например, элитным защитникам ниндзя, защищая его от плохого кода.

Если вы используете Git, ловушки очень мощные (и есть аналогичные ловушки для SVN , Mercurial и других систем контроля версий), и вам может быть полезно использовать их для запуска проверок перед фиксацией.

В документации Git есть страница по созданию ловушки для отклонения толчков, если они не соответствуют определенным критериям, которые можно легко адаптировать к этому варианту использования.

Однако многие люди утверждают, что отклонение коммитов - плохая идея для featureветки - вы будете просто тратить время на борьбу с системой CI, когда сборка по какой-то причине не работает, вместо того, чтобы фактически исправлять ошибку.

В masterветке может иметь смысл отказаться от разорванных слияний, потому что вы, возможно, захотите убедиться, что оно всегда собирается. Для featureотрасли, вы будете неизбежно ломать вещи, и так как код не собирается в производство в настоящее время , это имеет смысл только , чтобы предупредить вас , чем на самом деле отклонить ваше обязательство в целом.

Ни один инструмент не может гарантировать отсутствие регрессий - это зависит гораздо больше от ваших тестов, чем от инструмента, который их выполняет. Однако вы можете помочь предотвратить попадание регрессий в ветку интеграции. Вы можете сделать это с помощью ловушек перед фиксацией, но часто это проще с запросами на удаление (которые, мы надеемся, вы уже используете для рецензирования кода).

Если ветвь обновлена ​​в своем восходящем потоке (куда PR сливается), и ее тесты пройдены, то они все равно пройдут после объединения; состояние целевой ветви после слияния будет соответствовать состоянию исходной ветви до слияния.

Как правило, не особенно сложно (в зависимости от используемых инструментов) указать, соответствует ли исходная ветвь в PR цели, и имеет ли она промежуточную сборку CI. Вы можете использовать это как требование (политикой и / или принудительно применяя в программном обеспечении) для объединения запроса извлечения.

Истинные инструменты непрерывной интеграции (в отличие от просто непрерывного тестирования), такие как Reitveld и Zuul, могут помочь, хотя они так же хороши, как тесты, которые вы пишете, и обзоры кода, которые вы делаете.

Используйте GitLAB, вы можете установить в настройках проекта, чтобы разрешить слияние только при успешном конвейере, поэтому можете иметь действительно непрерывную интеграцию, сочетая это с добавлением вашего QA в список утверждений слияния и с динамическими средами, вы можете иметь гарантию качества прежде чем слиться с мастером.

ApartCI - это система CI, разработанная специально для предотвращения регрессий, что гарантирует постоянный или повышенный уровень качества филиала. Все еще в бета-версии.

Он организует централизованные проверки перед фиксацией таким образом, чтобы гарантировать, что изменение зафиксировано только после того, как оно будет проверено, вместе со всеми другими изменениями, принятыми до него, для достижения или превышения последнего уровня качества филиала.

Это ключевое отличие по сравнению с традиционными предварительными проверками, проводимыми разработчиками, часто выполняемыми параллельно, что оставляет место для регрессий, вызванных мешающими изменениями, которые никогда не тестировались вместе.

Этот инструмент также предназначен для простого масштабирования - он способен поддерживать очень высокий уровень поступающих изменений кандидатов и поддерживать 100/1000 разработчиков, работающих в одной и той же ветви интеграции.

Отказ от ответственности: я автор инструмента и основатель компании, предлагающей его. Извиняюсь за рекламу.