Как стать автором
Обновить

Комментарии 4

  1. Смущает, что скрипты вы пишете прямо в интерфейсе TC. Они получаются за пределами системы контроля версии и не привязаны к коду, который собирают, с соответствующими последствиями.


  2. Как в вашем случае выглядит конфигурирование сервисов для разных стендов?


  3. Много раз слышал, что не стоит запускать БД в докере, что вы об этом думаете?


1. В разных системах CI по-разному, но в TFS именно так. В ней самой созданы описания сборок, которые имеют историю. Зачастую бывает, что код передается Заказчику или предполагается совместная работа с ним. Соответственно, переносить в репозиторий избыточные данные – не лучшая практика в таком ключе. Опять-таки, есть проекты, где скрипты написаны разработчиками (или для них) и пригодны для использования вне CI (сборки Sharepoint и проч.) и тогда комбинируем. В-общем, все индивидуально получается.

2. В рамках одного проекта создаем дополнительное описание сборки с добавлением особенностей (к примеру для dev/stage).

3. Есть проблемы с запуском MySQL-кластера (не рекомендуем для Заказчиков), PostgreSQL работает в кластере, но и с ним есть определенные нюансы. Если нет требования отказоустойчивости или некритична временная недоступность сервиса, то хорошее решение.

Хранение скриптов сборки в git решает следующие проблемы:


1) При изменении скрипта можно всегда найти старые версии
2) Можно делать рефакторинг процесса сборки в новой ветке без каких либо усилий по созданию и поддержке разных тасков для разных веток


Ну и все таки скрипт сборки — не избыточные данные, это тот же код, который запускается и который надо поддерживать

Хранение скриптов сборки в репозитории – хорошее решение.
Опять-таки, как писал выше – для каждого проекта получается индивидуально.
Как правило, скрипты по разворачиванию сложных проектов (в контексте архитектуры) находятся в репозитории. В статье скрипт внутри build definition показан для наглядности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории