Автоматическое создание патчей и развертывание приложений .NET

Question

Вопрос в краткой форме, а затем объяснение Мы хотим создать исправления и включить только файлы, которые были изменены в сборке из-за некоторых исправлений для приложения dotnet. Патчи должны автоматически создаваться в процессе непрерывной интеграции с использованием SVN, Cruisecontrol.net и msbuild.

У нас есть сценарий здесь: Мы хотим поддерживать приложение .net, которое работает на удаленных серверах, используя непрерывную интеграцию. Исходный код находится в SVN и имеет 3 разных репозитория для DEV, QA и PROD. Наши разработчики делают новые исправления ошибок почти каждый день и объединяют изменения в репозиторий dev после их первоначального тестирования и удовлетворения. Код после того, как определенная проблема решена или добавлена ​​функция, затем объединяется в хранилище QA. Код QA встроен и протестирован на QA-машинах вручную. После тестирования QA мы объединим его в PROD. При этом QA также создает новые исправления для файлов, которые необходимо заменить или изменить вручную. Затем патчи развертываются на промежуточном сервере. На нем он тестируется до совершенства, а затем патчи развертываются на реальных удаленных серверах.

В поисках непрерывной интеграции мы теперь пытаемся использовать сочетание CruiseControl.net и msbuild для выполнения этого процесса. Процесс хорош до этапа, на котором мы должны генерировать исправления из строя QA автоматически. После создания патчей мы помещаем их на ftp-сервер, и из них они будут загружены на промежуточный сервер для тестирования. Проблема в том, что создание патчей из новой сборки имеет несколько аспектов. Файл решения для приложения имеет много проектов, и библиотеки dll копируются с использованием событий postbuild в папку bin приложения-запуска. Таким образом, у нас есть конкретная структура каталогов в фактическом приложении, которое само представляет собой комбинацию из 6 решений, которые более или менее независимы друг от друга.

Как мы пытаемся создать патчи, мы ищем журналы svn, чтобы найти файлы, которые были изменены. Затем мы анализируем его поиск имени проекта. Затем мы копируем все файлы из каталога bin этого проекта в папку патча определенным образом, в котором релиз имеет их, используя файл сопоставления, в котором есть все файлы приложения.

Так кто может предложить гораздо лучший или простой способ сделать патч, если у нас есть svn и cruisecontrol.net. Или любой другой инструмент с открытым исходным кодом для этого.

надеяться, что проблема ясен

Answer 1

Если ваша задача MSBuild выполняет сборку вместо восстанавливания то дата/время непораженных DLLs не иметь их измененную дату изменилась.

Я хотел бы предложить это по следующим причинам:

• MSBuild будет обновлять измененную дату для любой сборки, которая была затронута изменением - Т.е. изменение интерфейса?
• сборка - это то, что вы хотите развернуть, поэтому проверьте это, а не источник на наличие изменений. В противном случае вам нужно знать процесс сборки (не изменится) - I.e. Суевые местоположения файлов, ссылки и т. Д.

Ваше развертывание будет включать только DLL-файлы из каталогов сборки, в которые была изменена дата> = BuildDate.

Answer 2

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

По сути, вы не используете среды QA и DEV для обеспечения стабильности производства. Хуже того, вы используете разные деревья источников для создания кода для них. Это приводит к появлению новых точек возможных сбоев в процессе развертывания.

Стандартный способ приближения к этому состоит в том, чтобы иметь единственное дерево кода SVN - пометить версию, когда она будет выпущена в QA (с использованием уже построенных двоичных файлов!), Возможно, снова пометить ее при выпуске в PROD. Не перестраивайте двоичные файлы, используйте те, которые вы действительно тестировали!

Answer 3

Я согласен с skolima о рекомендуемой сборке & Процесс исправления. Вы должны создать свои исправления из ваших исходных тегов плюс изменения, а затем создать новую версию, которая должна быть развернута во всех средах.

В моей компании, мы используем этот метод:

1. Каждой преуспевающую сборку автоматически помечаются нашим CI сервер
2. Когда патч необходим для конкретной версии, программисты скопировать & регистрации по прибытию out tagged version и применить исправления на нем
3. Тогда у нас есть конкретная сборка «Patch» на нашем CI-сервере, которая делает точно такой же, как обычная сборка с флагом «Patch» и указывает на исправленные источники

Цель развертывания такая же, процесс сборки одинаков, только источники меняются.

Плюс - это патчей, имеющих собственную историю сборки на CI, потому что они построены отдельно, но рассматриваются как обычные сборки.

В любом случае, если вы хотите автоматизировать процессы исправления между двумя репозиториями через ваш CI, ihmo вам нужно создать определенные задачи MSBuild для этого. Вы можете либо попытаться слияния изменения между ними или проверка функции SVN Diff & патч команды.