Интересная идея, хотя, кажется, что правильнее было бы управлять этим процессом в 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 до ума.
Вместо попыток меня уделать, попробуйте понять суть проблемы :)
Но раз уж дошло до срача, и вы просили критики в статье, вот вам критика:
1. во первых вы хреново прогуглилили github.com/js-cookie/js-cookie (с 2009 года)
На вскидку – 1 в 1 с вашим велосипедом. Они, кстати, подумали о возможном конфликте неймспейсов, лохи, модулями то не умеют пользоваться :)
2. Вот 302 репозитория на эту или похожую тему github.com/search?l=JavaScript&q=js+cookie&type=Repositories&utf8=%E2%9C%93
уже на второй странице некий jonlabelle использует такой же неймспейс github.com/jonlabelle/cookie-js
и кажется делает все то же самое, но наверняка есть нюансы.
Одному Богу известно сколько людей и как используют этот код, созданный еще в 2012 году. Может быть он встретится в очередном попсовом лайтбоксе, или в няшненьком jquery плагине, который, так получилось, написан без изысков, но уже сейчас очень нужно им использовать, чтобы не писать с нуля.
И когда кучи плагинов и библиотек начинают тянуть за собой всякие Cookie, Linq, Strings и Dates, то, иногда, (конечно не всегда) начинается жопа. Например, когда ваше громадное решение встраивается в страницу как API в чужое огромное решение.
То что вы не видите в этом проблемы не значит, что этой проблемы нет. Технический долг есть всегда и он даст о себе знать.
> Кто вообще две библиотеки для одного и того же подключает?
первый разработчик сделает крутую библиотеку А использовав tasty-cookies,
второй разработчик сделает крутую библиотеку Б использовав другую Cookie-библиотеку с таким же именем Cookie.
третий – захочет одновременно использовать А и Б и получит конфликт.
Классический пример – Array.prototype.select или forEach во времена, когда jquery был еще не в ходу, а подобие лямбда выражениям в JS уже хотелось. Кажется, каждый пилил свою реализацию, а уже в производных библиотеках происходили конфликты. Сам с этим сталкивался, это очень больно.
> А что вы предлагаете?
Лично я бы хранил эти функции внутри фреймворка без глобального объекта. А если бы очень хотелось глобальный объект, то, хотя бы, назвал бы его по другому, исключив банальные конфликты с именами кучи уже сделанных решений Cookie / Cookies.
Мы у себя для этого используем прокси-приложение, некое подобие лоадбалансера, которое в реалтайме определяет, на какую версию нужно направить клиента.
Кстати в тему деплоя.
Два года назад, когда мы страдали при деплое нашего 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 до ума.
Но раз уж дошло до срача, и вы просили критики в статье, вот вам критика:
1. во первых вы хреново прогуглилили github.com/js-cookie/js-cookie (с 2009 года)
На вскидку – 1 в 1 с вашим велосипедом. Они, кстати, подумали о возможном конфликте неймспейсов, лохи, модулями то не умеют пользоваться :)
2. Вот 302 репозитория на эту или похожую тему
github.com/search?l=JavaScript&q=js+cookie&type=Repositories&utf8=%E2%9C%93
уже на второй странице некий jonlabelle использует такой же неймспейс github.com/jonlabelle/cookie-js
и кажется делает все то же самое, но наверняка есть нюансы.
Одному Богу известно сколько людей и как используют этот код, созданный еще в 2012 году. Может быть он встретится в очередном попсовом лайтбоксе, или в няшненьком jquery плагине, который, так получилось, написан без изысков, но уже сейчас очень нужно им использовать, чтобы не писать с нуля.
И когда кучи плагинов и библиотек начинают тянуть за собой всякие Cookie, Linq, Strings и Dates, то, иногда, (конечно не всегда) начинается жопа. Например, когда ваше громадное решение встраивается в страницу как API в чужое огромное решение.
То что вы не видите в этом проблемы не значит, что этой проблемы нет. Технический долг есть всегда и он даст о себе знать.
Вопрос по 5 фреймворкам адресуйте их создателям.
Не просите критики, если не готовы к ней.
первый разработчик сделает крутую библиотеку А использовав tasty-cookies,
второй разработчик сделает крутую библиотеку Б использовав другую Cookie-библиотеку с таким же именем Cookie.
третий – захочет одновременно использовать А и Б и получит конфликт.
Классический пример – Array.prototype.select или forEach во времена, когда jquery был еще не в ходу, а подобие лямбда выражениям в JS уже хотелось. Кажется, каждый пилил свою реализацию, а уже в производных библиотеках происходили конфликты. Сам с этим сталкивался, это очень больно.
> А что вы предлагаете?
Лично я бы хранил эти функции внутри фреймворка без глобального объекта. А если бы очень хотелось глобальный объект, то, хотя бы, назвал бы его по другому, исключив банальные конфликты с именами кучи уже сделанных решений Cookie / Cookies.