DevOps

Разработка программного обеспечения
  • Процесс разработки ПО
Ключевые процессы
  • Анализ
  • Проектирование
  • Программирование
  • Конструирование
  • Тестирование
  • Отладка
  • Развёртывание
  • Сопровождение
  • Документирование
Парадигмы и модели
  • Agile
  • Cleanroom
  • Итеративная
  • Спиральная
  • Каскадная
  • V-Model
  • Dual Vee Model
Методологии
  • ASD
  • DevOps
  • DAD
  • DSDM
  • FDD
  • Канбан
  • Lean SD
  • LeSS
  • MDD
  • MSF
  • PSP
  • OpenUP
  • RAD
  • RUP
  • SAFe
  • Scrum
  • TSP
  • UP
  • XP
Инструменты
  • Компилятор
  • Отладчик
  • Профилирование
  • GUI-конструктор
  • ИСР
  • Автоматизация сборки
  • Автоматизация релиза
  • Инструменты тестирования

Схема взаимодействия в методологии Devops. Разработка + Тестирование + Эксплуатация = DevOps Иллюстрация, показывающая вариант DevOps как пересечения разработки, эксплуатации и тестирования

DevOps (акроним от англ. development и operations; по-русски обычно произносится как «дево́пс») — методология активного взаимодействия специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимная интеграция их рабочих процессов друг в друга для обеспечения качества продукта. Предназначена для эффективной организации создания и обновления программных продуктов и услуг. Основана на идее тесной взаимозависимости создания продукта и эксплуатации программного обеспечения, которая прививается команде как культура создания продукта.

Содержание

  • 1 Общее обозначение
  • 2 Набор инструментов
  • 3 Сравнение с Agile и Continuous delivery
  • 4 Цели
  • 5 Преимущества DevOps
  • 6 DevOps и архитектура
  • 7 Примечания

Общее обозначение

Организациям, которым необходимы частые выпуски программного обеспечения, может понадобиться DevOps. Дневной цикл релизов может быть гораздо более интенсивным у организаций, которые выпускают несколько разнонаправленных приложений.

Методология фокусируется на стандартизации окружений разработки с целью быстрого переноса программного обеспечения через стадии, способствуя быстрому выпуску версий. В идеале, системы автоматизации сборки и выпуска должны быть доступны всем разработчикам в любом окружении, и у разработчиков должен быть контроль над окружением, а информационно-технологическая инфраструктура должна становиться более сфокусированной на приложении.

Задача DevOps-инженеров — сделать процесс разработки и поставки программного обеспечения согласованным с эксплуатацией объединив их в единую команду, что позволяет организовать процессы, которые далее можно автоматизировать с помощью инструментов.

DevOps-движение возникло в 2009 году и было призвано решить проблемы взаимодействия команд разработки и эксплуатации программных продуктов, в том же году в Бельгии была организована серия конференций «DevOps Days»[1][2]. Затем «DevOps-дни» проходили в различных городах и странах мира.

Набор инструментов

Поскольку DevOps — это командная работа (между сотрудниками, занимающимися разработкой, операциями и тестированием), нет единого инструмента «DevOps»: это скорее набор (или «инструментальная цепочка DevOps»), состоящий из нескольких инструментов. Как правило, инструменты DevOps вписываются в одну или несколько из этих категорий, что отражает ключевые аспекты разработки и доставки программного обеспечения:[3]

  1. Кодирование — разработка и анализ кода, инструменты контроля версий, слияние кода;
  2. Сборка — инструменты непрерывной интеграции, статус сборки;
  3. Тестирование — инструменты непрерывного тестирования, обеспечивающие быструю и своевременную оценку бизнес-рисков;
  4. Упаковка — репозиторий артефактов, предварительная установка приложения;
  5. Релиз — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
  6. Настройка — конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
  7. Мониторинг — измерение производительности приложений, взаимодействие с конечным пользователем;
  8. Непрерывная поставка;
  9. Непрерывная интеграция.

Несмотря на то, что доступно множество инструментов, некоторые категории из них имеют особо важное значение в настройке инструментальных средств DevOps для использования в организации. Некоторые попытки идентифицировать эти основные инструменты можно найти в существующей литературе[4].

Такие инструменты, как управление контейнеризацией (Docker, Kubernetes), непрерывной интеграцией (Jenkins, GitLab), развёртывания сред по шаблону (Puppet, Ansible, Terraform) и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps[5].

Сравнение с Agile и Continuous delivery

Agile и DevOps похожи, но Agile представляет собой изменение мышления и практики (что должно привести к организационным изменениям), а DevOps уделяет больше внимания внедрению организационных изменений для достижения своих целей.[6]

Потребность в DevOps рождалась из-за растущей популярности программного обеспечения Agile, поскольку это приводит к увеличению количества выпускаемых версий.

Continuous delivery и DevOps похожи по своим значениям (и часто сочетаются), но они представляют собой две разные концепции:

