Как правильно релизиться в больших компаниях?

Всем привет

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

Знакомые разработчики предложили следующие схемы:

  1. Фича-тим, где разработчики собираются для реализации одной фичи. Однако, тут есть минусы и сложности, если фич много, они небольшие и непродолжительные. Плюс "монорелиз" достаточно сложно тестировать, если в него пихают все из разных команд

  2. Версионнность. Команды релизятся отдельно, однако нужно делать дополнительный код и время от времени его чистить. Что опять же приводит к некоторым сложностями и удорожании разработки.


Как правильно в таких ситуациях поступать? Какая практика считается лучшей?
  • Вопрос задан
  • 2447 просмотров
Пригласить эксперта
Ответы на вопрос 7
DmitriyEntelis
@DmitriyEntelis Куратор тега Веб-разработка
Думаю за деньги
1. Фича-тим это хороший инструмент менеджера, для синхронизации технических решений и соответственно снижения рисков. В одновременные релизы разных команд я не верю.

2. С "версионностью" мне кажется не так много сложностей на самом деле.
Если воспринимать результат работы каждой команды как какой-то сервис с api наружу (а так наверное и есть), то по сути от команд требуется обеспечивать обратную совместимость новых версий api со старыми - задача которая в любом случае полезна.
Делать версионность без обратной совместимости - очень плохая идея как мне кажется. Тут и затраты на поддержку, и затраты на переподключение у всех остальных команд.

Еще очень важно, чтобы был вменяемый CTO / архитектор всего этого зоопарка. Ну или хотя бы просто был.

Видел живые проекты где не было продумано общей архитектуры, - поверх слоя основных сервисов по бизнес требованиям писался 2й слой, через годик поверх 2го слоя писался 3й, ... в итоге к нашей эре слоев было ~12 и как это точно работает не знал мне кажется никто, - что впрочем не мешало проекту иметь десятки миллионов пользователей.
Ответ написан
gromdron
@gromdron
Bitrix developer
На РИТ++ в этом году был прекрасный (на мой взгляд) доклад от Андрея Евсюкова из Lamoda. Рекомендую присмотреться. Записи увы нет, но по слайдам думаю будет понятна исходная суть.
Кстати, там рассмотрены именно Ваши проблемы (Time-to-market) и часть Ваших страхов
Ответ написан
zoonman
@zoonman
CEO @ LinuxQuestions.ru
Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.
Ответ написан
darqsat
@darqsat
PM
Как правильно релизиться в больших компаниях?

То что ты описал указывает на слабое планирование. Должен быть менеджер проекта который организует процесс планирования в котором будет участвовать Продакт Овнер, Тимлиды всех групп и он сам. Результатом планирования должна получится диаграмма ганта или Roadmap в котором будут учитываться взаимосвязи и будут заложены адекватные риски. Я это делаю всегда, и у меня на проектах почти никогда не бывает таких вот блокеров как ты описываешь.

По поводу релизиться есть разные методики.
Версионность это хорошо если вы работаете через API, а если у вас несколько команд бекенда которые пилят один и тот же монолит то нужно внедрять практику GitFlow и ставить техлида который будет заниматься мержами веток в релизы и правильно построит адекватный GitFlow.

Версионность апи это отличная практика, ей нужно учиться и не слушать тех кто говорит что это сложно. Это не сложно. А версионность позволит релизить бекенд не дожидаясь фронтенд и не ломая его на продакшене.

Что бы релизы проходили плавно нужно погрузить себя в книжки по Continues Delivery и занятся докеризацией своих сервисов или монолита.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Организация работы
build engineer
Правильные версии - более универсальный вариант. Вдобавок те же фича-тимы могут работать и с версиями.
Чтобы упростить работу с версиями, используйте https://semver.org/lang/ru/

Скажем так. На организацию эффективных фича-тим уйдет больше усилий, чем на версионирование.
Ответ написан
ApeCoder
@ApeCoder
Многие рекомендуют постоянные команды. Т.е. фича тим не собирается под фичу, а на команду назначается фича. После разработки фичи команда остается той же просто ей дается другая фича.

Можно делать "внутренний опернсурс" - допустим у вас компонентные команды, но при этом одной команде понадобилась фича в компоненте другой команды. Она может предложить патч для этого компонента, а другая команда рассмотрит его, накатит на компонент либо отвергнет.

см также
https://www.thoughtworks.com/mingle/scaled-agile/2...
www.discussagile.com/blog/dependency-management-in...
https://www.scaledagileframework.com/value-stream-...
Ответ написан
angrySCV
@angrySCV
machine learning, programming, startuping
ну сейчас популярен подход избавления от связанности и создание архитектуры на основе большого числа микросервисов, которые можно без проблем модифицировать, не зависимо от действий других команд.
соответственно разработку можно вести паралельно, также как и деплой с тестированием.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы