The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Несколько дней назад моя статья Почему непрерывная интеграция не работает была опубликована на DevOps.com. Практически в тот же день я получил несколько сильно негативных критик в Twitter.
Вот мой ответ на не заданный вопрос:
Несмотря на то, что у меня есть опыт в этой области, я не буду использовать его в качестве аргумента. Вместо этого я попытаюсь полагаться только на логику.
Кстати, мой опыт включает пять лет использования Apache Continuum, Hudson, CruiseControl и Jenkins в более чем 50 проектах с открытым и коммерческим исходным кодом. Кроме того, несколько лет назад я создал сервис непрерывной интеграции под названием fazend.com, который был переименован в rultor.com в 2013 году. В настоящее время я также активно использую Travis и AppVeyor.
Идея проста и очевидна. Каждый раз, когда вы создаете новый коммит в ветке “master” (или “/trunk” в Subversion), сервер (или сервис) непрерывной интеграции пытается собрать весь продукт. “Сборка” означает компиляцию, модульное тестирование, интеграционное тестирование, анализ качества и т.д.
Результат может быть либо “успехом”, либо “провалом”. Если это успех, мы говорим, что “сборка прошла успешно”. Если это провал, мы говорим, что “сборка сломана”. Сборка обычно сломается, потому что кто-то исправляет ее, внедряя новый код, который делает ранее прошедшие модульные тесты неудачными.
Это техническая сторона проблемы. Она всегда работает. Ну, у нее могут быть проблемы, такие как жестко закодированные зависимости, отсутствие изоляции между средами или конфликты параллельной сборки, но в этой статье речь не о них. Если приложение хорошо написано и его модульные тесты стабильны, непрерывная интеграция - это просто. Технически.
Давайте рассмотрим организационную сторону.
Непрерывная интеграция - это не только сервер, который собирает, но и управленческий/организационный процесс, который должен “работать”. Быть процессом, который работает, означает то, что сказал Джез Хамбл в Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, на странице 55:
Это то, что не работает и не может работать.
Как мы видим, непрерывная интеграция заключается в том, чтобы остановить всю команду разработки и исправить неудачную сборку. Позвольте мне повторить. Как только сборка сломана, каждый должен сосредоточиться на ее исправлении и сделать коммит, который вернет сборку в стабильное состояние.
Теперь мой вопрос: кто, в активно работающей команде, может понадобиться это?
Владелец продукта, который заинтересован в том, чтобы как можно скорее запустить новые функции на рынок? Или, может быть, менеджер проекта, ответственный за соблюдение сроков? Или, возможно, программисты, которые ненавидят исправлять ошибки, допущенные кем-то другим, особенно под давлением?
Кому нравится эта непрерывная интеграция и кому она нужна?
What Happens In Reality?
Я могу сказать вам. Я видел это несколько раз. Сценарий всегда одинаковый. Мы просто начинаем игнорировать статус сборки непрерывной интеграции. Сборка либо успешная, либо сломанная, и мы продолжаем делать то, что делали раньше.
Мы не останавливаемся и не исправляем это, как рекомендует Джеф Хамбл.
Вместо этого мы игнорируем информацию, которая приходит от сервера непрерывной интеграции.
В конечном итоге, возможно, завтра или в понедельник, мы попытаемся найти свободное время и исправим сборку. Только потому, что нам не нравится красная кнопка на панели инструментов и мы хотим сделать ее зеленой.
Да, есть и другая сторона этой медали. Мы можем попытаться обеспечить дисциплину в команде. Мы можем установить строгое правило, что наша сборка всегда должна быть чистой, и тот, кто ее сломает, получит некое наказание.
Попробуйте сделать это, и вы получите разработку, основанную на страхе. Программисты будут бояться совершать какие-либо коммиты в репозиторий, потому что они будут знать, что если они вызовут сбой сборки, им придется извиниться, по крайней мере.
Строгая дисциплина (которой я являюсь ярым сторонником) в этом случае только ухудшает ситуацию. Весь процесс разработки замедляется, и программисты держат свой код в себе как можно дольше, чтобы избежать возможных сбоев сборки. Когда приходит время делать коммит, их изменения настолько масштабны, что слияние становится очень сложным и иногда невозможным.
В результате вы получаете много кода, написанного кем-то, но никогда не зафиксированного в master, из-за этого фактора страха.
Я писал об этом раньше; это называется «только для чтения» главная ветка.
Это просто - запретить кому-либо сливать что-либо в master и создать скрипт, который может вызвать любой. Скрипт будет сливать, тестировать и фиксировать изменения. Скрипт не будет делать исключений. Если какая-либо ветка не проходит хотя бы один модульный тест, вся ветка будет отклонена.
Другими словами: поднимать красный флаг до того, как код попадет в master.
Это решает все проблемы.
Во-первых, сборка всегда чистая. Мы просто не можем сломать ее, потому что никто не может делать коммит, если его код не поддерживает чистую сборку.
Во-вторых, нет страха сломать что-либо. Просто потому, что технически вы не можете этого сделать. Все, что вы можете сделать, это получить отрицательный ответ от скрипта слияния. Затем вы исправляете ошибки и говорите скрипту попробовать снова. Никто не видит этих попыток, и вам не нужно извиняться. Фактор страха исчезает.
Кстати, попробуйте использовать rultor.com, чтобы применить этот принцип «только для чтения» главной ветки в вашем проекте.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:44
