Постоянная интеграция
Когда вы разрабатываете что-то несколькими командами есть “два стула”:
планируете интерфейс, а потом расходитесь пилить каждый свое на полгода по-отдельности, потом 3 месяца пытаетесь синтегрироваться.
планируете интерфейс, пилите все сразу вместе от интерфейса и вглубь, в “постоянной интеграции”.
На какой сам сядешь? На какой соседнюю команду посадишь?
Каждый сам за себя
Прекрасный вариант, когда есть человек ответственный за интеграцию частей проекта перед релизом. Тебе сказали - ты пишешь, если проебал сроки - виноват сам, если релиз не готов не по твоей вине - всегда можно четко ткнуть пальцем на того, из-за кого задержалась разработка.
Собираешь только свою часть под себя, никаких лишних зависимостей.
Есть одно но: интеграция может не получиться. Можно интегрироваться год, но так и не собрать проект из частей воедино. И тогда просто всех разгонят. Потому что заказчику неинтересно, что Вася молодец, а Петя проебал. Ему нужен работающий проект.
Постоянная интеграция
В этом случае вам заказчик заявляет: у меня нет никого, чтобы вас организовывать: а если два коммуниста не могут договориться, значит один из них - враг.
И тут вам приходится сразу договариваться как не проебать синхронизацию во время разработки. Поэтому надо с самого начала настраивать всех разработчиков на то, что мы все пилим целый проект.
При разработке в IDE должен грузиться весь набор либ и частей проекта. Сборка проекта - это всегда сборка всех его частей. Да медленно, но это будет подстегивать не засирать проект лишним и заниматься оптимизацией сборки.
Фэйл чьих-то юнит тестов должен фэйлить сборку всего про проекта. Твой баг - это и моя проблема тоже. При таком подходе все знают в каком состоянии находится разработка. И тогда у всех есть понимание, что не стоит подливать в масло в огонь, заливая в итак нерабочую главную ветку свой недотестированный код.
И постоянно должна доноситься информация о состоянии проекта на текущий момент: через почту, через чаты, голосом - как вам это удобно.
UI недоделан, но бэкенд рабочий - не канает, не релизим, должно работать все вместе. Если пилите по скраму, то на демо всегда показывайте приложение целиком, а не отдельные части.
Не должно быть каких-то долгостроев в отдельных ветках, в которые не мержатся обновления из основной ветки. Все что не было смержено за месяц - невозможно будет смержить в основную ветку и потом. Поэтому не накапливайте старье.
Разработчики должны чувствовать последствия от своих действий как можно быстрее. При постоянной интеграции кривые костыли должны бить того, кто их подставил как можно раньше. Ревью кода смежных частей должно проводиться всеми вовлеченными командами.
Такая разработка значительно более выматывает, чем разработка по-отдельности. Но при таком подходе проект гораздо чаще находится в состоянии “можно релизить”. А при грамотном планировании, можно вполне вкладываться в сроки.
