Ничто так не усложняет жизнь инженеру, как ужасный ад слияния. Необходимость переписывать код и тратить часы на попытки слияния с main утомительны, напряжены и тратят впустую инженерные ресурсы.
К счастью, есть решение; Магистральная разработка — это стратегия разработки, в которой используется только одна ветвь. При разработке на основе магистрали разработчики используют короткие ветки для обновления основной магистрали, что также известно как стратегия ветвления выпуска. Чем больше команда, тем короче должны быть эти ветки, так как вы хотите видеть обновления, которые постоянно сливаются с вашей основной веткой, также известной как ваш ствол.
Это помогает повысить производительность рабочего процесса разработчиков, сводит к минимуму риск ошибок и дает разработчикам уверенность при отправке нового кода. Мы углубимся в то, когда вы можете использовать разработку на основе ствола, почему вы должны ее использовать, альтернативы разработки и как вы можете легко реализовать эту стратегию с помощью флагов функций.
Оглавление
- Что такое транковая разработка?
- Варианты использования стратегии ветвления
- Типы стратегий ветвления
- Преимущества использования транковой разработки
- Плюсы и минусы магистральной разработки
- Использование флагов функций для магистральной разработки
- Построить или купить
Что такое транковая разработка?
Разработка на основе магистрали — это стратегия ветвления, при которой все разработчики работают над одной и той же «магистралью» общего кода. Ствол всегда находится в состоянии выпуска, а это значит, что хотя бы раз в день разработчики должны интегрировать свои изменения в транк. Это достигается с помощью недолговечных ветвей функций, связанных с задачами проекта.
Это стратегия, которую команда разработчиков программного обеспечения использует при написании, слиянии и отправке кода, которая устраняет ад слияния. Сохраняя небольшое количество измененных строк, менее вероятно, что изменение другого разработчика вызовет конфликт. При работе в команде разработчики должны делиться своими изменениями друг с другом. Ветвление — это стратегия, которая помогает командам управлять своей работой. Он определяет, как команда управляет ветвями, чтобы добиться максимальной эффективности, не мешая друг другу. Наилучшей стратегией ветвления является разработка на основе ствола.
Чтобы выполнять разработку на основе магистрали, вам нужны более короткие ветки, а флаги функций, естественно, позволяют создавать короткие ветки без риска. С помощью флагов функций вы можете вносить небольшие изменения, такие как добавление части функции, исправление ошибки или добавление небольшого раскрывающегося списка на ваш сайт в процессе производства. Ваши обновления будут в основном, но их просто не будет видно. Они также позволяют вам работать над большими изменениями. Вы можете иметь более крупные функции в main, но скрывать их за флагом функции. Это позволяет вам медленно обновлять функцию в main, но отключать ее в рабочей среде для ваших пользователей, поскольку ваш ствол всегда готов к работе.
Филиалы функций
Функциональная ветвь может длиться столько, сколько необходимо, в зависимости от стратегии ветвления, но для разработки на основе магистрали эти ветки должны длиться не более одного дня. Ветка часто используется одним разработчиком для своих изменений, но ею также можно поделиться с другими разработчиками. Ветви функций объединяются в ствол, когда они готовы.
Чтобы использовать транковую разработку, вам нужно, чтобы проект был разбит на задачи, требующие усилий менее одного дня. Это означает, что каждый день разработчик может объединять свою ветку функций с основным стволом.
Независимо от того, что они делают в своем личном репозитории, по крайней мере один раз в день они должны интегрировать свои изменения в общий ствол. Разработчики постоянно проверяют, что делают другие члены команды. Эта практика заставляет их видеть изменения и реагировать на них. Когда это постоянно, это заставляет сотрудничать в отношении качества и состояния кодовой базы.
По мере того, как непрерывная доставка и DevOps становятся все более заметными и даже необходимыми для многих групп разработчиков программного обеспечения, транковая система лучше всего соответствует этим современным подходам к доставке. На самом деле, разработка на базе магистралей является необходимым условием для CI/CD.
Варианты использования стратегии ветвления
Точная поставка программного обеспечения является обязательным условием, и лучший способ обеспечить точность — убедиться, что все в вашей команде следуют одному и тому же процессу. Стратегия ветвления лучше всего подходит для совместной работы, эффективности и соблюдения сроков. Без стратегии или неправильной стратегии ваша команда может потерять часы или дни усилий.
Ежедневный рабочий процесс
Типичный повседневный поток разработчиков включает небольшие и несрочные изменения; обычно они составляют основную часть всех изменений, которые вносит разработчик. Ваша стратегия для этого потока должна обеспечивать надлежащую координацию между разработчиками и поддерживать все соответствующие политики. Например, если у вас есть автоматизированные тесты, запросы на вытягивание или процедуры развертывания, они должны координироваться в этом рабочем процессе. Все эти изменения также управляются извне в системе управления рабочими процессами, такой как JIRA, чтобы обеспечить прозрачность всей команды и гарантировать, что каждый будет в курсе своих задач.
При работе с JIRA каждый тикет помогает составить небольшую часть более крупной задачи. Точно так же маленькие флаги функции могут быть созданы под более крупным флагом функции. Это позволяет командам работать над кодом в основном, скрывая его.
Сосредоточение внимания на выполнении одной задачи в день не только помогает вашему развитию, но и повышает производительность. Люди более продуктивны, когда они сосредоточены на одной задаче. 20% производительности теряется за каждую дополнительную задачу, которую кто-то пытается выполнить одновременно.
Чрезвычайные ситуации
Экстренное исправление — это срочное исправление ошибки, которое необходимо устранить быстро. Чтобы разработчик мог это сделать, поток должен учитывать их потребности. Это означает, что ваш процесс должен иметь возможность для разработчика внести срочные изменения в производственную среду, следуя при этом стандартному рабочему процессу разработки.
Эта стратегия позволяет стволу всегда быть готовым к запуску в производство и, следовательно, к исправлению, а также к немедленному объединению и выпуску без необходимости регрессионного тестирования всех других изменений, которые есть в выпуске, но скрыты флагом функции.
Изменения всех размеров
По мере развития отрасли все больше внимания уделялось небольшим изменениям и ограниченным размерам партий. Но бывают случаи, когда вам необходимо внести большие и сложные изменения, и ваша стратегия ветвления должна учитывать эти случаи.
Экспериментальные изменения
Разработчики хотят быть уверенными в изменениях кода, и если они пробуют новую библиотеку или фреймворк, они могут быть обеспокоены тем, как они интегрируются с их кодовой базой. При ветвлении важно учитывать экспериментальные изменения. Например, вы можете решить, что ваше изменение не будет выпущено немедленно, но все же необходимо поделиться им с другими разработчиками.
Типы стратегий ветвления
Модель ветвления Git
У каждого репозитория Git есть магистраль, которую сегодня обычно называют основной. Разработчики могут использовать множество различных стратегий ветвления, когда речь идет о стволе и времени внесения в него изменений. Время внесения изменений в код и используемая стратегия ветвления также зависят от конкретной используемой системы контроля версий.
Отдел развития
Ветка разработки используется для хранения изменений, сделанных разработчиками, прежде чем они будут готовы к развертыванию в ветке выпуска. Эта ветвь никогда не удаляется. Фиксация в ветке разработки инициирует развертывание в тестовой среде. Ветка разработки и ствол часто интегрируются в двух направлениях, поэтому они постоянно обновляются и интегрируются.
Ветки выпуска
Ветки релиза — это ветки репозитория Git, в которых новая функция готова к переносу в рабочую среду. Ветвь релиза может быть либо краткосрочной, либо долгоживущей в зависимости от стратегии. В любом случае ветвь выпуска отражает набор изменений, которые вносятся в рабочую среду.
В процессе разработки иногда случаются аварийные баги. В этом случае можно создать ветку исправления. Это недолговечная ветвь, которая используется для исправления ошибок в основном продукте. Будут ли они недолговечными или долгоживущими, ветки исправлений чаще встречаются в командах с явно версионными продуктами.
Преимущества использования транковой разработки
Разработчики могут использовать разработку на основе магистрали, чтобы поставить непрерывную интеграцию в центр своего рабочего процесса. Это идеальный способ работы, потому что вы не пропустите ни дня без интеграции своих изменений. Это заставит каждого разработчика по-разному относиться к своей работе, что поможет членам команды лучше сотрудничать. Непрерывная интеграция также необходима для более быстрого внедрения инноваций.
Ключевой частью разработки на основе магистралей является использование недолговечных веток функций. Эти ветки поступают непосредственно из магистрали и предназначены для связи с одной функциональной частью, которую разработчик может выполнить в течение дня.
Рабочие процессы, связанные с запросами на вытягивание, автоматической сборкой и тестированием веток, сохраняются. Разница в том, что объединенный код после утверждения попадает прямо в ствол. Менять свою работу каждый день означает делать маленькие шаги вперед. Вы не можете вносить радикальные изменения в файлы кода и ломать локальную компиляцию. Вместо этого делайте каждый шаг вперед, внося все изменения в несколько файлов. Делая небольшие непрерывные изменения, вы сводите к минимуму влияние, которое ошибка в вашем коде может вызвать в рабочей среде.
Автоматические тесты чаще запускаются с короткоживущими ветвями, а сквозные тесты могут выявлять небольшие ошибки до того, как они станут большими. Иногда вам может потребоваться сначала внести изменения в непроизводственную среду, убедиться, что они работают правильно, а затем перенести их в рабочую среду. В других случаях вы можете захотеть, чтобы ограниченная группа клиентов сначала увидела ваши изменения, прежде чем открывать их всем. Разработка на основе магистрали с флагами функций дает разработчикам и менеджерам по продуктам больший контроль при выпуске своих изменений. С помощью флагов функций незавершенный код можно развернуть в рабочей среде так, что конечные пользователи его не увидят. Таким образом, флаги функций снижают риск развертывания незавершенного кода в рабочей среде, предоставляя возможность протестировать код в рабочей среде.
Плюсы и минусы магистральной и отраслевой разработки
Магистральная разработка
Плюсы
Одним из основных преимуществ разработки на основе магистралей является то, что ваша основная ветка всегда находится в состоянии готовности к выпуску. Это означает, что вы можете выпустить релиз в любое время, не беспокоясь о неготовности кода. Поскольку разработка на основе магистралей использует небольшие, но частые обновления, эти изменения легко просматривать и контролировать. Это создает высокий уровень коммуникации между разработчиками, поскольку изменения необходимо просматривать ежедневно.
Минусы
При разработке на основе магистралей могут появляться ошибки, поскольку полное регрессионное тестирование не выполняется при каждом слиянии. Кроме того, перед слиянием разработчикам необходимо дождаться, пока их небольшие изменения пройдут автоматизированные процессы сборки и тестирования.
Отраслевое развитие
Плюсы
При разработке на основе ветвей определенные функции могут разрабатываться изолированно от других, а тестирование определенных функций может выполняться в отдельных средах.
Минусы
При обратном слиянии в транке может возникнуть несколько проблем, вызывающих задержки, новые ошибки и требующих повторного тестирования, что отнимает много времени и ресурсов разработчика. Кроме того, просмотр запросов на вытягивание может быть длительным процессом из-за большого количества добавленного или измененного кода.
Использование флагов функций для магистральной разработки
При разработке на основе магистрали вы хотите, чтобы изменения были видны в процессе разработки для целей тестирования, но не в рабочей среде. Когда дело доходит до развертывания в разработке на основе магистрали, вы должны различать развертывание и выпуск. Развернутый код перемещается в среду для тестирования, а выпущенный код виден в среде. Первым шагом в связывании настроек приложения с вашей веткой является создание шва абстракции. Этот метод выпустит ваши изменения в непроизводственной среде, не выпуская их в производственной среде. Это дает вам уверенность в том, что ваши изменения не будут выпущены в рабочей среде, если вы этого не хотите, но также позволяет вам выпускать их в других ветках.
После того, как вы использовали флаги функций для управления выпусками между производственной и непроизводственной средами, пришло время сделать инкрементный выпуск в рабочую среду. Вы можете сделать канареечный выпуск, который вы начинаете с выпуска изменения только для внутренних или пилотных пользователей. Вы наблюдаете за влиянием этого изменения, а затем выпускаете его для все большего числа клиентов, пока, в конце концов, оно не будет выпущено для всей вашей группы клиентов.
Построить или купить
Команды инженеров могут подумать, что они могут создать свою собственную версию системы управления флагами функций, но этот процесс может занять много времени и ресурсов. Создание надежной системы пометки функций отвлекает внимание от основной компетенции организации и команды. Тем не менее, для инженерных групп по-прежнему важно иметь доступ к этому уровню управления флагами функций. Команда разработчиков программного обеспечения захочет найти службу пометки функций, чтобы облегчить себе жизнь.
Использование флагов функций DevCycle
Разработка на основе магистралей — это мощный метод разработки более качественного кода. Это снижает сложность, сокращая вероятность ошибок и оптимизируя сотрудничество между разработчиками. DevCycle предоставляет флаги функций в качестве услуги для беспрепятственного выпуска нового кода.
DevCycle позволяет точно контролировать выпуск ваших функций. Вы можете установить флаг функции, который будет выпущен в определенную дату и время, что идеально подходит для планирования нового запуска. Во время этого процесса у вас есть полный контроль над тем, кто может получить доступ к новой функции. Эта стратегия выпуска также позволяет вам тестировать последние версии вашего программного обеспечения с небольшой, более целевой аудиторией, которая с большей вероятностью допустит ошибки или сбои в процессе работы над продуктом.
Начните с 14-дневной бесплатной пробной версии DevCycle.
