Как ускорить выкатывание изменений в большом проекте (монолит)?
Суть вопроса. Большой проект на php, монолит. Бизнес требует более быстрого выкатывания изменений в открытое бета тестирование (это почти прод - есть активные клиенты, все в бою).
Изменения плодят порядка 6-7 разработчиков ежедневно. Есть серввера сборок, куча тестов (unit + functional). БД одна.
Сейчас процесс релиза устроен в целом очень даже неполохо. Раз в две недели:
- проверяется каждое изменение на этапе влития в dev (team lead)
- проверяются все готовые изменени командой разработки на stage сервере + сразу фиксятся найденные баги
- проверяются все готовые измененя бизнес аналитиками на stage сервере
- репортятся баги
- правятся баги
- перепроверяется все
- ура! выкатываемся!
ну и грустная новость - все это порядка 3-4 дней.. :) (пока тесты пройдут - а это каждая ветка порядка 25 мин., пока все заведется и обговориться в jira и т.д.).
Пробовали сами себе ответить на этот вопрос, вот мысли:
1. Начинать разбивать всю систему на микросервисы, тем самым попытаться уйти от деплоя всего этого порохода на один присест.
Плюсы на лицо, код не пересекается, деплоить можно в отдельности любой из компонентов, масштабирование отдельыных сервисов и т.д.
Все круто, но! при условии - что БД в этом случае используется от монолита и по прежнему одна. Если же это не так, то это добавляет только больше вопросов и тех сложностей, чем
было раньше (внутреннее взаимодействи микрух, синхронизация данных, сложность работы с этим добром без нормальной оркестрации)
2. Тупо переключаемся на dev ветку на открытом бета тестировании и релизиться очень часто (и жить в аду )) ).
Тоже вариант в целом живучий, если сажать отдельного человека тушить ежедневные пожары.
Господа, хотелось бы узнать - как у вас в проекте выходили из таких ситуаций, и как к этому шли.
Спасибо!
когда остается зависимость от БД, это никакая не микросервисная архитектура.
Это оверинженеринг монолита, который ничего кроме головной боли не дает, остается тем же самым монолитом.
а предоставляя микросервисам паралельно читать и записывать данные из одного и тогоже источника, вы выбираете жить либо с рейс кондишен либо с деад локами.
rustler2000, будем пробовать, тема известная.. но почему то я всегда ее боком обходил.
По поводу l7 proxy - что посоветуете? кроме nging plus чет сходу ничего путного не нашел.
Петр Марочкин, дофига - у меня в черновике 8 штук, что могут под наши нужды подойти - и это точно не все.
начни с https://habr.com/search/?q=gobetween - авторы на хабре есть. он конечно не прямо вот L7 но будет кому вопросы задать на родном :D
поставишь на бакэнде http сервер(у вас же php и всеравно чтото стоит перед ним) c graceful shutdown и будеш руками туда трафик врубать. ну или патчь к gobetween с лимитом соединений на сервер (если еще такого нет), и по rest лимит выставлять и смотреть живет или падает.
Процедуры сборки, развертывания, тестирования автоматизировали?
В моем понимании, если Вы утром следующего дня прийдете на работу и увидите развернутую на тестовом сервере версию с отчетом о прохождении тестов, то время с dev до prod сокращается до 2 дней (утром стабилизируете и после обеда получаете стабильный релиз).
Проверено на практике. Собирали мы не раз в две недели а каждую ночь. Базовые проверки проходили ночью, а функционал аналитики проверяли только при подготовке обновления у заказчика.
Важно: на prod накатывать не результирующую сборку, а все сборки ровно в том последовательности в которой накатывали на stage (сначала нестабильный релиз, потом фиксы до стабильного). Это нужно что бы исключить ошибки при повторной сборке.
