Настройка процесса сборки с TeamCity

Question

Я начинаю внедрять CI в своей команде, и я выбрал TeamCity, поскольку он бесплатен для небольших временных команд, а также кажется довольно популярным в настоящее время и имеет много хороших вариантов.

У меня еще нетчтобы определить, что является «типичным» или наилучшим вариантом использования для этого сервера.

Мне кажется, что подавляющее большинство задач сборки лучше выполнять с помощью другого инструмента (пусть это будет в каком-то сценарии сборки, таком как MSBuild)./ NANT) и TC используется только для выдачи модульных тестов / триггера сборки.

Мне сложно настроить полный процесс сборки (копирование файлов / вызов более сложного и логического кода и т. Д.).

Какой хороший сценарий для настройки TC в процессе сборки?

Наш продукт представляет собой программное обеспечение на основе C # с различными "плагинами".

Мы создаем 3 большихФайлы .sln, в настоящее время использующие модуль запуска MSBuild (просто указав файл .sln в качестве аргумента для этого модуля).

Это только заботится о создании реальных двоичных файлов, но не требуетgh для вещей, которые должны объединить выходные данные различных проектов, например для создания установщика.

Answer 1

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

В наших проектах .NET (которые, как вы упоминаете, упоминаете MSBuild / NAnt), у нас есть сборки, состоящие из нескольких этапов. Один использует средство компоновки решения teamcity, второй использует модуль тестирования nunit, а последний использует msbuild для копирования файлов.

У нас есть еще одна сборка .NET, которая следует аналогичному шаблону, но добавляет несколько шагов, вызывая пользовательские инструменты, написанные на python.

У нас есть несколько сборок java, которые выполняют только бегуна NAnt.

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

Если у вас уже есть хороший сценарий msbuild или nant, просто укажите на него teamcity и используйте его для запуска.

Мне нравится использовать средство запуска teamcity, потому что оно просто работает. То же самое с их бегуном. Но MSBuild / NAnt действительно хорош для работы с шаблонами файлов.

Надеюсь, это поможет.

Answer 2

Технически, вы можете делать все, что делает TeamCity, через скрипт или инструмент. Прелесть TeamCity в простоте, которую он предоставляет «из коробки» для организации ваших задач. В основе TeamCity лежит интеграция командной строки и встроенных инструментов с отраслевыми инструментами. Они облегчают бремя конфигурации, так что, указав несколько переменных или параметров, вы можете автоматизировать ключевые задачи, которые мог бы выполнить громоздкий скрипт. Пользовательский интерфейс интуитивно воспринимает параметры командной строки. Мой любимый пример использования TeamCity - это его историческое значение, которое проистекает из возможностей его пользовательского интерфейса. Представьте себе, если вам нужно выяснить, когда последний раз выполняемый вами скрипт провалился или почему он провалился? вам придется хранить исторические журналы, артефакты и т. д., чтобы разобраться в них, чтобы ответить на простые вопросы. Теперь представьте, что вам нужно сообщить об историческом тренде ваших автоматизированных задач (сборок), вам понадобится специальная реализация, которая просматривает все данные, которые вы собираете, просто для того, чтобы сообщать или отвечать на простые вопросы, типа «эта сборка занимает больше времени? количество наших юнит-тестов увеличивается? и т. д. Все эти данные собираются из коробки и сообщаются вам с teamcity. Если вы не можете сказать, я думаю, что это прекрасный инструмент.

Answer 3

Мы используем TeamCity следующим образом: 1. Запускаем сборки Continuous Integration (запускаются, как только кто-то фиксирует код) 2. Ночные сборки 3. Ночные развертывания (с использованием сценариев пакетной обработки / оболочки) 4. Тесты Sanity (запускаются при ночных развертываниях)