Среди команд разработчиков ПО Agile и DevOps наиболее популярна система управления версиями Git, которая составляет важную часть набора инструментальных средств DevOps. Эта система с открытым исходным кодом активно поддерживается, а благодаря универсальности ее можно использовать в рамках разнообразных рабочих процессов, с помощью которых та или иная команда разработчиков решает свои задачи. Поскольку система является распределенной (а не централизованной), она значительно повышает производительность. Так разработчики могут выполнять работу на собственных локальных устройствах и передавать изменения в общий репозиторий, только когда они будут готовы представить эти изменения команде.
Система Git подходит для применения в командах Agile- и DevOps-разработки не только за счет универсальности и распределенности. Ее ключевые функции также являются хорошим подспорьем в деле Agile и DevOps и расширяют возможности разработчиков. Git можно рассматривать как составную часть Agile- и DevOps-разработки. Изменения можно отправлять вперед по конвейеру развертывания быстрее, чем при работе с монолитными релизами и централизованными системами управления версиями. Git работает так же, как работают (и как должны работать) Agile- и DevOps-команды.
Совет 1. Начните рассматривать задания как ветки Git
Git вступает в игру, когда запланированные функции проработаны, добавлены на дорожную карту продукта и команда разработчиков готова приступить к работе. Но прежде чем рассказать о применении этой системы, быстро пробежимся по основам Agile-разработки функциональных возможностей. Команды по продукту, проектированию, контролю качества и разработке проводят совещание, предваряющее начало работы над возможностью. На нем участники приходят к общему пониманию того, какой будет новая возможность (то есть, прорабатывают требования к ней), каким будет объем работ по проекту и на какие задания следует разделить работу над возможностью, чтобы реализовать ее. В результате эти задания, также известные как пользовательские истории, назначаются отдельным разработчикам.
На этом этапе рабочего процесса Agile и появляется Git. В компании Atlassian принято создавать новую ветку для каждой отдельной задачи. Свою ветку получает каждое изменение кода, будь то новая возможность, исправление бага или небольшое улучшение.
Создавать ветки легко, и с помощью них команды могут без труда совместно работать в рамках единой центральной базы кода. Когда разработчик создает ветку, он получает собственную независимую версию базы кода, в которой можно совершать изменения. Когда возможности делятся на пользовательские истории, а затем ветки, команда Agile-разработчиков получает способ выполнять задания по отдельности и работать над одним и тем же кодом, но в разных репозиториях более эффективно. Никому не приходится выполнять одну и ту же работу дважды, и, поскольку сотрудники могут сосредоточить внимание на небольших блоках работы в репозиториях, отделенных от главного репозитория, в процессе разработки возникает не так много зависимостей, способных его замедлить.
Помимо веток для заданий можно одновременно создавать и другие виды веток Git, например ветки релизов. Это позволяет разработчикам определить постоянный объем работ, запланированных для того или иного релиза, и закрепить его, не задерживая при этом других разработчиков, которые занимаются будущими релизами.
Создав ветку релиза, нужно регулярно выполнять ее слияние с главной веткой, чтобы результаты работы над функцией были включены в будущие релизы. Чтобы связанные с этим затраты ресурсов были минимальными, рекомендуется создавать ветку релиза как можно ближе к запланированной дате релиза.
Совет 2. Пользуйтесь тем, что каждую ветку из множества можно тестировать по отдельности
Когда работа над веткой достигает логического завершения и в ней можно проводить проверку кода, Git приходит на помощь в еще одной важной процедуре agile-разработки — тестировании. Успешные agile- и DevOps-команды выполняют проверку кода и автоматическое тестирование (с помощью конвейеров непрерывной интеграции или непрерывной поставки). С Git выполнять проверку кода и тестирование проще, поскольку в этой системе разработчики могут без труда уведомить всю команду о том, что результаты работы в ветке готовы к проверке и нуждаются в ней, с помощью запроса pull. Проще говоря, отправить запрос pull — это все равно что попросить другого разработчика выполнить слияние одной из ваших веток с главной веткой и сообщить ему, что она готова к тестированию.
При использовании соответствующих инструментов сервер непрерывной интеграции может создавать и тестировать запросы pull до слияния. При этом вы можете быть уверены, что слияние не приведет к проблемам, а значит, в целом будет проще исправлять баги и устранять конфликты, поскольку система Git способна после разветвления отличать ветку от основной базы кода.
Если функциональная ветка долго находится в работе и редко сливается с главной веткой, у вас могут возникать проблемы с применением Agile и выполнением итераций. Если вы работаете над функциональной веткой уже долгое время, помните, что у вас есть уже две независимо изменяющиеся версии базы кода и что это в итоге приведет к росту количества багов, требующих исправления, и конфликтов. Лучше всего не затягивать работу над функциональными ветками. Для этого можно разбивать пользовательские истории на более простые задания, тщательнее планировать спринты и чаще выполнять слияние кода, чтобы поставлять новые функции посредством функциональных флажков.
Совет 3. С Git agile-разработка становится прозрачной и качественной
Git и Agile используются вместе для повышения эффективности, проведения тестирования, автоматизации и повышения гибкости в целом. Рабочий процесс Agile можно считать завершенным после слияния функциональной ветки с главной. Если слияние выполняется путем запросов pull, значит, по мере готовности кода можно, опираясь на выводимую системой информацию, убедиться, что работа действительно завершена, что остальные участники команды утвердили новый код и что он готов к релизу. Благодаря этому работа в agile-командах идет без остановки и уверенно, с частыми релизами, что и есть признак успешной команды, следующей принципам agile.
Главное в agile-разработке — регулярно выпускать новые версии. Чтобы система Git эффективно поддерживала рабочий процесс Agile, нужно, чтобы главная ветка была всегда в зеленом состоянии. И если работа над функцией еще не закончена, ее поставку нужно отложить до следующего релиза. Если у вас короткие циклы релиза, это не составляет проблемы.
