Как разрешить развертывание нескольких типов?

Ответ 1

Если вы ищете улучшенный опыт развертывания в Visual Studio, проверьте решение Flexera InstallShield Limited Edition in-box (ISLE, http://blogs.msdn.com/b/visualstudio/archive/2013/8/15/what-s-new-in-visual-studio-2013-and-installshield-limited-edition.aspx). ISLE - отличное решение для тех клиентов, которые ищут дополнительные возможности, не найденные в проектах установщика Visual Studio, такие как интеграция с TFS и MSBuild, поддержка создания новых веб-сайтов и поддержка меток ISO 19770-2 и т.д.

VS2015: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2015InstallerProjects

VS2017: https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects

С помощью шаблонов проекта установки и развертывания вы можете выбрать пакет всех сборок в решении или каждый отдельно в качестве MicroService с помощью проектов Setup, Web, CAB или Merge Module:

Затем выберите, какие сборки включены:

Ответ 2

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

Вы указали два сценария развертывания: развертывание одного проекта (например, микросервис) и развертывание всех проектов (полное развертывание). Пусть начнется небольшое...

Развертывание отдельного проекта

Главное, чтобы планировать, это то, что каждый развертываемый атом (это может быть проект или бэкэнд службы + БД... что-то такое же маленькое, как вы бы предпочли не разделить его на более мелкие развертывания).

Для веб-проектов (будь то проекты веб-API или другие типы), встроенные параметры Visual Studio можно в целом суммировать как: WebDeploy, Azure, и теперь с .NET Core, Docker images. Я не буду вдаваться в подробности каждого, потому что это отдельные вопросы. Но я могу сослаться на некоторые подробности для вас, чтобы исследовать, если они звучат интересно (я более знакомы концептуально с WebDeploy, поэтому я буду говорить об этом много, но я не сторонник его или против него).

Если вы использовали WebDeploy, например, каждый проект может создать пакет WebDeploy. (Опять же, посмотрите на это подробнее, как это сделать). Этот пакет может быть создан для хранения файловой полезной нагрузки (файлов сайта/службы), а также полезной нагрузки базы данных или других субатомных систем с использованием модели поставщика WebDeploy. Visual Studio имеет довольно приличную поддержку для этого сценария, и на нем есть документация.

Или вы можете создать изображение Docker. Из моего понимания (и отсутствия опыта работы с Docker пока), если вы хотите развернуть свой веб-сервис и базу данных, они должны быть в отдельных контейнерах. Скоро вы сами создадите их вне VS. Это не плохо, Докер звучит очень гибко, как только вы его повесите; но вы оставляете IDE для этого.

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

Развертывание решения

Итак, у вас есть много этих пакетов для атомного развертывания. Как вы их раскалываете?

Хорошо, на данный момент VS не предоставляет много для вас. И трудно обосновать, что VS должен делать здесь. Почти каждая организация собирается разработать несколько иные правила. Развертываете ли вы из своего CI? Создаете ли вы пакеты и развертываете их в разных средах в конвейере выпуска? Или вы делаете это в облачных и горячих средах (например, слоты для развертывания Azure)?

Собственное решение VS должно быть либо чрезвычайно настраиваемым (и, следовательно, чрезвычайно сложным), либо оно будет слишком простым для удовлетворения потребностей большинства клиентов. (В стороне от первоначальной поддержки WebDeploy в VS2010 с ошибкой на первом из них. Это было чрезвычайно настраиваемо и очень сложно для клиента или даже команды продукта обернуть головы вокруг всех возможных сценариев. QA для этой функции когда-то.)

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

VS обычно организует вещи с помощью MSBuild. Опять же, я не выступаю за это как свою платформу оркестровки (мне на самом деле это не нравится), это нормально для вашей конфигурации проекта, но IMO не подходит для управления задачами), но если это то, что вы хотите использовать, он может работать. Это довольно просто, если вы используете его для сценария веб-проекта. Вы можете построить свое решение и использовать параметр /p:PublishOnBuild=true. Если вы используете WebDeploy для прямой публикации, все готово! Если вы создаете пакеты WebDeploy, вам все равно нужно нажать их, но, по крайней мере, вы их создали сразу.

