Сверхмощная непрерывная поставка с Git

По правде говоря, суть не в том, что Git — оптимальное решение для непрерывной поставки. Речь идет о том, что для непрерывной поставки отлично подходят рабочие процессы на основе ветвления, а инструмент Git идеален для таких процессов. Рабочий процесс создания веток и их слияния является лучшим другом непрерывной поставки: он упрощает устранение сложных багов, позволяет пробовать новые технологии и дает возможность писать код для новых возможностей с нуля, не опасаясь, что эти изменения не позволят вашим коллегам по команде продвигаться вперед с их собственными заданиями.

Конечно Subversion и другие традиционные системы контроля версий тоже позволяют создавать ветки. Но давайте отвлечемся от этого на минуту и подумаем о злом двойнике ветвления: о слиянии.

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

Git, с другой стороны, отлично подходит для отслеживания изменений разных версий файлов в разных ветках. Система всегда знает, как выглядел общий предок файла. Можно сказать, в Git есть встроенный GPS, который позволяет системе управлять слияниями, не прерываясь и не запрашивая у вас постоянно дальнейших указаний.

С Git вы можете использовать мощные возможности ветвления таким образом, который был бы непрактичен при работе в Subversion. Накладные расходы, связанные с ветвлением и слиянием, настолько незначительны, что создавать ветки, существующие лишь день или два, становится не только возможно, но и полезно.

Хорошо, допустим. Но почему именно создание веток является настолько мощным подходом для непрерывной поставки?

К примеру, все команды разработчиков в Atlassian договорились не отправлять коммиты напрямую в главные и стабильные ветки. Каждый делает свою работу в отдельных ветках. На самом деле, мы настолько оптимистично смотрим на ветвление, что решили создавать отдельные ветки для каждой задачи Jira, которую решаем (подробнее об этом чуть позже).

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

Ветки позволяют принимать дополнения от людей, не входящих в команду

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

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

Правильное использование веток = четкое отслеживание проекта

Текущий тренд — создавать ветки разработки для всех реализуемых историй, исправлений багов и заданий (например, задач в Jira). В Atlassian модель, где каждой задаче соответствует отдельная ветка, была внедрена много лет назад, и мы ни разу об этом не пожалели. Она стала популярной и среди наших клиентов.

Создание ветки для каждой задачи позволяет легко выбирать, какие изменения необходимо поставить в рабочую среду или включить в релиз. Поскольку вы не выполняете слияния изменений в главную ветку, у вас есть возможность выбирать, что будет в нее добавлено и когда. Вы можете поставить MVP-версию возможности уровня «эпик» плюс одну возможность из разряда «не помешает», а не ждать, пока будут готовы все подобные возможности. Или же поставить единичное исправление бага, сделав это в рамках обычного релиза. Даже если исправление срочное, вам не придется иметь дело с переполохом, когда нужно отменять другие изменения, не готовые к поставке, только чтобы выпустить то самое исправление.

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

При таком подходе не только не допускается отправка непроверенного кода в главную ветку (поскольку в имя ветки включается соответствующий ключ задачи Jira, а также имя или инициалы разработчика), но и всегда обеспечивается понимание того, как движется работа над каждой задачей.

Обратите внимание на принципы наименования, используемые на приведенном выше рисунке: уникальный ключ реализуемой задачи Jira плюс краткое, понятное человеку описание того, о чем эта задача. В результате менеджер по релизам или другая заинтересованная сторона может посмотреть на репозиторий, показанный выше, и сразу понять, что пользовательская история, отслеживаемая по номеру AMKT-13952, готова к релизу: видно, что было выполнено ее слияние с главной веткой. Вот что значит возможность отслеживания без ручного труда — ура!

Отличный вопрос! Я расскажу об этом кратко, не вдаваясь в подробности, так как другие статьи на этом сайте углубляются в каждый этап.

• Создайте ветку для задачи, над которой будете работать. Добавьте ключ задачи Jira в имя ветки, чтобы было понятно, для чего она предназначена. Если вы пользуетесь инструментами Atlassian, такими как Bitbucket или Bitbucket Pipelines, они подхватят этот ключ задачи и свяжут между собой задачу, вашу ветку, все ваши коммиты, сборки, запросы pull и развертывания, относящиеся к данной задаче. Короче говоря, ключи задач творят чудеса.
• Вносите свои изменения в ветке. Это ваш собственный маленький мир, где вы можете делать все что угодно. Пробуйте новое. Ломайте. Это все неважно, потому что следующий пункт…
• Реализуйте непрерывную интеграцию в своей ветке. Здесь вам и вашей команде надо решить, следует ли выполнять специализированные тесты (например, нагрузочные тесты или сквозные тесты на основе пользовательского интерфейса) и нужно ли автоматически запускать прогон тестов каждый раз, когда в ветку вносятся изменения. Команды Atlassian обычно выполняют модульные и интеграционные тесты в ветках разработки.
• Регулярно обновляйте свою ветку, используя последние версии главной ветки. Для этого можно использовать операцию rebase или коммит ветки. Выбирайте на свой вкус. (Только не выполняйте операцию rebase для ветки, с которой, помимо вас, работают другие разработчики, — этим вы их сильно рассердите.) В любом случае вы обнаружите конфликты интеграции прежде, чем выполните слияние, что, в свою очередь, поможет поддерживать порядок в главной ветке.
• Создайте запрос pull, когда будете готовы к слиянию. Это значит, что внедрение завершено, вы осуществили pull изменений от членов вашей команды, устранили все возникшие конфликты, а все тесты в вашей ветке проходят успешно.
• Выполняйте слияние и развертывание по запросу. Некоторые команды предпочитают автоматически поставлять каждое изменение, как только выполнено его слияние в главную ветку и пройдены все тесты. Это модель непрерывного развертывания. Другие команды хотят, чтобы решение о поставке каких-либо изменений и времени такой поставки оставалось за человеком. Выбор только за вами.

Вот такая картина. Процессы на основе веток упрощают непрерывную поставку, а Git избавляет от проблем при работе с ветками. Читайте дальше, чтобы глубже погрузиться в настройку репозитория Git для работы с CD и узнать о том, как реализовать все эти идеи на практике с помощью инструментов Atlassian. Увидимся на следующей странице!