Comments 4
Смущает, что скрипты вы пишете прямо в интерфейсе TC. Они получаются за пределами системы контроля версии и не привязаны к коду, который собирают, с соответствующими последствиями.
Как в вашем случае выглядит конфигурирование сервисов для разных стендов?
Много раз слышал, что не стоит запускать БД в докере, что вы об этом думаете?
1. В разных системах CI по-разному, но в TFS именно так. В ней самой созданы описания сборок, которые имеют историю. Зачастую бывает, что код передается Заказчику или предполагается совместная работа с ним. Соответственно, переносить в репозиторий избыточные данные – не лучшая практика в таком ключе. Опять-таки, есть проекты, где скрипты написаны разработчиками (или для них) и пригодны для использования вне CI (сборки Sharepoint и проч.) и тогда комбинируем. В-общем, все индивидуально получается.
2. В рамках одного проекта создаем дополнительное описание сборки с добавлением особенностей (к примеру для dev/stage).
3. Есть проблемы с запуском MySQL-кластера (не рекомендуем для Заказчиков), PostgreSQL работает в кластере, но и с ним есть определенные нюансы. Если нет требования отказоустойчивости или некритична временная недоступность сервиса, то хорошее решение.
2. В рамках одного проекта создаем дополнительное описание сборки с добавлением особенностей (к примеру для dev/stage).
3. Есть проблемы с запуском MySQL-кластера (не рекомендуем для Заказчиков), PostgreSQL работает в кластере, но и с ним есть определенные нюансы. Если нет требования отказоустойчивости или некритична временная недоступность сервиса, то хорошее решение.
Хранение скриптов сборки в git решает следующие проблемы:
1) При изменении скрипта можно всегда найти старые версии
2) Можно делать рефакторинг процесса сборки в новой ветке без каких либо усилий по созданию и поддержке разных тасков для разных веток
Ну и все таки скрипт сборки — не избыточные данные, это тот же код, который запускается и который надо поддерживать
Хранение скриптов сборки в репозитории – хорошее решение.
Опять-таки, как писал выше – для каждого проекта получается индивидуально.
Как правило, скрипты по разворачиванию сложных проектов (в контексте архитектуры) находятся в репозитории. В статье скрипт внутри build definition показан для наглядности.
Опять-таки, как писал выше – для каждого проекта получается индивидуально.
Как правило, скрипты по разворачиванию сложных проектов (в контексте архитектуры) находятся в репозитории. В статье скрипт внутри build definition показан для наглядности.
Sign up to leave a comment.
Микросервисы. Версионность в системах непрерывной интеграции и развертывания CI/CD на примере использования TFS