DevOps применяется в более широких аспектах и сосредоточен вокруг:

  1. Организационных изменений: в частности, для поддержки более тесного сотрудничества между различными типами работников, занимающихся поставкой программного обеспечения;
  2. Разработчиков;
  3. Операций;
  4. Гарантии качества;
  5. Управления;
  6. Системного администрирования;
  7. Администрирования базы данных;
  8. Координаторов
  9. Автоматизации процессов в поставке программного обеспечения.[7]

Continuous delivery — это подход к автоматизации аспекта поставки, который фокусируется на:

  1. Объединении различных процессов;
  2. Выполнении их быстрее и чаще.

Они имеют общие конечные цели и часто используются вместе для их достижения. DevOps и Continuous delivery используют гибкие методы: небольшие и быстрые изменения с целенаправленным результатом для конечного клиента.

Цели

Конкретные цели DevOps охватывают весь процесс поставки программного обеспечения. Они включают:

  1. Сокращение времени для выхода на рынок;
  2. Снижение частоты отказов новых релизов;
  3. Сокращение времени выполнения исправлений;
  4. Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы).

Методики DevOps делают простые процессы более программируемыми и динамическими. С помощью DevOps можно максимизировать предсказуемость, эффективность, безопасность и ремонтопригодность операционных процессов.

Интеграция DevOps предназначена для доставки продукта, непрерывного тестирования, тестирования качества, разработки функций и обновлений обслуживания для повышения надежности и безопасности и обеспечения более быстрого цикла разработки и развертывания.[8]

DevOps дает преимущества в управлении выпуском программного обеспечения для организации путем стандартизации среды разработки. События можно более легко отслеживать, а также разрешать документированные процессы управления и подробные отчеты. Подход DevOps предоставляет разработчикам больше контроля над средой, предоставляя инфраструктуре более ориентированное на приложения понимание.

Преимущества DevOps

Компании, которые используют DevOps, сообщили о значительных преимуществах, в том числе: значительно сокращении времени выхода на рынок, улучшении удовлетворенности клиентов, улучшении качества продукции, более надежных выпусках, повышении производительности и эффективности, а также увеличении способности создавать правильный продукт путем быстрого экспериментирования.[8]

Однако, исследование, выпущенное в январе 2017 года компанией «F5 Labs», на основе опроса почти 2200 ИТ-руководителей и специалистов отрасли, показало, что только один из пяти опрошенных полагает, что DevOps оказывает стратегическое влияние на их организацию, несмотря на рост использования. В том же исследовании было установлено, что только 17 % определили DevOps как ключевой инструмент.[9]

DevOps и архитектура

Чтобы эффективно использовать DevOps, прикладные программы должны соответствовать набору архитектурно значимых требований (ASR), таких как: возможность развертывания, изменяемость, тестируемость и возможности мониторинга.

Хотя в принципе можно использовать DevOps с любым архитектурным стилем, архитектурный стиль микросервисов становится стандартом для построения постоянно развернутых систем. Поскольку размер каждой услуги невелик, он позволяет создавать архитектуру отдельного сервиса посредством непрерывного рефакторинга, что уменьшает необходимость в большом предварительном дизайне и позволяет выпускать программное обеспечение на ранней стадии непрерывно.

Примечания

  1. Debois, Patrick DevOps Days Ghent (неопр.). DevopsDays. Дата обращения: 19 августа 2019.
  2. Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост об этом событии.
  3. Gartner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain (англ.) : journal. — Gartner, 2015. — 18 February.
  4. Theakanath, Thomas DevOps Stack on a Shoestring Budget (неопр.) (недоступная ссылка). devops.com. Дата обращения: 5 июня 2017. Архивировано 27 мая 2016 года.
  5. Stronger DevOps Culture with Puppet and Vagrant (неопр.) (недоступная ссылка). Puppet Labs. Дата обращения: 22 октября 2015. Архивировано 29 января 2016 года.
  6. Ambler, Scott W. We need more Agile IT Now! (неопр.) // Dr. Dobb’s The world of software Development. — San Francisco: UBM, 2014. — 12 February.
  7. Humble, Jez; Farley, David. Continuous Delivery: reliable software releases through build, test, and deployment automation (англ.). — Pearson Education Inc. (англ.)русск., 2011. — ISBN 978-0-321-60191-9.
  8. 1 2 Chen, Lianping. Continuous Delivery: Huge Benefits, but Challenges Too (англ.) // IEEE Software (англ.)русск. : journal. — 2015. — Vol. 32, no. 2. — P. 50. — doi:10.1109/MS.2015.27.
  9. Bourne, James. New research questions strategic importance of DevOps despite rise in usage (англ.) // CloudTech : journal. — 2017. — 23 January.
⚙️   Нормативный контроль Microsoft: 9903902
Рассказать друзьям:

Добавить комментарий