Построение зависимостей и локальных построений с непрерывной интеграцией

Question

Наша компания в настоящее время использует TFS для управления версиями и сборки сервера. Большинство наших проектов написаны на C/C++, но у нас также есть некоторые .NET-проекты, и мы не хотели бы ограничиваться, если нам нужно будет использовать другие языки в будущем.

Мы хотели бы использовать Git для управления исходным кодом, и мы пытаемся понять, что будет лучшим выбором для сервера сборки. Мы начали искать в TeamCity, но есть некоторые вопросы, мы возникают проблемы, с которыми, вероятно, будет иметь значение, независимо от выбора сервера сборки:

1. зависимостей Построить - Мы хотели бы, чтобы иметь возможность контролируйте зависимости сборки для каждого <project, branch>. Например, <MyProj, feature_branch> зависит от <InfraProj1, feature_branch> и <InfraProj2, master>. Из того, что мы видели, для этого нам, возможно, понадобится использовать Gradle или что-то подобное, чтобы строить наши проекты вместо простого MSBuild. Это верно? Существуют ли более простые способы достижения этого?
2. Местные сборки - Очевидно, мы хотели бы иметь возможность создавать проекты локально. Это становится проблемой, когда вводятся зависимости проекта, поскольку нам нужен способ ссылки на эти ресурсы или скопировать их локально, чтобы сборка была успешной. Как это обычно решается?

Я был бы признателен за любой ввод, но образец установки, который охватывает эти проблемы, также будет большой помощью.

Answer 1

IMHO Оба вопроса, которые вы упоминаете, действительно относятся к категории управления конфигурацией, поэтому, как вы говорите, не связаны с выбором сервера сборки.

Рабочее пространство для сборки проекта (не имеет значения, централизовано или локально) должно действительно содержать все необходимые ресурсы для сборки.

Как вы можете это достичь? Имейте проект «metadata» git repo с «content» файл, содержащий все ваши компоненты проекта и их зависимости (каждый со своим собственным git/другим репо) и их точные версии - эффективно связывая их вместе согласованно (вы можете найти полезно также хранить другие метаданные в этом компоненте по дороге, а также информацию о SCM, специфичную для компонента, при использовании комбинации SCM в рабочей области).

Рабочая область тянуть скрипт-обертка будет первым тянуть этот метаданных GIT репозиторий, разобрать содержания файла, а затем вытащить все остальные компоненты проекта и их зависимости в соответствии с содержания информацией файла. Любая сборка в таком рабочем пространстве будет иметь все необходимые ей части.

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

Конечно, на самом деле управление зависимостями - это другое дело. Тонны мнений, некоторые даже противоречивые.