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

10

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

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

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

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

Дэн Корнилеску
источник
Я продолжаю задаваться вопросом о правильном способе понимания этого вопроса (и вашей собственной рекомендации в вашем собственном ответе). Если бы я заменил «мониторинг» на «после фактов», а «предотвращение» на «предотвратить их», то был бы это более или менее тот же вопрос? Кроме того, может быть, вы можете добавить пример сценария, чтобы объяснить разницу?
Pierre.Vriens
@ Pierre.Vriens Это лучше?
Дан

Ответы:

6

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

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

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

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

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

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

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

Aurora0001
источник
Ну, что хорошего в том, что образ SW создается, но является ли DOA перспективным тестированием? Разработчики не могут проверить свои изменения кода, даже если они собираются, поэтому они будут так же заблокированы. Поэтому в целом я бы распространял отклонение коммита на все, что не проходит минимальную проверку качества, выбранную путем уравновешивания двух противоречивых требований: как можно выше, чтобы максимизировать число разработчиков, защищенных от блокировки, и настолько низко, насколько это возможно, чтобы проверка QA задерживала не замедляйте процесс слишком сильно.
Дан
Примером этого может служить модель запроса на извлечение, в которой вы можете установить определенные ограничения на возможность объединения запроса на вытягивание или нет. Например, мы (моя компания) используем Atlassian Bitbucket Server, и есть варианты, требующие по крайней мере N количества подтверждений и X количества проходящих сборок для данной ветви, прежде чем разрешить объединение запроса на извлечение. Это не отвергает это прямо. Но предотвращает случайное слияние, когда тесты не пройдены или другие глаза еще не видели код.
Энди Шинн
@AndyShinn: Да, я нахожу это весьма полезным - GitHub также предлагает защищенные ветки и проверки на запросы , которые часто бывают полезны.
Aurora0001,
1
Один из аргументов в пользу того, что в ветвях функций допускается неработающий код, заключается в том, что он позволяет разработчикам отправлять код, над которым они работают, в репозиторий, даже если он еще не готов. Это может быть полезно для того, чтобы поделиться кодом с другими для ранних проверок кода / архитектуры до того, как все будет готово, помочь в устранении неполадок или для того, кто уходит в отпуск, чтобы поставить частично выполненную работу так, чтобы другие могли ее получить. Для функциональных веток я бы только помещал такие вещи, как линтеры и хуки перед фиксацией.
брадим
2

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

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

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

Адриан
источник
«Если ветвь обновлена ​​в своем восходящем потоке (куда PR сливается), и ее тесты пройдены, то они все равно пройдут после объединения» - Почему? Слияние - это разрыв, оно приносит неизвестные. Как и конфликты - код может даже не скомпилироваться, пока не будет решен. Вам нужно запустить тесты и подтвердить, что они проходят для любого слияния веток. Я бы сказал, даже для быстрой перемотки вперед, если вы хотите быть осторожным. См. Apartsw.com/insights/2016/11/16/…
Дэн
Хм, да, такая гарантия возможна, проверьте мой ответ. Ну, может быть, я должен уточнить: под регрессией я подразумеваю результаты хуже, чем исходные результаты ветвления (и игнорируя возможность ложных срабатываний, к ним нужно обращаться, поскольку они могут исказить базовый уровень, разрушая все это и требуя вмешательства человека). Прерывистые ложные негативы - это просто неприятность, замедляющая ситуацию, но с ней можно справиться.
Дан
Вы не можете гарантировать отсутствие регрессий, вы можете только гарантировать отсутствие обнаруженных регрессий. Если изменение вызывает регрессию, не обнаруженную тестом, это регрессия, о которой инструмент CI не может дать никаких гарантий. И хотя объединение двух наборов изменений приносит неизвестные, вы можете сделать это в ветви функций (путем объединения входящего потока) перед объединением другого направления. Если источник соответствует цели, это простое слияние (ускоренная перемотка вперед), и после этого целевое состояние будет идентичным состоянию источника до слияния, следовательно, если тесты пройдены до, они пройдут после.
Адриан
Расщепление волосков. Инструмент CI может быть сконфигурирован с тестом для обнаружения и, следовательно, защиты от регрессии, которая вас интересует. Я не буду много спорить о слияниях - моя цель - как можно больше избегать их, они просто проблемы в целом :)
Дан
Я хочу сказать, что это не инструмент CI, предлагающий такую ​​защиту, а вы, написав тесты. Инструмент CI не может предоставить никаких гарантий, кроме предоставляемых вами тестов.
Адриан,
1

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

coderanger
источник
Но Reitveld, кажется, является инструментом совместного анализа кода, а не инструментом CI, я что-то упустил? Это то, на что я смотрел: github.com/rietveld-codereview/rietveld
Дан
Zuul, кажется, действительно связан, я изучу это ближе.
Дан
Он не выполняет тестирование, но он обрабатывает некоторые аспекты управления филиалами, выступая в качестве системы привратника, что является лучшим способом предотвратить проникновение плохого кода путем блокировки слияния.
Coderanger
Я понимаю что ты имеешь ввиду. Ну, это может помочь с общим качеством кода, но само по себе не дает никакой гарантии. Два совершенно хороших изменения, которые проходят все проверки QA независимо, могут все еще вызвать поломки, когда они встречаются в филиале.
Дан
1

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

Дэнни Гуссен
источник
Это работает, но только если вы не разрешаете 2-му слиянию запускать проверки качества до завершения предыдущего слияния, иначе 2-е слияние не увидит 1-е, оставляя место для регрессий. Другими словами, слияния (включая проверки QA) должны быть полностью сериализованы, что не подходит для больших команд.
Дэн Корнилеску
0

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

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

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

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

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

Дэн Корнилеску
источник
Хорошо, что вы добавили заявление об отказе от ответственности, но лично я считаю, что задавать вопрос и отвечать на него самостоятельно, рекламируя свою собственную компанию или продукты, можно считать формой спама.
THelper
Я задал вопрос о мета, разрешено ли это: meta.devops.stackexchange.com/q/59
THelper
SnapCI сделал это тоже. ПОКОЙСЯ С МИРОМ.
paul_h
@paul_h, если я что-то упустил, SnapCI и его рекомендованная замена GoCD основаны на проверках после фиксации (вызванных опросом SCM), поэтому они все еще доступны только для мониторинга. За исключением, может быть, для PR-проверок, но если эти проверки не будут полностью сериализованы, они могут только снизить частоту регрессии, но не устранить их полностью.
Дан
Дэн, не голосую, нет, крючки. И в недолгую пиар-ветку, которая еще не слилась в trunk / master - trunkbaseddevelopment.com/game-changers/…
paul_h