У меня есть веб-приложение, основанное на архитектуре микросервисов (как фронтенд, так и бэкенд). У нас четыре уровня: Dev, SIT, UAT и Prod. Изначально у нас была только одна команда, занимающаяся написанием кода и деплоем.
Недавно количество команд увеличилось до трех (возможно, в будущем вырастет еще), и мы столкнулись с ограничениями среды. То есть, если код команды A находится на UAT, они не хотят, чтобы команда B вносила какие-либо изменения в UAT, пока не получит одобрение на UAT, чтобы убедиться, что стабильный код перейдет в продакшен. В то же время команда B застряла на SIT. Одновременно команда C не может внести код в SIT, потому что команда B хочет стабильный SIT, прежде чем развернуться на UAT. Теперь команда A, ожидая одобрения на UAT, не может объединить код с основным Dev, потому что команда C использует его.
Эта проблема кажется очень тривиальной, и я просто не могу понять, как ее решить (я менеджер по продукту) – возможно, мне не хватает правильных терминов, чтобы описать это, и это мешает моим поисковым усилиям.
Я ищу советы, которые не являются специфичными для технологий, а скорее сосредоточены на решении этой проблемы в принципе или на формировании стратегии управления ею. Наличие нескольких окружений UAT увеличит затраты, и в конечном итоге мы снова столкнемся с ограничением по мере роста.
Ответ
Создание эффективной стратегии развертывания и управления кодом для нескольких команд в архитектуре микросервисов требует системного подхода. Вот несколько принципов и стратегий, которые могут помочь вам справиться с текущими проблемами:
1. Изолированные окружения для разработки
Создайте изолированные среды для каждой команды на уровне разработки. Это позволит командам A, B и C работать независимо друг от друга. Каждая команда может работать с собственным экземпляром среды разработки, где они могут проводить тестирование и интеграцию, не влияя на других.
2. Параллельное тестирование
Рассмотрите использование дублирующих сред для SIT и UAT. Например, обе команды могут иметь доступ к своим версиям SIT и UAT, что позволяет командам проводить тестирование параллельно. Это потребует дополнительных ресурсов, но может значительно ускорить процесс развертывания.
3. Контроль версий и ветвление
Используйте стратегию ветвления в вашей системе контроля версий (например, Git), чтобы каждая команда могла работать над своей функциональностью в отдельных ветках. Это даст возможность проводить ревью и тесты независимо. После завершения работы над функциональностью ее можно будет объединить с основной веткой только после завершения всех проверок.
4. Координация и коммуникация
Создайте регулярные встречи или каналы для координации между командами. Это может быть общий стенд-ап или каналы в мессенджерах, где команды могут делиться статусами и информировать друг друга о плане развертывания. Четкая коммуникация поможет избежать блокировок.
5. Стратегия выпуска
Внедрите стратегию "Feature Toggles" (переключатели функциональности). Это позволяет командам разрабатывать и внедрять код, даже когда функциональность ещё не готова к использованию. Функционал можно включать и выключать в зависимости от стадии тестирования и готовности.
6. Оптимизация процессов CI/CD
Инвестируйте в автоматизацию процессов непрерывной интеграции и непрерывного развертывания (CI/CD). Автоматизированные тесты могут быть запущены при каждом изменении кода. Это обеспечит более быструю обратную связь и позволит командам уверенно размещать свой код, зная, что он был протестирован.
7. Правила управления релизами
Определите строгие правила управления релизами, включая очередность развертывания и время программных релизов. Согласуйте расписание развертываний между командами и дайте каждой команде своё «окно» для развертывания.
8. Обратная связь и улучшения
Периодически проводите ретроспективы, чтобы выявить проблемы в процессе и находить пути для улучшения взаимодействия и развертывания. Это может обогатить вашу стратегию и помочь командам эффективно развиваться.
Заключение
С задачами, связанными с управлением несколькими командами и окружениями, необходимо подходить стратегически. Лучшие практики в области управления проектами и разработки помогут улучшить процессы развертывания и интеграции, что приведет к более высокому качеству продукта и уменьшению ожиданий между командами.