Подход непрерывного развертывания для исходного Asp.Net-MVC

Политики удаленного клиента не позволяют мне публиковать из моей среды разработки непосредственно на их сервер. Я удаляюсь в среду и копирую опубликованные артефакты (Asp.Net-MVC) в тестовую среду. Процесс развертывания между различными средами (сборка/тестирование/постановка/производство) в настоящее время выполняется вручную, что отнимает много времени и чревато ошибками.

Я знаю, что есть инструменты, которые уже существуют, и рассмотрел несколько решений CI и CD, но многие из них выглядят излишними для того, что я хочу в данный момент. Изучил Jenkins, Octopus, MSDeply, PSDeploy, Robocopy и другие, чтобы назвать несколько, но теперь я не уверен, какой путь выбрать. Прочтите о подходе непрерывного развертывания, которого я в конечном итоге хочу достичь, поскольку я действительно пытаюсь не изобретать велосипед и писать свой собственный инструмент развертывания, который является неприятной привычкой, которую я пытаюсь сломать, учитывая множество шляп, которые я должен носить.

Любые советы о том, как автоматизировать этот процесс на автономном сервере? На этом этапе основное внимание уделяется перемещению файлов, а не миграции баз данных.

Спасибо




Ответы (2)


Сервер CI по своей сути является просто исполнителем задач. Jenkins — отличный CI-сервер с открытым исходным кодом и множеством плагинов.

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

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

msbuild someproject.sln /p:DeployOnBuild=true /p:PublishProfile=Prod

Jenkins можно настроить для выполнения этой сборки по запросу или всякий раз, когда что-то возвращается.

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

person Josh    schedule 14.01.2016
comment
В моем случае я делаю сборку в своей среде, а затем копирую ее в свою среду. Смогу ли я тогда просто выполнить аспект развертывания, используя профиль публикации для тестирования, подготовки и производства, когда это необходимо? - person Nkosi; 14.01.2016
comment
@Nkosi - В этом случае я бы посмотрел на создание пакета публикации. Вам придется кое-что узнать о MSDeploy, но это позволит вам создать один пакет и развернуть его в нескольких средах. Вы даже можете переопределить настройки по мере необходимости. - person Josh; 14.01.2016
comment
Я внесу его в список тогда. Спасибо. - person Nkosi; 14.01.2016
comment
@Nkosi - Стоит отметить, что почти все это можно сделать и с помощью powershell. Если вам не нужно сложное, простой сценарий PowerShell прост и понятен. - person Josh; 14.01.2016
comment
И я полагаю, мне следует уточнить, что создание пакета, а затем вызов MSDeploy можно выполнить с помощью powershell :) - person Josh; 14.01.2016
comment
Да, я понимаю. Как я уже говорил, я создаю пакет в своей среде, а затем копирую его на сервер. Я буду использовать ps для вызова MSDeploy. В очередной раз благодарим за помощь. - person Nkosi; 14.01.2016

Почему бы не использовать управление релизами? Это инструмент Microsoft, который отлично подключается к tfs через свой шаблон. Вам необходимо создать определение сборки, используя сервер сборки, который настроен на CI, что означает, что каждая регистрация будет загружать код в необходимые среды в управлении выпусками. Вы можете создать этап утверждения, на котором будут загружаться только утвержденные сборки. Чтобы включить работу разработчиков и регистрацию без загрузки элемента, просто создайте 2 ветки HEAD и DEV и поместите свой слушатель ci (исходную папку) только в HEAD . Когда разработчик сольется с DEV на HEAD и зарегистрирует файлы, они будут загружены.

person boaz levinson    schedule 23.01.2016