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

Question

Я довольно новичок в использовании непрерывной интеграции в рамках обычного процесса разработки в качестве разработчика. Однако я поставил задачу ввести ci в нашу команду разработчиков программного обеспечения и поэтому сделал некоторые попытки выполнить это.

В настоящее время мы имеем следующее: 0. Bitbucket как наш источник репо 1. Команда города 2. ProGet сервер 3. Octopus Deploy 4. Developement тестирование VM 5. UAT испытания VM 6. Производство В.М.

В целом процесс идет

1. пункт Список
2. ЗАКАНЧИВАТЬ решение от BitBucket
3. Внесите изменения.
4. Обязаться Bitbucket
5. Team City Строит
6. Team City толкает артефакты ProGet, как NuGet пакетов
7. Team City создает релиз в Octopus Deploy и развертывание запуска автоматического тестирования на виртуальной машине развития.
8. Руководство Octopus нажать на ЕСХН
9. Руководство Octopus толчок к производству

Все, начиная от верхнего уровня выглядит хорошо для всех, кроме нас разработчики.

Наша проблема заключается не в концепции, а в живом процессе. Причина в том, что у нас есть два решения, в которых вторая ссылается на пакет nuget первого решения с нашего сервера ProGet. Это означает, что каждый раз, когда зависимое решение нуждается в модификации в первом решении, нам нужно дождаться появления цикла, а затем обновить пакет nuget во втором, чтобы выполнить необходимые изменения.

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

Что бы я хотел, это разработать оба решения на компьютере разработчика, не дожидаясь, когда ci создаст и опубликует измененный пакет. Это, я думаю, означает dll из первого решения, на которое нужно ссылаться локально, но как я могу изменить это, поэтому окончательная ссылка с сервера ProGet будет построена на поле CI?

Может ли кто-нибудь сказать мне, как это сделать?

Answer 1

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

Рассмотрите этот учебник Deploying ASP.NET and Windows Service Applications with Otter - идея состоит в том, что создание решения через MSBuild (либо в режиме Release на вашей рабочей станции, либо в TeamCity) создает файл пакета (UPack или NuGet, не имеет значения).

Затем, как разработчики, вы можете добавить шаг для использования Otter Romp для локального конфигурирования и развертывания этого пакета и обычного Otter, чтобы гарантировать, что пакет/конфигурация существует в других средах. Таким образом, это последовательный подход к локальному разработчику для тестирования продукта.

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

Смотрите также: KB#1114 - A Comparison: Octopus Deploy vs Otter

__

Отказ от ответственности, мой день работа в Inedo :)