Рабочий процесс для непрерывной интеграции и автоматической маркировки версий: проекты .NET + CC.NET + SVN + MSBuild - PullRequest
Новая
       21

Рабочий процесс для непрерывной интеграции и автоматической маркировки версий: проекты .NET + CC.NET + SVN + MSBuild

4 голосов
/ 08 февраля 2012

Я использую SVN + CruiseControl.NET + MSBuild для создания проектов .NET. Это специфика технологии, чтобы вы понимали окружающую среду и мою терминологию, но вопрос носит более общий характер.

Прямо сейчас мой рабочий процесс CI довольно прост:

  1. CC.NET обнаруживает новую версию ствола проекта, обнаруженную в SVN
  2. Рабочая копия CC.NET обновлена ​​из SVN
  3. MSBuild запускается для файла .proj в транке
  4. Выполнены юнит-тесты
  5. В случае успеха проект копируется / развертывается

На шаге 3 я бы хотел "поставить" номер версии на сборке; в моем случае в файле AssemblyInfo.cs, скорее всего, используется что-то вроде задачи AssemblyInfo из msbuildtasks. Кроме того, я хотел бы иметь возможность повторить эту сборку под конкретным номером версии. Прямо сейчас я думаю, что, вероятно, после шага 4 мне нужно будет зафиксировать / пометить обратно в SVN проект с помеченным AssemblyInfo.cs, но у меня возникли проблемы с поиском наиболее простого способа сделать это.

Если я фиксирую проект с штампованным файлом AssemblyInfo.cs обратно в хранилище, он не может быть в транке, так как это вызовет другую автоматическую сборку: бесконечный цикл. Итак, я предполагаю, что для этого потребуется перейти к новому тегу. Затем я бы пометил ревизию, переключил рабочую копию на метку, зафиксировал, а затем переключился обратно на транк. Это обычный способ?

Или я слишком усложняю это? Стоит ли мне беспокоиться о том, чтобы вернуть эту сборку обратно в репозиторий или просто заархивировать собранный проект и сохранить его в структурированном месте в файловой системе?

Ответы [ 2 ]

3 голосов
/ 17 февраля 2012

В моей текущей и предыдущей компании.мы штампуем / модифицируем assemblyInfo.cs во время сборки и фиксируем обратно файлы assemblyInfo после каждой успешной сборки.

Для предотвращения бесконечного цикла;мы исключаем asssemblyInfo.cs из запуска сборки в конфигурации ccnet.

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

Я все еще изучаю более эффективные способы управления версиями AssemblyInfo:)

добавлено через 2 часа:

После некоторых исследований;вместо передачи ассемблированной информации обратно в транк;некоторые люди создают тэг рабочего каталога (с измененной сборкойInfo). CCNET поддерживает этот механизм: SVN TagOnSuccess, рабочая копия и обновленный AssemblyInfo.cs

Джереми Миллер использует этот подход http://codebetter.com/jeremymiller/2007/12/06/do-you-really-know-where-that-code-has-been/

недостаток: тегов будет много

1 голос
/ 08 февраля 2012

Вам не нужно задание msbuild для печати версий. CCNET сделает это за вас. Задача в стиле msbuildtasks только для TFS, где она не встроена.

Нет причин беспокоиться о проверке в файле assemblyinfo. Пока есть метка (или как ее называет svn), у вас все в порядке.

Что касается повторного запуска точной копии сборки, я бы сказал, просто сжать их и сохранить те, которые на самом деле используются. Вам не нужно хранить каждую сборку.

То, что я всегда делал, - это сборка CI, которая запускается при каждой регистрации, плюс сборка выпуска, которая запускается только вручную для развертываний. Сборка CI вообще не получает номер версии и нигде не сохраняется. Версионная сборка получает номер версии и сохраняется.

...