RDCLR.DEV

Коллеги, закинули инвайт на субботнюю встречу. Собираемся 17 августа в центре Воронежа на конференцию «Код на крыше».

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

В плане мероприятия 3 секции для разных профессиональных комьюнити. Объединяем людей из разных направлений: менеджеры, технические эксперты и дизайнеры.

О разработке расскажут спикеры из Авто.ру, Red Collar, ex-OBI и #NDA:

- Дмитрий Панычев, ex ИТ-директор OBI и vprok.ru
«Архитектура не нужна?»

- Евгений Ефанов, старший мобильный разработчик Red Collar
«Разработка для Apple TV: SwiftUI и Focus Engine»

- Артём Михайлёв, старший Android-разработчик Авто.ру
«Функциональный подход к созданию дизайн-систем»

И один доклад о проекте под жестким #NDA, про который расскажем позже.

А еще круглый стол на тему, которую выберите вы сами, карьерный центр на крыше и афтепати.

Подробнее о программе и регистрация: rooftopcode.ru

UPD: Конференция перенесена! Новая дата будет анонсирована позже.

Итак, что мы хотим?

Нам нужно переизобрести процесс разработки так, чтобы выполнялись условия

1. Минимизировать количество долгоживущих веток

2. Взять все плюсы gitflow: работу с релизами и хотфиксами

3. Постараться выкатывать в продакшн полностью оттестированный код

Скажу честно, за основу мы взяли методологию trunk based development aka магистральная разработка, о которой я когда-то писал, но методом проб и ошибок адаптировали ее к своим реалиям, о чем и расскажу в следующих постах.

Давайте продолжим.

Какие могут быть недостатки у подхода gitflow?

1. Множество долгоживущих веток.
Две очевидные "вечные" ветки - master и develop 🟡.
При этом фича-ветки в классическом gitflow тоже не ограничены по времени жизни. Разрабатывайте свою фичу хоть три года, куда спешить.
Если релизные ветки создаются под каждый релиз и потом закрываются, это еще полбеды. Совсем плохо, когда команда проекта использует отдельную долгоживущую ветку releases 🟢 просто потому, что они так поняли картинку, но текстовое описание флоу не прочитали 🤦‍♀️
Это могло бы показаться шуткой, если бы не повторялось десятки раз

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

На картинке, если коммит из hotfix 🔴 попадает в develop 🟡 с конфликтом из-за того, что там уже произошли какие-то изменения после релиза, то это неизбежно приведет к расхождению master 🔵 и develop 🟡 с непредсказуемым результатом в будущем.

При использовании gitflow обычно к каждой ветке привязано свое окружение и этим объясняется необходимость долгоживущих веток. Например, весь код из develop 🟡 собирается и попадает на стенд разработки, из releases 🟢 - на stage для тестирования, из master 🔵 - на продакшн. Вроде бы логично, понятно и удобно, если вас не смущает то, что на стейдже вы тестируете один код, а на продакшн выкладываете другой 🤷