Как ускорить выкатывание изменений в большом проекте (монолит)?

Question

[Петр Марочкин]

Суть вопроса. Большой проект на php, монолит. Бизнес требует более быстрого выкатывания изменений в открытое бета тестирование (это почти прод - есть активные клиенты, все в бою).
Изменения плодят порядка 6-7 разработчиков ежедневно. Есть серввера сборок, куча тестов (unit + functional). БД одна.
Сейчас процесс релиза устроен в целом очень даже неполохо. Раз в две недели:
- проверяется каждое изменение на этапе влития в dev (team lead)
- проверяются все готовые изменени командой разработки на stage сервере + сразу фиксятся найденные баги
- проверяются все готовые измененя бизнес аналитиками на stage сервере
- репортятся баги
- правятся баги
- перепроверяется все
- ура! выкатываемся!

ну и грустная новость - все это порядка 3-4 дней.. :) (пока тесты пройдут - а это каждая ветка порядка 25 мин., пока все заведется и обговориться в jira и т.д.).

Пробовали сами себе ответить на этот вопрос, вот мысли:

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

Все круто, но! при условии - что БД в этом случае используется от монолита и по прежнему одна. Если же это не так, то это добавляет только больше вопросов и тех сложностей, чем
было раньше (внутреннее взаимодействи микрух, синхронизация данных, сложность работы с этим добром без нормальной оркестрации)

2. Тупо переключаемся на dev ветку на открытом бета тестировании и релизиться очень часто (и жить в аду )) ).
Тоже вариант в целом живучий, если сажать отдельного человека тушить ежедневные пожары.

Господа, хотелось бы узнать - как у вас в проекте выходили из таких ситуаций, и как к этому шли.
Спасибо!

Comments

[rustler2000]

Blue/green deployment? Счас наверное хрен найдешь l7 proxy без этой фичи

[⚡ Kotobotov ⚡]

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

[Петр Марочкин]

⚡Дима Кубитский ⚡, да, тут вы правы...
ничего хорошего выйти тут явно не сможет в таком виде.. уже обмозговал эту идею.

[Петр Марочкин]

rustler2000, будем пробовать, тема известная.. но почему то я всегда ее боком обходил.
По поводу l7 proxy - что посоветуете? кроме nging plus чет сходу ничего путного не нашел.

[rustler2000]

Петр Марочкин, дофига - у меня в черновике 8 штук, что могут под наши нужды подойти - и это точно не все.
начни с https://habr.com/search/?q=gobetween - авторы на хабре есть. он конечно не прямо вот L7 но будет кому вопросы задать на родном :D
поставишь на бакэнде http сервер(у вас же php и всеравно чтото стоит перед ним) c graceful shutdown и будеш руками туда трафик врубать. ну или патчь к gobetween с лимитом соединений на сервер (если еще такого нет), и по rest лимит выставлять и смотреть живет или падает.

Answer 1

[InOdinWeTrust]

Возможно, вы доросли до большого проекта. Значит, без аналитики не разобраться.
Нужно четкое представление сколько времени тратится на каждый шаг вашего процесса релиза.
Если нет однозначных метрик - покрывайте. Нужно не на глаз сколько минут, а четко статистика по каждой задаче - сколько времени собиралась, тестировалась, сколько релиз, сколько проверка бизнесом, и тд и тп. Метрик мало не бывает.
Затем по собранным данным рисовать графики, диаграммы, анализировать, на что тратится больше всего времени.
Затем думать, где можно оптимизировать.
Анализировать и оптимизировать не имея на руках цифр и картинок с диаграммами - это путь вникуда. Можете угадать с оптимизацией, можете не угадать.

Когда все данные на руках есть, можете оптимизировать.

Чаще всего помогает:
- Исключить из процессов или минимизировать участие людей (CI, CD, автотесты и тд)
- Распараллелить множественные однообразные процессы (мержи, запуски тестов на задачах, запуски тестов на билде, и тд)
- Группировать (тестировать билд один раз после того, как в него попали все нужные бизнессу задачи)

Comments

[Петр Марочкин]

InOdinWeTrust спасибо! По факту провели расследование, проанализировали то что есть.
Как итог - спроектировали и внедрили blue green deploy и сейчас делаем очень мелкие и безопасные обновления.

Answer 2

[ponaehal]

Процедуры сборки, развертывания, тестирования автоматизировали?
В моем понимании, если Вы утром следующего дня прийдете на работу и увидите развернутую на тестовом сервере версию с отчетом о прохождении тестов, то время с dev до prod сокращается до 2 дней (утром стабилизируете и после обеда получаете стабильный релиз).
Проверено на практике. Собирали мы не раз в две недели а каждую ночь. Базовые проверки проходили ночью, а функционал аналитики проверяли только при подготовке обновления у заказчика.

Важно: на prod накатывать не результирующую сборку, а все сборки ровно в том последовательности в которой накатывали на stage (сначала нестабильный релиз, потом фиксы до стабильного). Это нужно что бы исключить ошибки при повторной сборке.

Answer 3

[xmoonlight]

1. Каждый новый функционал - это замена одного логического блока на другой или присоединение нового. Соответственно, однотипные блоки - должны иметь одинаковый интерфейс.
2. Для быстрой автоматической откатки в случае ошибки, до начала работы нового блока должны запоминаться: все входные значения и состояние изменяемых им параметров.
3. В случае исключения - откатываемся и применяем старый блок без требования каких-либо дополнительных действий с чьей-либо стороны.