Разрабатываем некий программный комплекс(не знаю, как это обозвать по человечески...), в составе которого имеется пару ASP.NET приложений, пару windows service и ещё куча всякого мусора.
Используется это в двух вариантах с небольшими отличиями в конфигах: cloud (мы сами хостим и обслуживаем) и on-premises (продаём)
Для этого хозяйства есть самописный сетап, который, в принципе, справляется с этой задачей, но делает это медленно. Проверка простейших фиксов в web приложении выливается в 20 минутный апдейт руками, где нужно периодически нажимать next-next-next-reboot. Сборка сетапа из исходников тоже занимает порядочно времени.
Хочется как-то перевести деплоймент web приложения в cloud конфигурации на какие-то более быстрые рельсы.
И вот я пытаюсь найти решение, которое:
1. позволит быстро деплоить web часть. (windows services пока можно не обновлять — они меняются реже. но в перспективе и их как-то надо бы...)
2. помогает, или по крайней мере не мешает делать сетап для on-premises варианта, где мы не контролируем окружение и наличие разного рода тулов.
Пока смотрю в сторону webdeploy.
Что ещё можно посмореть?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Что ещё можно посмореть?
Обычный TFS (2015) вполне вменяемый стал, есть Build / Deploy / Release Management, почти на все что обычно встречается.
Для энтерпрайза тоже вроде все есть — настраиваемые approvals (QA/RM), environments (типа DEV/TEST/PROD).
Здравствуйте, Sergey J. A., Вы писали:
bnk>>Для энтерпрайза тоже вроде все есть — настраиваемые approvals (QA/RM), environments (типа DEV/TEST/PROD).
SJA>У нас TeamCity, менять пока не собираемся..
Это билд, деплоя в TeamCity, насколько я знаю, нет. Есть воркараунды.
Для понимания, что есть поддержка деплоя:
https://www.visualstudio.com/team-services/release-management/
Здравствуйте, bnk, Вы писали:
SJA>>У нас TeamCity, менять пока не собираемся..
bnk>Это билд, деплоя в TeamCity, насколько я знаю, нет. Есть воркараунды.
Ну так я про билд и говорю. Что бы запустить деплой с TFS-а нужно наверное проект там собрать? Переносить всю требуху связанную со сборкой (а там куча всяких костылей) на TFS не хочется.
bnk>Для понимания, что есть поддержка деплоя:
bnk>https://www.visualstudio.com/team-services/release-management/
К сожалению пробежавшись глазами я ничего не понял
Есть какое-то качественное отличие от, скажем, ручного запуска webdeploy (которое можно организовать на TeamCity)?
Если там что-то большее, то я постараюсь найти время почитать это, но пока мне представляется, что это красивая/удобная обёртка для webdeploy.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Ну так я про билд и говорю. Что бы запустить деплой с TFS-а нужно наверное проект там собрать?
Не, не нужно. Системы деплоймента/управления релизами (включая TFS Release Management) начинают работать с того места, когда билд уже собран.
То есть, RM может брать готовый билд хоть из папки на сервере.
Сборка — это другая задача (хотя TFS в принципе собирать тоже умеет, и иметь все в одной системе удобно,
чтобы автоматически отслеживать какие тикеты-фиксы были куда задеплоены, или для геренации Release Notes например.
SJA>К сожалению пробежавшись глазами я ничего не понял Есть какое-то качественное отличие от, скажем, ручного запуска webdeploy (которое можно организовать на TeamCity)?
SJA>Если там что-то большее, то я постараюсь найти время почитать это, но пока мне представляется, что это красивая/удобная обёртка для webdeploy.
webdeploy — это метод один из методов деплоймента на IIS. Другой метод — заливка файлов по FTP например. Это же не система.
Что делает система деплоймента?
Началом работы, как я написал выше, является готовый билд (пусть будет в папке для простоты)
Ее задача — установить его в целевое окружение (то что называется "environment" на сайте выше), . Это может включать в себя
— правку конфигов приложения для целевого окружения
— установку нужных собранных компонент в целевую систему (например сайты можно ставить через тот же webdeploy)
— обновление баз например, если нужно, или запуск еще каких скриптов в целевом окружении.
— все это делается под соответствующими аккаунтами.
— логгирование — документирование всех установок и показ этих логов.
Например, пусть есть 3 окружения "dev" => "test" => "prod"
Разработчик выбирает билд который хочет задеплоить, нажимает кнопку "deploy".
Система деплоймента берет этот билд, прописывает в конфигах что нужно для DEV. У нас это например, connection strings для баз данных,
имена связанных серверов с которыми работает приложение, номера сертификатов, связанные сайты шарепоинта, куча всего.
Потом RM деплоит этот билд на DEV-сервера. Включая установку сайтов, перезапуск пулов, установку сервисов.
Вообще, действия набираются из "тасков" как для билда, только задачи тут специализированные для деплоймента.
Типа "задеплоить на заданный сервер", "задеплоить на такую-то машину в azure", "поменять конфиг", "установить софтину", перезапустить сервер X.
В общем, далее разработчк смотрит что все вроде работает, говорит QA что этот билд можно брать проверять.
QA нажимает "deploy to test" (разработчик эту кнопку нажать не может).
Происходит тот же процесс что и выше, но для test. После этого имеем новую версию рабочей системы в test.
QA тестирует, если все нормально, аппрувит для деплоймента в prod. Дальше QA lead нажимет на "deploy to prod".
Билд уходит в продакшен по той же системе.
Целевых окружений может быть сколько угодно, связи (что-следует-за-чем) тоже в принципе любые.
Для каждого из них можно задать аккаунты, которые нужно использовать для деплоя, ну и вообще общие для всех билдов настройки.
В результате из истории легко понять, кто, что, куда, и когда, и зачем задеплоил
