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

Question

Может быть, это просто мечта сумасшедшего, но ..

В моей компании у нас большой проект на C # .NET, с ~ 25 решениями (очень старыми) и ~ 3,5 млн.Loc.Проблемы, с которыми я сталкиваюсь: слишком медленное время сборки, сейчас это занимает 7 минут с SSD (dev-машины), 15 минут + в виртуальной машине с обычными жесткими дисками (это будет система сборки TeamCity, которую я хотел бы развернуть).Я знаю, что система сборки должна быть самой быстрой, но я ничего не могу изменить в краткосрочной перспективе.

Я хочу сократить цикл обратной связи commit-build-unittest для разработчиков (желательно сейчас на компьютере Teamcity)просто скомпилировав проект (ы), которые были затронуты последним коммитом, взяв все остальные сборки, например, с локального сервера nuget (сам сервер Teamcity с версией 7.0).

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

Я знаю, что проблема такой частичной компиляции заключается в возможности пропускаошибки компиляции (несоответствие интерфейсов может остаться незамеченным), но это можно было бы устранить, запустив второй (Teamcity?) экземпляр сервера сборки, который выполняет всю энчиладу параллельно.Но получение первой обратной связи немедленно очень важно для меня.

Теперь мой вопрос: есть ли система сборки / система непрерывной интеграции, которая может справиться с этой задачей?Или мне придется написать свой собственный фоновый сервис с поддержкой фиксации?Это было бы немного неприятно, так как мы используем FinalBuilder Scripts, и этот формат, кажется, не читается никаким API (но недостаточно углублен в это).

PS: Также я хотел бы запускать модульные тесты только для проектов, которые были изменены последним коммитом, или, по крайней мере, расставлять приоритеты.Но это запоздалая мысль.

Answer 1

Большинство доступных механизмов CI использует конвейер развертывания , который специально разработан для сокращения времени обратной связи в цикле разработки. Это работает следующим образом: статус FAIL немедленно, если какой-либо из шагов пошёл не так.

Предполагается ( в этой книге ), что первые 4 шага должны быть менее 2-5 минут даже для самых сложных проектов, если он превышает это, то есть проблема с вашим конфигурация и способ использования процесса CI.

Code commit
 triggers --->

 Step 1. Automatic checkout on CI side
 Step 2. Compile code, ideally 1-2 mins  
 Step 3. Save binaries to the artifact repository
 Step 4. Unit test, ideally 1-2 mins
 Step 5. Deploy to staging
 Step 6. Automated integration testing
 Step 7. Automated acceptance testing
 ------------------------------------
 Manual testing
 Manual deploy to production

Специально для шага 2 вы можете:

а. Разделите большое решение на отдельные уровни. Каждый уровень будет иметь свое собственное решение Visual Studio и только проекты, относящиеся к этому уровню, в некотором смысле вы выполняете децентрализацию исходного громоздкого решения. На шаге 5 вы знаете, как собрать уровни в удобное для использования приложение.

б. В конфигурации TeamCity вы можете указать, выполнять ли чистую проверку или использовать уже доступный источник (можно сэкономить время на шаге 1). Убедитесь, что для целевого объекта MSBuild установлено значение Build , при котором будут приниматься только исходные файлы, которые изменились с момента последней сборки (сэкономьте время на шаге 2).

Из личного опыта вариант а) является лучшим, но при необходимости вы также можете использовать как а), так и б), что, однако, может привести к некоторым скрытым ошибкам со старыми файлами, которые хранятся дольше, чем необходимо. Teamcity также поддерживает несколько агентов (до 3 в бесплатной версии), которые позволят вам запускать задачи параллельно.

Answer 2

Используйте систему зависимых сборок.Если вы используете SVN с каждым проектом в отдельной папке, вы можете настроить CI-проект для каждого из ваших проектов c #, который создает только этот проект и очень быстро уведомляет вас о том, успешно он или нет.

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

Для полной сборки у вас может быть другой проект CI, который отслеживает изменения в корневой папке и запускает сборку всего решения.

Настроив его таким образом, вы можете настроить сборку каждого проекта и быстро возвращать результаты при проверке кода и более медленном возврате тестов для проекта

Answer 3

MSBuild делает различие между "build" и "rebuild" для целей сценария сборки - нормальная сборка строит только те проекты, которые она видит как измененные с момента предыдущих сборок.

При этом должно быть достаточно, чтобыОчистите каталог сборки агента TeamCity при получении исходного кода из системы управления версиями (возможность сделать это может зависеть от SCM - кажется, что он хорошо работает с Mercurial) и просто запустите сборку, а не перестроение.

Что касается модульных тестов, TeamCIty может сначала выполнить неудачные, но выяснить, какие тесты адресуют, какие части исходного кода мне кажутся трудными, а не те, которые поддерживаются TeamCity AFAIK.