Если вы используете пакеты WebDeploy, каждый из них будет генерировать script для публикации. Существуют также способы передачи в разных параметрах WebDeploy, поэтому вы можете повторно использовать один и тот же пакет (сборку) для публикации в разных средах. Однако вам придется написать свой собственный script, чтобы объединить все это в одно мегалитическое развертывание.

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

Там также более общие платформы оркестровки, такие как Octopus Deploy.

Как неудовлетворительно!

Да, это отстой, что не существует готового решения для широкомасштабных развертываний. Но если бы это было так, это не сработало бы для 95% команд. Большая часть того, что предлагает VS, достаточно для отдельной или очень небольшой команды разработчиков, чтобы получить код на своих серверах. Любая большая часть команды, и вы получите лучший пробег из строя системы, которая разработана для вашей команды. Есть множество инструментов, и ни один из них не работает отлично во всех случаях. Найдите ту, которая работает для вас, и со мной все будет в порядке. И, в конце концов, все сводится к тому, чтобы нажимать файлы и запускать скрипты. Если вам не нравится одна система или инструмент, вы можете попробовать другой.

Ответ 3

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

Взяв ваш пример с этими тремя различными исполняемыми файлами в качестве отдельных микросервисов (Service A, B, C) и в качестве полного сервиса (Startup) в контексте Web.Api, вы можете сделать следующее:

• Каждый проект (Service A, B, C) может быть разработан как отдельный автономный исполняемый файл OWIN (как указано в Использовать OWIN для Self -Host ASP.NET Web API 2) и предоставить один или несколько конечных точек, которые будут показаны.

• Основным проектом (Startup) может быть сам хост OWIN или обычное приложение IIS Web.Api, которое ссылается на три проекта (службы A, B, C) и загружает их соответствующие конечные точки в свой собственный Startup (и, возможно, дополнительные конечные точки).

Затем вы можете использовать отдельный проект конфигурации в Visual Studio (или внешний проект в совершенно другой среде) и использовать технологии развертывания, такие как Puppet, Chef или что-то другое для развертывания в соответствии с вашими сценариями.

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

Если это не отвечает на ваш вопрос или если я неправильно понял ваш вопрос, не могли бы вы прояснить его и дать более подробную информацию?

Ответ 4

Когда мы говорим о смысле жизни, вот две центы об этом специалисту по развертыванию (установке): -) - ответ (кажется:-) долго, но он будет содержать определенную информацию, где искать каждая точка..

Прежде всего, позвольте утверждать, что развертывание НЕ является знатоком, хотя многие разработчики хотели бы видеть это как это (и, как специалист по развертыванию, я наблюдаю довольно часто заинтересованные стороны в процессе разработки программного обеспечения, фактически думая так:, развертывание забыли до дня до отгрузки: -)

Сравните это с колом для жирного и простого примера. "Разработчики" производят жидкость, но здесь довольно легко понять, что работа еще не завершена.: -)

Visual Studio сама по себе не поддерживает стратегии развертывания. Основываясь на нескольких областях развертывания, упомянутых в следующем списке, есть, конечно, много технологий, некоторые из которых помогают Microsoft. Я бы хотел создать сборку для разных клиентов или сценариев, которые устанавливают поднаборы служб, таких как сценарии клиент/сервер или другие (см. № 3. в следующем списке.)

Во-вторых, как вы могли видеть из других ответов, развертывание не является развертыванием. Отчасти это зависит от того, рассматривается ли развертывание как просто создание двоичных файлов с помощью MSBuild или развертывание в тестовой системе или развертывание для клиента, например. путем обновления продуктивного веб-сайта или создания DVD-дисков или загрузки исполняемых файлов на веб-сайт обновлений...

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

