Блог

Мы работаем над старым проектом, который состоит из нескольких приложений, которые все используют одну и ту же базу данных и сильно зависят друг от друга. Из-за размера проекта мы не можем провести рефакторинг кода, поэтому все они используют API как единый источник базы данных. Платформа содержит следующие приложения:

• Веб-сайт
• Администратор / CMS
• API
• Cronjobs

Прямо сейчас мы хотим начать реализацию конвейера CI / CD с использованием Gitlab. В настоящее время мы испытываем проблемы, потому что мы не можем обновить базу данных для развертывания одного приложения, не нарушая работу всех других приложений (если мы не развернем все приложения).

Я думал о решении, при котором один конвейер запускает все остальные конвейеры. Каждый конвейер будет выполнять все недавно добавленные миграции базы данных и проверять, работает ли конвейер по-прежнему должным образом. Если все конвейеры завершатся успешно, начнется развертывание всех приложений.

Я сомневаюсь, что это хорошее решение, потому что это изменение только увеличит и без того высокую связь между нашими приложениями. Кто-нибудь знает лучшее решение, как реализовать CI / CD для нашей платформы?

Вы должны перестать думать о них как об отдельных приложениях. У вас есть монолит с несколькими модулями, но до тех пор, пока их не удастся разъединить, все они являются одним приложением и должны быть развернуты как таковые.

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

Вероятно, существует множество решений, но одно из них, которое я делал в прошлом, — это создание отдельного хранилища для CI / CD всей системы.

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

Отдельный репозиторий CI / CD извлекает соответствующие теги для каждого элемента и запускает CI / CD для всех них как единое целое. Это позволяет вам указать, какой тег для каждого репозитория вы хотите указать, что должно предотвратить сбой этого конвейера при внесении изменений в отдельные компоненты.

Спросите себя, почему эти «разные приложения» используют «одну и ту же базу данных». Это потому, что все эти «отдельные приложения» имеют дело с «одной и той же бизнес-семантикой»? Если это так, как уже заявил Роб, то у вас просто есть одно приложение (и, кроме того, не будет развязки именно потому, что ваша бизнес-семантика является сингулярной / атомарной / …).

Или в структуре БД есть различимые части, чтобы можно было определить высокоточное отображение, говорящее «этот компонент использует эту часть» и т.д. и т.п.? В таком случае, что заставляет вас говорить что-то вроде «не удается обновить базу данных для развертывания …»??? (Кстати, «обновить базу данных» — это не то же самое, что «реструктурировать базу данных». Пожалуйста, пожалуйста, пожалуйста, будьте точны.) Ответ на этот вопрос определит, что вам нужно решить.