Комментарии 10
Если линковать на шару, то могут быть проблемы с доступностью приложения.
Спасибо, интересный подход, надо взять на вооружение.
У меня на данный момент сделано следующим образом: есть каталог в Program Files и в нем лежат различные версии сборки (т.е. Site-2.1.10.0, Site-2.2.0.0 и т.п.), и я в IIS (в свойствах сайта) просто меняю путь на новую версию. При таком способе в IIS всё автоматически подхватывается, но есть проблема в том, что если в предыдущей версии были изменения в конфигурационном файле, то их нужно вручную редактировать в новой версии.
У меня на данный момент сделано следующим образом: есть каталог в Program Files и в нем лежат различные версии сборки (т.е. Site-2.1.10.0, Site-2.2.0.0 и т.п.), и я в IIS (в свойствах сайта) просто меняю путь на новую версию. При таком способе в IIS всё автоматически подхватывается, но есть проблема в том, что если в предыдущей версии были изменения в конфигурационном файле, то их нужно вручную редактировать в новой версии.
Тоже делаю так на тестовых серверах. Не вижу у подхода с симлинками особых преимуществ.
Для любителей консоли всё одной строчкой настраивается.
PowerShell:
То же в обычном cmd:
Разве что при наличии вложенных виртуальных директорий путь к каждой нужно задавать отдельно, поскольку все пути абсолютные. Если они все внутрь корневого каталога смотрят, симлинк позволит заменить их разом.
Вносить изменения в конфиг можно так же через PowerShell или appcmd.
Для любителей консоли всё одной строчкой настраивается.
PowerShell:
Import-Module WebAdministration
Set-ItemProperty 'IIS:\Sites\Default Web Site\MyApp' -Name PhysicalPath -Value 'C:\Dev\MyApp\1.1\'
То же в обычном cmd:
%systemroot%\System32\inetsrv\appcmd.exe set vdir "Default Web Site/MyApp/" -physicalPath:"C:\Dev\MyApp\1.1"
Разве что при наличии вложенных виртуальных директорий путь к каждой нужно задавать отдельно, поскольку все пути абсолютные. Если они все внутрь корневого каталога смотрят, симлинк позволит заменить их разом.
Вносить изменения в конфиг можно так же через PowerShell или appcmd.
Очень хрупкое решение, если честно.
Есть же Octopus Deploy, который скачает артефакт билда, вытащит одну машину из лоад-балансера, удалит текущую версию сайта, распакует новую версию, заменит плейс-холдеры в конфигурационных файлах, запустит сайт и если сайт ответит на простой heals check, то машина вернётся в лоад-балансер.
Таким образом вы добиваетесь стабильно повторяемых релизов, ни каких шаманств с симлинками, нет нужды хранить несколько версий сайта на сервере.
Ну во-первых это решение бесплатнее Октопуса.
Во-вторых для стабильной повторяемости это решение нужно использовать как оконечник для Bamboo, а не само по себе.
А вообще спасибо, сейчас поставлю Октопус, посмотрю, может правда им лучше.
Во-вторых для стабильной повторяемости это решение нужно использовать как оконечник для Bamboo, а не само по себе.
А вообще спасибо, сейчас поставлю Октопус, посмотрю, может правда им лучше.
Октопус бесплатен для маленьких команд (а большие зарабатывают достаточно). И да, вам нужно хранилище артефактов, но если у вас уже есть билд-сервер, то добавить ему степ Octopack и публикацию артефакта не очень трудно. Бесплатный ProGet или любой другой in-house сервис подойдёт.
Кроме того вы получаете нормальные дашборды, нотификации, хранение скриптов, простые роллбэки и шифрование конфигураций. Поверьте, те инвестиции, которые требуются на настройку и развёртку этого решения, окупаются очень быстро. Деплой перестаёт быть проблемой.
Посмотрите на их дэмо сервис, поиграйте. Оно того стоит.
Когда возникла необходимость располагать несколько проектов в едином репозитории, при этом сохранить общее независимое ядро с возможностью индивидуального развертывания любого из проектов, то решение с символическими ссылками было весьма кстати, действительно удобный функционал. Правда у нас совсем не вэб и нам очень повезло, что Unity дружит с символическими ссылками.
Интересная идея, хотя, кажется, что правильнее было бы управлять этим процессом в IIS а не на уровне файловой системы.
Мы у себя для этого используем прокси-приложение, некое подобие лоадбалансера, которое в реалтайме определяет, на какую версию нужно направить клиента.
Кстати в тему деплоя.
Два года назад, когда мы страдали при деплое нашего asp.net приложения, я долго смотрел на Octopus, TeamCity, Bamboo и т.п.
Мне всё не понравилось. Билд серверы были чем-то вроде обертки над командной строкой с планировщиком, а октопус работал с версиями не так, как нам хотелось, интеграция тоже была так себе и не была из коробки. (У нас хитрый кейс, когда на живых серверах одновременно работает сразу несколько версий, как минимум текущая и следующая)
Было принято волевое решение написать свой CI сервер с деплоем и куртизанками (как бы это адово не звучало).
Исходники доступны: github.com/adoconnection/AspNetDeploy
Основные идеи:
нет скриптам, нет командной строке, все должно быть красиво
правильный CI это и сборка и публикация в одном флаконе (continuous delivery, если угодно)
в интерфейсе я должен оперировать проектами, указывая только куда и как их деплоить, а как оно будет собираться и паковаться — проблемы CI сервера
программисты не должны мешать QA команде, когда дело доходит до публикации на тестовые сервера, именно тестировщики инициируют деплой, тогда, когда им удобно начать тестировать следующую фичу
не должно получиться случайного деплоя на живой, поэтому релиз запускает старший разработчик, но обязательно с отмашки qa, которые должны зааппрувить один из билдов, как пригодный для заливки на живой.
Что умеет:
доставать исходники из SVN
парсить все проекты солюшена, понимать их тип (WebProject, Tests, ConsolApp, DatabaseProject)
из проектов собираются пакеты – то, что должно быть опубликовано за один раз. Для каждого типа проекта AspNetDeploy предлагает релевантный вариант публикации: если сайт — как его опубликовать в IIS, как настроить конфиги, если DatabaseProject — как его задеплоить в MSSQL
много серверов, у каждого одна или несколько ролей, сервера объединяются в среды, а среды связаны между собой. Например test -> staging -> live
удобные переменные, можно сразу увидеть и отредактировать значение переменной на всех средах
и все это имеет версионность
Если это хоть немного интересно, могу написать небольшую статью. Почему-то, я уверен, что это должно быть полезно другим людям.
Еще очень хочется единомышленников найти и довести UI до ума.
Мы у себя для этого используем прокси-приложение, некое подобие лоадбалансера, которое в реалтайме определяет, на какую версию нужно направить клиента.
Кстати в тему деплоя.
Два года назад, когда мы страдали при деплое нашего asp.net приложения, я долго смотрел на Octopus, TeamCity, Bamboo и т.п.
Мне всё не понравилось. Билд серверы были чем-то вроде обертки над командной строкой с планировщиком, а октопус работал с версиями не так, как нам хотелось, интеграция тоже была так себе и не была из коробки. (У нас хитрый кейс, когда на живых серверах одновременно работает сразу несколько версий, как минимум текущая и следующая)
Было принято волевое решение написать свой CI сервер с деплоем и куртизанками (как бы это адово не звучало).
Исходники доступны: github.com/adoconnection/AspNetDeploy
Основные идеи:
нет скриптам, нет командной строке, все должно быть красиво
правильный CI это и сборка и публикация в одном флаконе (continuous delivery, если угодно)
в интерфейсе я должен оперировать проектами, указывая только куда и как их деплоить, а как оно будет собираться и паковаться — проблемы CI сервера
программисты не должны мешать QA команде, когда дело доходит до публикации на тестовые сервера, именно тестировщики инициируют деплой, тогда, когда им удобно начать тестировать следующую фичу
не должно получиться случайного деплоя на живой, поэтому релиз запускает старший разработчик, но обязательно с отмашки qa, которые должны зааппрувить один из билдов, как пригодный для заливки на живой.
Что умеет:
доставать исходники из SVN
парсить все проекты солюшена, понимать их тип (WebProject, Tests, ConsolApp, DatabaseProject)
из проектов собираются пакеты – то, что должно быть опубликовано за один раз. Для каждого типа проекта AspNetDeploy предлагает релевантный вариант публикации: если сайт — как его опубликовать в IIS, как настроить конфиги, если DatabaseProject — как его задеплоить в MSSQL
много серверов, у каждого одна или несколько ролей, сервера объединяются в среды, а среды связаны между собой. Например test -> staging -> live
удобные переменные, можно сразу увидеть и отредактировать значение переменной на всех средах
и все это имеет версионность
Если это хоть немного интересно, могу написать небольшую статью. Почему-то, я уверен, что это должно быть полезно другим людям.
Еще очень хочется единомышленников найти и довести UI до ума.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Деплой ASP.NET приложений при помощи символических ссылок