Упрощение разработки программного обеспечения с помощью Git

Три совета о том, как подогнать Git под рабочий процесс agile (и наоборот)

Laura Daly Laura Daly
Просмотр тем

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

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

Подсказка

Git — это распределенная система управления версиями (DVCS). В отличие от систем CVS или Subversion (SVN), Git позволяет разработчикам создавать собственные копии командного репозитория, который хранится вместе с основной базой кода. Эти копии называются ветками, и когда работа над веткой завершена, отправить изменения обратно в базу кода не составляет труда.

Ветвление в Git | Atlassian — тренер по agile

Совет 1. Начните рассматривать задания как ветки Git

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

Здесь-то в рабочем процессе agile и появляется Git. В компании Atlassian принято создавать новую ветку для каждой отдельной задачи. Свою ветку получает каждое изменение кода, будь то новая функция, исправление бага или небольшое улучшение кода.

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

Подсказка

Помимо веток для заданий можно создавать и другие виды веток Git, в том числе и одновременно. Например, можно создавать ветки релизов. Это позволяет разработчикам определить постоянный объем работ, запланированных для того или иного релиза, и закрепить его, не задерживая при этом других разработчиков, которые занимаются будущими релизами.

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

Подробное представление веток Git | Atlassian — тренер по agile

Совет 2. Пользуйтесь тем, что каждую ветку из множества можно тестировать по отдельности

Когда работа над веткой достигает логического конца и в ней можно проводить проверку кода, Git приходит на помощь в еще одной важной процедуре agile-разработки: тестировании. Успешные agile-команды выполняют проверку кода и автоматическое тестирование (с помощью конвейера непрерывной интеграции или непрерывного развертывания). С Git выполнять проверку кода и тестирование проще, поскольку в этой системе разработчики могут без труда уведомить всю остальную команду о том, что результаты работы в ветке готовы к проверке и нуждаются в ней, с помощью запроса pull. Проще говоря, отправить запрос pull — это все равно, что попросить другого разработчика выполнить слияние одной из ваших веток с главной веткой и сообщить ему, что она готова к тестированию.

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

Подсказка

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

Совет 3. С Git agile-разработка становится прозрачной и качественной

Git и agile используются вместе для повышения эффективности, проведения тестирования, автоматизации и повышения гибкости в целом. Рабочий процесс agile можно считать завершенным после слияния функциональной ветки с главной. Если слияние выполняется путем запросов pull, значит, по мере готовности кода можно, опираясь на выводимую системой информацию, убедиться, что работа действительно завершена, что остальные участники команды утвердили новый код и что он готов к выпуску. Благодаря этому работа в agile-командах идет без остановки и уверенно, с частыми релизами, что и есть признак успешной agile-команды.

Подсказка

Главное в agile-разработке — регулярно выпускать новые версии. Чтобы заставить систему Git работать на рабочий процесс agile, нужно, чтобы главная ветка была всегда в зеленом состоянии. Тогда, если работа над функцией еще не закончена, его поставку нужно отложить до следующего релиза. Если циклы релиза длятся небольшой промежуток времени, это не станет причиной проблем.

продолжение темы
Branching