Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Shmj, Вы писали:
S>>Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты.
НС>Нет никакого такого стандартного способа.
S>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые.
НС>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Здравствуйте, Shmj, Вы писали:
S>Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты.
Нет никакого такого стандартного способа.
S>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые.
Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки).
Это как? Ты раньше на проде патчил только одну сборку из проекта? Ну ты герой.
S> Даже более — можно было создать плагинную систему
Зачем плагинная система на сервере? Чтобы тормозов побольше?
S>Теперь подобного можно достичь с помощью т.н. микросервисов, что не подходит для мелких случаев — для каждого плагина делать отдельный микросервис — это бред.
Микросервисы это не плагины, и цель у них совершенно иная.
S>Ну и вопрос такой. Как лучше совместить плагинную систему и современные тренды, когда принято все собирать из исходников с нуля, обычно собирают целый проект а не по частям? Или же лучше не делать плагинов а просто пересобирать все с нуля как все?
Делать без плагинов, по крайней мере пока ты не сможешь ответить на вопрос какие бенефиты тебе дают твои плагины.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. НС>>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Мне надо было наколеночный проект закачать на машину в aws
Если вы прям ненавидите амазоновскую проприетарщину, есть прекраснейший Terraform, который умеет всё то же, что и CloudFormation (но только _немного иначе_). Умеет ещё кучу других провайдеров, и совсем "общие" вещи вроде подключиться через SSH куда-то и что-то там выполнить. Можно одним слоем развернуть инстанс EC2, а вторым навалить на него какой вам софт нужен.
Не надо прикрываться этой "наколеночностью" — сейчас много хороших инструментов с отличной документацией, которые позволяют сразу сделать хорошо.
Здравствуйте, Sharov, Вы писали:
S>Я полностью согласен с тем, что задача любого программиста автоматизировать вся и все. Но вот как быть с таким S>важнейшим компонентом как время? Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза S>от силы скажем не менее часа, а то и более 2-х. При этом по RDP скопировать, проверить и запустить дело от силы S>5 минут. Автоматизация нужна для выигрыша времени в основном. Тут никакого выигрыша нет, разве что опыт, да S>и выложить скрипт на гитхаб всяким hr показывать. Не более.
Вот именно из-за такой точки зрения эти подходы для многих остаются "абстрактными идеалами". Если зафиксировать все параметры и сравнивать только время, вы правы — с большой вероятностью автоматизация будет выглядеть невыгодно. Но сравнивать нужно не только время, но ещё:
* предсказуемость — "оно делает именно вот это"
* воспроизводимость — "оно делает так всегда"
* задокументированность — "вот есть скрипт и его можно прочитать, чтобы понять что происходит"
* возможность захотеть большего — деплоить более 1 энвайронмента, деплоить чаще чем вы привыкли, и т.д.
У ручного подхода есть проблемы с предсказуемостью и воспроизводимостью — мыслящий человек после N повторений начинает оптимизировать процесс, начинает придумывать, что вот вот этот шаг не обязателен, в этот раз вот это обновлять не буду, т.к. точно знаю, что в билде оно не менялось. И в какой-то момент 5-минутный ручной деплоймент превращается в 20-минутное ковыряние "чё за фигня, почему так?"
Задокументированность — другая головная боль. Понятно, что если вы вводите процесс ("процесс ручного деплоймента"), его надо хотя бы минимально описать. Если это будет написано человеческим языком, можно очень легко забыть что-то упомянуть, или забыть что-то поправить, когда по факту процесс немного изменился. Легко получить документ, который не соответствует реальности.
Возможность захотеть большего — деплоймент скрипт можно развивать (и это будет "нормально"). Ручной деплоймент развивать некуда — с каждым усложнением он будет становиться всё менее предсказуемым и воспроизводимым.
Попробуйте на деплойменты смотреть так же как на юнит/инт тесты: "в принципе можно тестировать руками — и это позволит сэкономить время на написании тестов"
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, rosencrantz, Вы писали:
R>>Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows,
S>И что же там самое близкое? Не cmd ли?
Ага, через телнет.
S>Вы лично как делали во времена IIS?
Ну например TeamCity + MS Build + WebDeploy в 2012 году. А что?
R>>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
S>Ansible появился совсем недавно а Puppet работает только через cygwin.
Ansible появился 9 лет назад, и слово "подходы" у меня там именно для того, чтобы говорить не об инструментах, а об идеях.
S>Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
Из мира .NET я довольно быстро сбежал как раз из-за чудовищной экосистемы заточенной на "кликанье мышкой через RDP". Но в нескольких .NET проектах всё-таки довелось сделать CI/CD, поэтому у меня есть (возможно немного устаревшее) представление о том, что там может или не может работать. В этот тред я пришёл потому что CI/CD занимаюсь уже лет 10, последние 5 лет это где-то половина моей работы, я думаю не будет преувеличением сказать, что у меня есть опыт, и я вобщем не вижу почему бы моя точка зрения не была интересна/полезна для коллег. Ты пришёл мне сделать какое-то замечание?
S>А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
С моей точки зрения ситуация принципиально не поменялась — как 10 лет назад кто-то верил в ценность автоматизации, кто-то предпочитал руками, так и сейчас. Разве что раньше это часто было "запросить у админов виртуалку, потратить полдня на установку тимсити, и т.д.", а сейчас за 10 минут билд пайплан делается в облаках.
S>Раньше проще всего было через RDP или FTP — разница не большая. Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Между RDP и FTP разница таки большая. Аплоад по FTP автоматизируется тривиально, а автоматизировать RDP — это реально лучше сразу к врачу.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Легаси, .net 4.* какой-нибудь. НС>>И? Контейнеры с ним есть.
S>А если нету win10, рабочая win7 и win2008 продуктовая? А как до докера люди делали?
Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows, пишется скрипт, который заливает новый билд и дёргает что там у IIS надо дёрнуть, чтобы он понял что произошло. Даже такая наколенка в сто раз лучше, чем руками через RDP. Более хороший вариант — примерно то же самое, только не на коленке, а хоть через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
Сейчас стараются максимально разграничить "неизменную часть" (типа низкоуровневая инфраструктура вроде сервера, на котором есть чистая минимальная ОС и демон докера) и изменяемую часть (контейнеры, которые в том самом докере крутятся). Вот эту изменяемую часть не обновляют — её на каждый деплоймент убивают и создают новую с нуля.
Даже если не Packer, точно так же делаем EC2 с голой виндой, натравливаем на него Ansible/Puppet, получаем свежий сервер со свежим билдом, старый грохаем.
Здравствуйте, Shmj, Вы писали:
S>Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки). Даже более — можно было создать плагинную систему и копировать плагины просто в директорию, добавляя таким образом новый функционал, не вмешиваясь в старый, не производя компиляцию даже.
Можно но не нужно. Куда проще сделать скрипт, который все удалил и накатил новое.
И пересобрать все — какая проблема? Не вручную же ты символы пишешь, компьютер автоматом все пересоберет и не устанет. Ну, если сборка проекта целиком занимает двое суток, могу понять, но в дотнете как-то обычно сборка совсем не такая длинная...
Здравствуйте, Sharov, Вы писали:
S>Ну это уход от вопроса. Т.е. таки rdp и копировать ручками.
Ну вам же ответили ранее https://rsdn.org/forum/dotnet/8087679.1
Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity.
Как минимум Octopus, Ansible и DSC для связки .Net 4 и Server 2008R2+ работать должны.
К перечисленным решениям можно добавить еще:
— Microsoft System Center (который Operation Manager и иже с ним)
— TFS (release management там с версии 2015 вроде) / Azure DevOps / Azure Pipelines
В принципе, народ работал и на базе GPO в Active Directory, но это, скорее из серии "когда уж совсем никак, то пусть будет хоть это".
RDP + ручная установка вполне прокатывают как разовое средство, но как только речь заходит о более-менее регулярных деплоях (или деплоях на более чем один Instance, а я так думаю, в большинстве случаев деплой одного релиза идет минимум 3 раза: на тестовом окружении, на Stage и на Prod и это еще без учета того, что на скорее всего у вас кластер машин на Prod), имхо, от них нужно уходить и как можно быстрее, иначе риск операторской ошибки становится слишком большим!
Здравствуйте, Sharov, Вы писали:
S>>> А как до докера люди делали? НС>>А еще раньше люди огонь при помощи кремня добывали. S>Ну это уход от вопроса. Т.е. таки rdp и копировать ручками.
Я тебе там целую пачку вариантов помимо контейнеров привел, но ты их все проигнорировал. Ну ОК, продолжайте с RDP развлекаться.
Здравствуйте, Shmj, Вы писали:
R>>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности. S>Ansible появился совсем недавно
9 лет назад это недавно?
S>а Puppet работает только через cygwin.
Есть еще дакая древность как Шеф. Было бы желание.
S>Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
Сразу видно что это ты никогда этим не занимался, вот и колхозишь бог пойми что на коленочке.
S>А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
CI/CD это принцип, а не конкретный софт. О чем ты сейчас?
А конкретный софт это тот же Октопус или ТимСити, которые тоже уже больше 10 лет доступны. А до этого был, в конце концов, svn и серверные хуки.
S>Раньше проще всего было через RDP или FTP — разница не большая.
Просто нет.
S>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить.
Здравствуйте, Shmj, Вы писали:
S>>>Раньше было на одну. НС>>Никогда не было. S>Для средних сайтов хватало одного мощного сервака для IIS.
High availability? Не, не слышал.
S>>>Там уже папка открыта — просто заходишь, удаляешь, вставляешь. НС>>Это все одним нажатием кнопки, причем сразу на все инстансы, да?
S>1 инстанс.
Все равно рукопашное копирование одним нажатием в RDP у тебя никак не получится. Надо собрать локально, открыть сессию RDP, подключится к диску, найти нужный каталог, создать файлик app_offline, запустить копирование, ответить на промт о перезаписи. И так для каждого инстанса. Ошибиться — миллион возможностей. И весь этот рукопашный перфоманс — просто чтобы не напрягать моск, один раз разобравшись с какой нибудь механикой деплоймента.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>High availability? Не, не слышал.
Раньше этим мало кто страдал. Если база была на отдельном серваке и делались регулярные бекапы раз в день — уже неплохо.
S>>1 инстанс.
НС>Все равно рукопашное копирование одним нажатием в RDP у тебя никак не получится. Надо собрать локально, открыть сессию RDP, подключится к диску, найти нужный каталог, создать файлик app_offline, запустить копирование, ответить на промт о перезаписи. И так для каждого инстанса. Ошибиться — миллион возможностей. И весь этот рукопашный перфоманс — просто чтобы не напрягать моск, один раз разобравшись с какой нибудь механикой деплоймента.
Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
Здравствуйте, Shmj, Вы писали:
НС>>High availability? Не, не слышал. S>Раньше этим мало кто страдал.
Или просто ты был не в курсе.
S>Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
Здравствуйте, Sharov, Вы писали:
S>Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза
У тебя сервис 5-6 раз деплоится, а потом ты его выкидываешь на свалку?
S>Автоматизация нужна для выигрыша времени в основном.
Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
Здравствуйте, Sharov, Вы писали:
S>>>Автоматизация нужна для выигрыша времени в основном. НС>>Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
S>Сложно сломать сервис, который по сути один exe файл со справочной бд в виде файла sqlite. S>Надо понимать, что программы\сервисы разные бывают, а не только high scalability веб сервисы.
Согласен "про разные бывают", но осуждаю эту уверенность про то, что "X никогда не случится" сервис всегда будет таким, я всегда буду единственным программистом в этом проекте, на другую инфраструктуру мы переезжать не будем, и т.д. И потом бац, бизнес такой: "а давайте в облака чтоли переедем", "т.е. как 3 месяца займёт? щас наймём тебе в помощь второго программиста"
Речь о серверных приложениях. Т.к. сейчас все делают через JS-фреймворки React/Vue/Angular, а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты. Чуть глубже. Сейчас многие предпочитают виртуализацию, т.е. все через Docker/Kubernetes и при каждом новом деплое — обычно создается новая вирт. среда (а старая удаляется, дабы не думать о совместимости).
Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. Или же проделывали то же самое через sftp/ftps.
Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки). Даже более — можно было создать плагинную систему и копировать плагины просто в директорию, добавляя таким образом новый функционал, не вмешиваясь в старый, не производя компиляцию даже.
Теперь подобного можно достичь с помощью т.н. микросервисов, что не подходит для мелких случаев — для каждого плагина делать отдельный микросервис — это бред.
Ну и вопрос такой. Как лучше совместить плагинную систему и современные тренды, когда принято все собирать из исходников с нуля, обычно собирают целый проект а не по частям? Или же лучше не делать плагинов а просто пересобирать все с нуля как все?
Здравствуйте, Shmj, Вы писали:
S>Ну и вопрос такой.
Использую следующую схему.
1. приложение монолитное(т.е. без плагинов).
2. паблиш запускает скрипт который зипует сборку app_1.0.1.42.zip без лишних артефактов.
3. либо через простейшую реализацию submit либо ручками копирую в спец папку на сервак.
4. дальше опять либо ручками, либо через filewatcher запускается процесс обновления.
в скрипт можно встроить бэкап приложения, базы. вообщем резвимся как хотим.
в IIS есть еще фишка под названием app_offline.htm(из webdeploy).
если такой файл кинуть в корень приложения, то оно останавливается(вместо него содержимое странички пользователям)
и можно спокойно обновить приложение.
по поводу вебдеплоя долго настраивали с товарищем, но в ответственный момент происходил сбой, причину которого я так и не отловил.
лечилось с трудом, шаманство и повторная настройка. подозреваю из-за отсутствия валидного сертификата на сервере. может еще что-то.
поэтому отказался.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. НС>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Мне надо было наколеночный проект закачать на машину в aws, что подцепить к RMQ для обработки задача.
Как webdeploy тут мог помочь, он же вроде только для веба (ISS,asp.net)? Я просто тот, кто копировал
файлы (папочку с ) на прод. Сейчас (net5) проще -- single_exe (а-ля го) + докер. Хотя и без докера
один exe совсем симпатично. А webdeploy для не веб приложения как?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Мне надо было наколеночный проект закачать на машину в aws НС>У AWS свой инструментарий.
У нас своя инф-ра, в частности RMQ, так что aws тут не поможет.
S>>один exe совсем симпатично. А webdeploy для не веб приложения как? НС>А где я обещал webdeploy не для веб-приложения?
Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Наколеночные приложения не только веб. Это может быть обработчик, который живет на отдельной машине.
Здравствуйте, Sharov, Вы писали:
S>>>Мне надо было наколеночный проект закачать на машину в aws НС>>У AWS свой инструментарий. S>У нас своя инф-ра, в частности RMQ, так что aws тут не поможет.
Не очень понял при чем тут своя инфраструктура. Если речь про деплоймент самого кролика или прочей инфраструктуры, то он деплоится контейнерами или образами VM, таки через штатные средства AWS. Если же речь про деплоймент своего кода, как в стартовом сообщении, то при чем тут вообще кролик?
S>>>один exe совсем симпатично. А webdeploy для не веб приложения как? НС>>А где я обещал webdeploy не для веб-приложения? S>
S>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Наколеночные приложения не только веб.
Ты стартовое сообщение читал?
а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
Не нужно выдирать мои слова из контекста и приписывать то, что я не утверждал.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>У нас своя инф-ра, в частности RMQ, так что aws тут не поможет. НС>Не очень понял при чем тут своя инфраструктура. Если речь про деплоймент самого кролика или прочей инфраструктуры, то он деплоится контейнерами или образами VM, таки через штатные средства AWS. Если же речь про деплоймент своего кода, как в стартовом сообщении, то при чем тут вообще кролик?
Нету докера и вм, есть машина на которой надо запустить exe файл (или сервис).
S>>Наколеночные приложения не только веб. НС>Ты стартовое сообщение читал? НС>
НС>а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
НС>Не нужно выдирать мои слова из контекста и приписывать то, что я не утверждал.
Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp
я не знаю.
Здравствуйте, Sharov, Вы писали:
S>Нету докера и вм
В AWS? Так не бывает.
S>Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp S>я не знаю.
Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity.
Но в 2021 году не использовать контейнеры, а вместо этого ручками копировать через RDP файлики — очень странное решение.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp S>>я не знаю. НС>Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity. НС>Но в 2021 году не использовать контейнеры, а вместо этого ручками копировать через RDP файлики — очень странное решение.
Здравствуйте, Sharov, Вы писали:
S>>>Легаси, .net 4.* какой-нибудь. НС>>И? Контейнеры с ним есть. S>А если нету win10, рабочая win7 и win2008 продуктовая?
Поставить.
S> А как до докера люди делали?
А еще раньше люди огонь при помощи кремня добывали.
Здравствуйте, Михаил Романов, Вы писали:
МР>RDP + ручная установка вполне прокатывают как разовое средство, но как только речь заходит о более-менее регулярных деплоях (или деплоях на более чем один Instance, а я так думаю, в большинстве случаев деплой одного релиза идет минимум 3 раза: на тестовом окружении, на Stage и на Prod и это еще без учета того, что на скорее всего у вас кластер машин на Prod), имхо, от них нужно уходить и как можно быстрее, иначе риск операторской ошибки становится слишком большим!
Благодарю, я это все понял и, отчасти, знал. Просто было категорическое заявление, что RDP+ручное копирование
используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе.
Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде).
Здравствуйте, Sharov, Вы писали:
S>Просто было категорическое заявление, что RDP+ручное копирование S>используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе. S>Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде).
А я вот плюсану категоричность, потому что нет каких-то объективных причин выделять "редко деплою" и "деплою всего на 1 машину" в отдельную категорию. Обычно если умеешь, то пофигу редко там или не редко — заскриптованный деплоймент становится таким необсуждаемым минимумом, как руки мыть после туалета. Если не умеешь, да, причины не делать нормально всегда найдутся.
Здравствуйте, rosencrantz, Вы писали:
R>Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows,
И что же там самое близкое? Не cmd ли? Вы лично как делали во времена IIS?
R>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
Ansible появился совсем недавно а Puppet работает только через cygwin.
Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
Раньше проще всего было через RDP или FTP — разница не большая. Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>9 лет назад это недавно?
Да. Я начинал в 2004.
S>>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
НС>Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить.
Раньше было на одну. Там уже папка открыта — просто заходишь, удаляешь, вставляешь.
Здравствуйте, Shmj, Вы писали:
НС>>9 лет назад это недавно? S>Да. Я начинал в 2004.
А я в 94. И 9 лет это давно по меркам подобных тулов.
S>>>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро. НС>>Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить. S>Раньше было на одну.
Никогда не было.
S>Там уже папка открыта — просто заходишь, удаляешь, вставляешь.
Это все одним нажатием кнопки, причем сразу на все инстансы, да?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Раньше было на одну. НС>Никогда не было.
Для средних сайтов хватало одного мощного сервака для IIS.
S>>Там уже папка открыта — просто заходишь, удаляешь, вставляешь. НС>Это все одним нажатием кнопки, причем сразу на все инстансы, да?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
НС>Ну чо, продолжай в том же духе.
S>>Просто было категорическое заявление, что RDP+ручное копирование S>>используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе. S>>Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде). R>А я вот плюсану категоричность, потому что нет каких-то объективных причин выделять "редко деплою" и "деплою всего на 1 машину" в отдельную категорию. Обычно если умеешь, то пофигу редко там или не редко — заскриптованный деплоймент становится таким необсуждаемым минимумом, как руки мыть после туалета. Если не умеешь, да, причины не делать нормально всегда найдутся.
Я полностью согласен с тем, что задача любого программиста автоматизировать вся и все. Но вот как быть с таким
важнейшим компонентом как время? Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза
от силы скажем не менее часа, а то и более 2-х. При этом по RDP скопировать, проверить и запустить дело от силы
5 минут. Автоматизация нужна для выигрыша времени в основном. Тут никакого выигрыша нет, разве что опыт, да
и выложить скрипт на гитхаб всяким hr показывать. Не более.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза НС>У тебя сервис 5-6 раз деплоится, а потом ты его выкидываешь на свалку?
Это исправление ошибок и новая версия. Все остальное время он просто работает.
S>>Автоматизация нужна для выигрыша времени в основном. НС>Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
Сложно сломать сервис, который по сути один exe файл со справочной бд в виде файла sqlite.
Надо понимать, что программы\сервисы разные бывают, а не только high scalability веб сервисы.