• Развертывание, рассматриваемое как часть архитектуры, должно иметь дело с исходными и двоичными структурами и сущностями, например. проект и двоичная структура (сколько файлов .exe,.dll, как их зависимости, планирование вариаций. = > Как вы уже упоминали, вы находитесь здесь в области (Visual Studio и т.д.) Решений, проектов, а также пространств имен, особенно в области WCF, у вас есть контракты и т.д., У вас есть (POС#) интерфейсы и т.д. У вас есть Nuget или другие инструменты для разрешения и управления зависимостями. .NET должен предложить концепцию сборки для решения этой проблемы, например, в архитектуре. если развернуть интерфейсы и контракты в собственных сборках, как справляться с сценариями клиент/сервер, как зависят друг от друга сборки, зависит от вас и архитектуры.

  • Что касается сервисов, есть интересная подзадача, как размещать службы, они могут размещаться на веб-сервере, они могут быть самозахватами в .exe, они могут быть размещены с помощью IIS или OWIN и т.д. Ссылки для получения дополнительной информации:

  • Самохостинг в WCF: https://msdn.microsoft.com/en-us/library/ee939340.aspx

  • Selfhosting в службе Windows, здесь с SignalR: https://code.msdn.microsoft.com/windowsapps/SignalR-self-hosted-in-6ff7e6c3

  • Хостинг с OWIN: https://en.wikipedia.org/wiki/Open_Web_Interface_for_.NET

• Развертывание как часть локальной интеграции Windows или другой операционной системы: вам нужно подумать о том, в каких системных каталогах вы должны размещать определенные файлы или данные в целом. Вам нужно подумать об общих DLL, обмениваемых данных, данных проекта, временных данных, данных пользователя, реестре, файловой системе, требованиях к логотипу Windows, передовых методах, конфигурации сервиса и т.д.

• Развертывание как процесс создания настроек, собственные установки, которые, помимо прочего, выполняют необходимые действия, упомянутые в 2-, с дополнительными задачами, такими как графические (графический интерфейс установки), подтверждение лицензии, какой новый раздел, выбор дополнительных компонентов (просто подумайте о настройке Visual Studio), удалите/восстановите/измените возможности и т.д.

• Развертывание как процесс devops, например. часть непрерывной интеграции, непрерывной доставки и/или непрерывного развертывания, Вот два основных момента: Технически, чтобы иметь определенный процесс, который делает вещи, упомянутые в пунктах 2. и 3. (или, альтернативно, шаги развертывания в Интернете) автоматически как часть процесса сборки ( "шаг после сборки" ). Это может включать в себя создание настроек или иерархии настроек или вообще без установки). Во-вторых, чтобы тестеры, разработчики и менеджеры (или даже клиенты) могли видеть по крайней мере каждое утро или даже чаще уже установленный пример последней ночной или ежедневной сборки, возможно, с несколькими вариантами развертывания (клиент/сервер?, базовые /prof?) или в разных системах. Вы здесь наполовину в мире разработчиков, наполовину в мире админов. Здесь основное внимание часто не создает сложные настройки, как в 3. но прежде всего для определения собственных процессов "pack" и copy (и sign... и т.д.), А также для автоматизации их как части разработки (и тестирования и доставки) обработать. Кукольный и Шеф-повар.

• Развертывание в качестве развертывания в Интернете или облаке (также может быть конечной точкой процесса детограмм) - другие говорили об этом, я опускаю детали здесь, но важная дифференциация - это если вы говорите о развертывании клиента или развертывания в промежуточную тестовую или промежуточную систему. Возможно, одна вещь, которая стоит упомянуть дополнительно к devops, заключается в том, что развертывание на онлайн-серверах, фермах серверов или облаке имеет очень серьезные проблемы.

• Развертывание рассматривается прежде всего как административный процесс распространения shippable, buyed и/или собственного программного обеспечения для всех тысяч компьютеров в компании и дочерних фирмах. есть, конечно, специальные инструменты для этого, включая стратегию обновления, мониторинг, управление лицензиями и многое другое. Вы здесь, в мире админов, а не в мире разработчиков. Microservices станет новой и сложной задачей для администраторов, которые в основном используются для установки и распространения "больших" пакетов, таких как MS Office или Oracle или вообще.

  • Этот вопрос не настолько скучен для разработчиков, как кажется. Первичный, потому что два "мира" разработчиков и администраторов сливаются. И разработчики должны заботиться о представлении клиентов о "запуске программного обеспечения в реальном мире". Devops - это только начало. Все знают виртуальные машины, но теперь у нас есть программное обеспечение, определяемое сетью, виртуальными приложениями, фермами виртуальных серверов, облаком и т.д. Вы можете определить архитектуру развертывания по зависимостям без какого-либо программирования только по конфигурации. Поэтому развертывание должно быть частью архитектуры вашего приложения, но в основном это недостаточно (достаточно). Фактически до сих пор админ-просмотр почти нигде не интегрирован с точки зрения производителей/разработчиков программного обеспечения. Что касается Microsoft, здесь много работы сделано командой Windows, особенно. в серверной линейке продуктов, и это никогда не было стратегически согласовано с командой разработчиков AFAIK (это, вероятно, действует для КАЖДОГО магазина программного обеспечения до сих пор: -)

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

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

У самой Visual Studio больше нет собственной поддержки более сложных типов настроек, таких как MSI, и особенно никогда не было для группировки настроек в пакеты, что может быть одним из возможных решений развертывания пучка (или варианты сгустков) услуг - VS имеет, например, некоторую поддержку развертывания "ClickOnce", но это было сделано больше для клиентов базы данных ( "умных" ), чем для служб или даже микросервисов. ClickOnce: https://msdn.microsoft.com/de-de/library/31kztyey.aspx

Замена отсутствия "реальной" установки в Visual Studio может быть набором WiX, который представляет собой проект с открытым исходным кодом, созданный сотрудниками Microsoft. Или InstallShield Express (который является бесплатным, но ограниченным вариантом коммерческих). С помощью обоих вы можете создать полные настройки MSI, которые, возможно, являются самым сложным типом установки в зоопарке установки Windows.

a) Конечно, существуют и другие типы настроек помимо MSI (например, установщик Windows), они принадлежат сторонним поставщикам, которые более или менее проприетарны, но более просты:, например, Nullsoft - NSIS и InnoSetup.
Я не буду давать ссылки для создания одиночных установок MSI, потому что их можно легко найти с помощью указанных ссылок создания пакетов MSI-установок в следующих строках:

б) Инструмент для создания установок, которые выбирают и устанавливают другие (определенные подмножества базового) в мире Wix, называется "Burn":

Создание пакетов настроек с Запись: http://wixtoolset.org/documentation/manual/v3/bundle/

Специальная (платная) поддержка для этого вы можете получить, например, от основателя WiX, который специально создал компанию: https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/ Роб Мэншинг, основатель, можно найти здесь, в SA, также отвечая на заданные вопросы.

c) Установки InstallShield Suite: Другим является уже упомянутый инструмент InstallShield, но для этого вам понадобится вариант InstallShield Premium, который стоит долларов:
http://helpnet.installshield.com/installshield21helplib/helplibrary/SteCreatingSuites.htm

d) Настройка Factory: https://www.indigorose.com/setup-factory/

e) Я уверен, что многие люди посоветуют взглянуть на Docker. Виртуальные приложения - это не только настройки, но они изолируются в "установленном" состоянии от других приложений, таких как песочница. См. Например https://docs.docker.com/docker-for-windows/

е) Список будет неполным, если я не буду упоминать APP-V как технологию установки виртуальных приложений, которая разделяет некоторые, но не все функции с докером. Но эти технологии на самом деле не предназначены для организации нескольких поставок, а для доставки всего лишь одного приложения. И Microsoft определила новый тип установки, называемый AppX. Особенно вам нужно различать, если вы хотите создать "устаревшие" (полные) настольные приложения для Windows, где настройки MSI - это известная технология для или новых приложений, которые являются новым типом, начиная с Windows 8 (aka Universal Windows apps, например, приложений Windows Store aka современные приложения, например, приложения Metro).

AppX: https://msdn.microsoft.com/en-us/library/windows/desktop/hh446767(v=vs.85).aspx AppX нацелен на более простой тип настройки, чем MSI.

Универсальные приложения Windows (UWP): https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp

Для получения более подробной информации мы должны знать больше ваших требований.