Хотим внедрить у себя CI/CD в компании (проекте). На текущий момент у нас две команды, которые в паралелли пилят моно-релизы (полугодичные, 4-5 спринтов).
Состав команд приблизительно такой: 5 фронтов, 5 бэков, 3 SQL, BA, PM и команда QA
Появилось предложение разделить команды по профилям: Фронт команда отдельно, бэк + скл - у каждой будет свой бэклог, и работают они, в принципе, независимо, фронт - просто потребитель апишек, которые релизит бэк + скл
Пока не понимаем эффективна ли такая модель или лучше делать небольшие команды, но фулстековые (фронт + бэк + скл)
Поделитесь опытом, пожалуйста
Подскажите пожалуйста, как Вы видите связь между текущим и/или предлагаемым вами разделением команд и процессами CI/CD? На мой взгляд CI/CD можно одинаково успешно применять в любой из озвученных Вами конструкций, но у Вас вопрос видимо не об этом.
Я, как раз, не очень понимаю эту связь ...
Но есть мнение, что в больших командах "размазана" ответственность и сложнее планировать работу, так как какие-то фичи требуют больше фронта или больше бэка
Да какая разница как у нас?! Скорее всего мы находимся в разных исторических контекстах: разные цели, разные задачи, разные ресурсы - разное все.
Если речь идет не о переменах ради перемен, то надо исходить из проблемы. Вот Вы сказали "Появилось предложение разделить команды по профилям..." и "Пока не понимаем эффективна ли такая модель "... У меня в ответ на это возникает вопрос: "а зачем тогда что то менять?". Какую проблему пытаетесь решить?
Если попытаться конструктивно порассуждать о предлагаемом варианте организации, то необходимо понимать и уметь решать следующие задачи:
1. Обычно всегда есть задачи по автоматизации процессов, которые насквозь проходят через фронт, мидл и бэк. Соответственно, в предложенной Вами структуре (поскольку во фронте, мидле и бэке у вас работают разные команды) возрастают требования к координации, устранению конфликтов, устранению разрывов при выпуске релизов и т.д. Т.е. по мимо тимлидов команд, вам нужны еще и координаторы изменений. По моим ощущениям, одного PM вам будет недостаточно (не уверен, что он сможет отследить технологические зависимости между тасками в разных беклогах). Возможно ошибаюсь.
2. Если разнесете по разным беклогам, то сложнее будет отслеживать технологические и ресурсные зависимости между тасками. Хотя, возможно, все будет зависеть от используемого инструмента.
Saboteur
@saboteur_kiev Куратор тега Организация работы
software engineer
CI/CD это не организация команд, это организация процесса автоматической сборки/деплоймента/тестирования.
Для этого девопс/админ или шарящий в этой теме разработчик придумывают правила (branching name conventions, versioning, настраивает соответствующие инструменты и инфраструктуру (teamcity/jenkins/какой-нить bitbucket с пулл реквестами. Чтобы по коммиту собирался билд, проходили юнит тесты, результат деплоился в тестовый энвайрнмент, запускались автотесты, результат возвращался в пулл реквест и подтверждал действие.
Чтобы деплоймент на тестовый энвайрнмент делался одной кнопкой, чтобы деплой на прод делался одной кнопкой с предварительным подтверждением и аппрувалом также в цифровом виде.
Вот это все.
спасибо за коммент
вы описали техническую сторону - я с вами полностью согласен
меня же в этом вопросе больше интересует - организация труда людей, более эффективная возможно
Написано
Saboteur
@saboteur_kiev Куратор тега Организация работы
Роман,
Эффективность организации команд от CI/CD не зависит практически вообще.
Она зависит от того, как у вас создана иерархия подчинения, как идет воркфлоу - пришел реквест-попал в продакшен, какие требования, какая свобода и так далее.
У нас были и отдельно команды разработчиков по профилям, и отдельно feature-команды, когда внутри команды есть полный стек и можно таск кинуть на команду, не разделяя.
Везде зависит от нагрузки. Если в команде есть 2 фронта, 2 дба, 2 бэкенда, и приходит фича на фронт - остальные 4 человека страдают фигней.
Если фич прилетает много, и они тесно связаны по профилям - то может оказаться и фича-тимы удобнее.
Вы должны понимать, что ваш вопрос слишком абстрактный и не относится к технической тематике.
МОжет оказаться так, что разница между организацией работы будет небольшая, а вот сама миграция займет кучу времени и усилий
Простой
Средний
Средний
Средний
