деплоймент план что это
CRISP-DM/Deployment
Материал из MachineLearning.
Создание модели, как правило, не конец проекта. Даже если целью модели является получение знаний о данных, эти знания должны быть организованы и представлены таким образом, чтобы клиент смог использовать их. Это часто включает в себя применение «Живых» моделей, например персонализация веб-страниц в режиме реального времени или повторяющиеся расчеты маркетинговых данных. Тем не менее, в зависимости от требований, фаза развертывания может быть столь же простой, как генерация отчета, или же сложной, как реализация повторяющегося интеллектуального анализа данных в предприятии. Во многих случаях это является задачей заказчика, а не аналитика, однако, даже если аналитик не будет выполнять развертывание, для клиента важно понять заранее какие действия должны быть осуществлены в каком порядке, чтобы использовать полученные модели.
Содержание
Запланировать развертывание (Plan deployment)
Чтобы внедрить результаты анализа данных в бизнес, разрабатывается план развертывания на основании результатов оценки модели. Если была определена общая процедура создания подходящих моделей, она документируется для последующего применения.
План развертывания (Deployment plan)
Описать стратегию развертывания, включая необходимые шаги и способ их осуществления.
Запланировать поддержку и мониторинг развернутого решения (Plan monitoring and maintenance)
Мониторинг и поддержка являются очень важными составляющими проекта, когда результаты становятся неотъемлемой частью бизнеса и его окружающий среды. Внимательная подготовка стратегии поддержки помогает избежать долгих периодов неправильного использования результатов анализа данных. Чтобы наблюдать за эксплуатацией результатов проекта, нужен детальный план по процессу мониторинга. Этот план должен принимать во внимание всю специфику эксплуатации проекта.
План мониторинга и поддержки (Monitoring and maintenance plan)
Составление стратегии мониторинга и поддержки, включающее в себя все необходимые шаги и их выполнение.
Сделать финальный отчет (Produce final report)
В конце проекта, лидер вместе с командой составляют финальный отчет. В зависимости от плана эксплуатации, этот отчет может быть просто резюмированием проекта и связанных с ним достижений (если это уже не было документировано во время выполнения проекта), или это может быть окончательная полная презентация результатов анализа данных.
Финальный отчет (Final report)
Это окончательный письменный отчет о проведенном анализе данных. Он включает в себя все предыдущие результаты и подводит итоговые заключения.
Итоговая презентация (Final presentation)
Обычно это встреча по завершению проекта, где результаты в устной форме презентуют заказчику.
Ревью проекта (Review project)
Оцените то, что пошло правильно, а что пошло не так, то что было сделано хорошо, и что должно быть улучшено.
Документирование опыта (Experience documentation)
Что такое деплой в программировании
Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.
После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:
Простыми словами, деплой — это процедура переноса вашего сайта на сервер. Данная операция может быть очень затруднительной и напрямую зависит от применяемых инструментов. Когда программисты начинают реализовывать deploy, они выполняют следующие действия:
Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.
Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.
По большому счету, на сегодняшний день все работы, связанные с настройкой и обслуживанием серверов должны быть максимально автоматизированы и отточены.
Однако невзирая на множество различных вариантов деплоя проектов, существует одно неотъемлемое правило для каждого — запрещено делать откаты. Другими словами, если в процессе выполнения deploy вы допустили ошибку и все пошло не по плану, то следует «деплоить» по новой версию, которая была ранее.
Помимо этого, deploy можно подразделять на категории откатов и обновлений:
Так же следует отметить такой способ, как канареечный релиз (canary release). Применяя такую методологию переход на обновленную версию происходит поэтапно — первоначально для малого количества пользователей, а потом для всех остальных.
Выбираемый вариант деплоинга напрямую зависит от применяемого хоста, а также метода настройки сервера. Вот перечень основных хостингов:
По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.
Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.
Надеемся данный материал был для вас полезен. В случае, если вы не смогли найти ответа на ваш вопрос или в чем-то не до конца разобрались — пишите нам в комментарии, и мы обязательно ответим.
Что такое деплой?
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
Создание плана развертывания
Относится к:
Мышление «управление службами» означает, что устройства в организации попадают в континуум, а процесс обновления программного обеспечения постоянно планируется, развертывается, отслеживается и оптимизируется. И как только вы используете этот процесс для обновлений функций, обновления качества становятся легкой процедурой, которая проста и быстро выполняется, в конечном счете, увеличивая скорость.
При переходе на модель управления службами необходимы эффективные способы развертывание обновлений для представительных групп устройств. Мы обнаружили, что развертывание на основе кольца хорошо работает для нас в Microsoft и многих других организациях по всему миру. Кольца развертывания в Windows похожи на группы развертывания большинства организаций, построенные для предыдущих крупных обновлений. Это просто метод для раздельного размещения устройств в временной шкале развертывания.
На самом высоком уровне каждое «кольцо» включает группу пользователей или устройств, которые получают определенное обновление одновременно. Для каждого кольца ИТ-администраторы устанавливают критерии для управления временем отсрочки или принятием (завершением), которые должны быть выполнены перед развертыванием на следующее более широкое кольцо устройств или пользователей.
Общая структура кольца использует три группы развертывания:
Организации часто используют разные имена для своих «колец», например:
Сколько колец должно быть у меня?
Точное количество колец для развертывания не имеет определенных правил. Как упоминалось ранее, вы можете обеспечить нулевое время простоя для устройств, критически важных для миссии, поставив их в собственное кольцо. Если у вас большая организация, можно назначить устройства кольцам в зависимости от географического расположения или размера колец, чтобы ресурсы helpdesk были более доступными. Рассмотрите потребности вашего бизнеса и введите кольца, которые могут быть нужны вашей организации.
Продвижение между кольцами
Существует в основном две стратегии переноса развертывания из одного кольца в другой. Один из них основан на обслуживании, другой — на основе проекта.
Если речь идет о развертывании, то ручные действия в процессе обычно препятствуют скорости обновления. Стратегия «красная кнопка» лучше, если это ваша цель.
Кольцо предварительного просмотра
Цель кольца Предварительного просмотра — оценить новые функции обновления. Это не для широких частей организации, но ограничивается людьми, которые несут ответственность за знание того, что будет дальше, как правило, ИТ-администраторы. В конечном счете, на этом этапе происходит работа по проектированию и планированию, чтобы при отправке общедоступных обновлений вы могли иметь больше уверенности в обновлении.
Участие в программе Windows insider предоставляет вам ранний доступ к выпускам Windows, чтобы вы могли использовать сборки предварительного просмотра в кольце предварительного просмотра для проверки приложений и инфраструктуры, готовя вас к общедоступным Windows выпускам.
Кто в кольцо Preview?
Пользователи кольца Preview — это самые опытные и устойчивые люди, которые не потеряют производительность, если что-то пойдет не так. В общем, эти пользователи являются ИТ-профессионалами и, возможно, несколькими людьми в бизнес-организации.
На этапах планирования и подготовки следует сосредоточиться на следующих действиях:
Помните, что вы работаете с программным обеспечением предварительного выпуска в кольце Предварительного просмотра и будете оценивать функции и тестировать обновление для целевого выпуска.
Если вы используете Windows (предварительный выпуск) для предварительного выпуска и используете WSUS или Windows Update для бизнеса, обязательно задайте следующие политики для создания предварительного просмотра:
Ограниченное кольцо
Цель ограниченного кольца — проверка обновления на представительных устройствах по всей сети. В этот период создаются данные и отзывы, позволяющие принимать решение о более широком развертывании. Desktop Analytics поможет определить хорошее ограниченное кольцо представительных устройств и помочь в мониторинге развертывания.
Кто в ограниченном кольце?
Наиболее важной частью этого этапа является поиск представительного примера устройств и приложений по всей сети. По возможности необходимо представлять все аппаратные средства и все приложения, и важно, чтобы выбранные для этого кольца люди регулярно использовали свои устройства для создания данных, необходимых для принятия решения о более широком развертывании в организации. ИТ-отдел, лабораторные устройства и пользователи с самым передовым оборудованием обычно не имеют приложений или драйверов устройств, которые действительно являются представительным образцом вашей сети.
Во время пилотных этапов и проверки необходимо сосредоточиться на следующих действиях:
При развертывании на ограниченном кольце вы сможете собирать данные и реагировать на инциденты, происходящие в среде, быстро реагируете на все возникающие проблемы. Убедитесь, что вы отслеживали достаточное принятие в этом кольце, так как ваше ограниченное кольцо представляет организацию по всей доске, и при достижении достаточного принятия вы можете быть уверены в том, что более широкое развертывание будет работать более гладко.
Широкое развертывание
После того как устройства в ограниченном кольце имеют достаточный период стабилизации, пришло время для широкого развертывания по всей сети.
Кто в кольцо развертывания Broad?
В большинстве предприятий кольцо Broad включает остальную часть организации. Из-за работы на предыдущем кольце для проверки устойчивости и минимизации нарушений (с диагностическими данными для поддержки вашего решения) широкое развертывание может происходить относительно быстро.
В некоторых случаях можно удерживать критически важные устройства (например, медицинские) до завершения развертывания в широком кольце. Получите рекомендации и рекомендации по развертыванию обновлений Windows клиентских функций на критически важных устройствах миссии.
На этапе широкого развертывания следует сосредоточиться на следующих действиях:
Планирование развертывания ring
Ранее мы предоставляли методы анализа развертывания, но это были автономные средства для оценки, управления и выполнения развертывания. Другими словами, необходимо создать анализ, разработать стратегию развертывания, а затем перейти к консоли для реализации, повторив эти действия для каждого развертывания. Многие из этих задач и многое другое мы объединили в единый интерфейс с Desktop Analytics.
Desktop Analytics — это облачная служба и ключевой инструмент в Microsoft Endpoint Manager. С помощью искусственного интеллекта и машинного обучения Desktop Analytics является мощным средством, который позволяет получить сведения и аналитические сведения для принятия обоснованных решений о готовности Windows устройств.
Как правильно организовать деплой приложения?
Вчера я понял, что веду свои _дела_ каким-то абсолютно варварским способом. Использование git и bitbucket уже никого не удивляет.
Из-за продолжительной работы конвейера, который выпускает велосипеды по моей разметке появилась необходимость облегчить некоторые этапы работы.
Прямо сейчас имеется мой пк на котором разрабатывается _очередной_ сайт и два компьютера, которые можно назвать серверами. Да черт с ним, два невероятно полноценных сервера — development и production сервера. ( а какой размах? )
Я честно воспользовался гуглом, в стране в которой отсутствует реестр незаконных сайтов, и понял, что мою маленькую проблему решает:
Но вот моя компетентность оставляет желать лучшего — я решил освоить тестирование. Каюсь, до селе пусть и знал, но не воспринимал тестирование любого вида, как должное. Пора становиться намного лучше!
С самими тестами я как-то разберусь, но где их _правильно_ было бы запускать? У меня? Уже на стороне девелопмент сервера?
И предположим, что велосипед моего производства вышел на свет в виде готового сайта на дев-сервере. По-старинке, по фтп на продакшн?
Есть ли возможность у гита вытягивать с удаленного репозитория только обновления файлов, которые сейчас существуют?
Т.е. есть желание сделать такие операции в результате которых с дев-сервера можно сливать на все файлики сайта, а только их часть.
Прошу обратить внимание, что мои вопросы могут быть заданы совсем неверно или не очень верно. Не сердитесь. 🙁
Я увидел в Вашем вопросе две части.
Как правильно организовать деплой (выкладку работоспособного кода на сервер)?
В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.
Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.
Как организовать процесс тестирования?
Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.
Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.
В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.
Таким образом
Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.
Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.
Не лучше ли использовать технологии вроде bash scripting для деплоя вместо всех этих капистранов? Преимущества:
1) bash-скрипт простой и короткий. Его легко и быстро написать. Во всяких капистранах надо сначала полдня изучать инструмент, потом думать, каким костылем можно заставить его делать то, что нужно.
2) bash-скрипт легко проверить на отсутсвие ошибок и не надо полдня отлаживать
3) bash-скрипт делает ровно то, что в нем написано. Что сделает сложная система, написанная другим человеком неизвестной квалификации — никому неизвестно
4) Простое решение лучше сложного
У автора вопроса, как я понимаю, речь идет о несложном приложении, а не мегасистеме с десятками серверов и сервисов и использовать сложные системы вроде CI, юниттестов это излишнее усложнение жизни.
Плюс, как видно из описания Mina, это чрезвычайно тяжелый и сложный инструмент: вы добавили пару строчек в файл, логично закачать измененный сервер на файл за полсекунды и успокоиться, но она будет делать репозитории, выкачивать что-то, собирать, загружать… боюсь, это не способствует быстрой разработке.
Опять же, вы советуете использовать юнит-тесты. А я советую использовать функицональные тесты. Почему? потому, что функциональные тесты проверяют, правильно ли работает приложение. Если все правильно — его можно выливать на продакшен. А прохождение юнит тестов не гарантирует правильной работы приложения. А время на них расходуется. Вопрос, зачем они тогда нужны.
В общем, советую автору вопроса сделать самую-самую простую систему деплоя на основе bash скрипта/нескольких скриптов и FTP/SFTP и не мучаться.
Инструменты для разработки? PHP, MySQL, свои велосипеды (никакого yii).
Методика тестирование? TDD. 🙂
Очень здорово! С этими вопросами покончено! Спасибо.
Значит на продакшн проще по-старинке, да?
И всё-таки может ли гит выкачать определенные папки из конкретной ветки с указанного удаленного репозитория?
Egorinsk — Mina, если Вы этого не заметили, сама по себе генерирует баш скрипт и транслируется из Ruby напрямую в bash. Это очень легкий инструмент и отдельного внимания заслуживает DSL с помощью которого и генерируется конечный баш-скрипт. По поводу «сложной системы», «другого человека» и «неизвестной квалификации» — предлагаю периодически думать.
По поводу тестов — я привел пример того, как запускать тесты. Автор просил именно этого совета. И конечно юнит-тесты не панацея.
Автор, уточните пожалуйста, с какой целью Вы хотите выдергивать отдельные папки из гита? Сразу скажу, что это невозможно 🙂
shebanoff, на самом деле мои велосипеды разных моделей выходят с достаточно постоянной частотой.
Иногда в эти разработки прокрадываются баги и нужно на разных сайтах вносить одни и те же изменения в файлы _ядра_ велосипеда.
К сожалению, чтобы исправлять один продукт конвейера я придумал другой — параллельная линия выпуска. Сделать так, чтобы при коммите в ветку мастер изменения файлов ядра вносились на разных сайтах-донорах-клиентах.
Без абстракции всё выглядит примерно так: есть мой микро-фреймворк который реализует базовый функционал простого сайта — я его назвал ядром. И всякие модули к нему, например галерея с множественной загрузкой картинок. На одном сайте такой модуль нужен — на другом нет. Но ядро везде одно и тоже.
Вопрос стоит таким образом: как производить обновления основных компонентов сайта (ядра) и при этом не лазить на каждый сайт по фтп?
Разрабатываю один, но поддерживать приходится несколько сайтов моего производства. Критические вещи нужно фиксить. Подумал, что такое ухищрение с гитом решит мою проблему.
Есть решение? Можно вызвать более опытных товарищей на скайпообщение?