DevOps (акроним от англ.

development & operations) — методология автоматизации технологических

процессов сборки, настройки и развёртывания программного обеспечения. Методология
предполагает активное взаимодействие специалистов по разработке со специалистами
по информационно-технологическому обслуживанию и взаимную интеграцию их технологических
процессов друг в друга для обеспечения высокого качества программного продукта. Предназначена
для эффективной организации создания и обновления программных продуктов и услуг. Основана на
идее тесной взаимозависимости создания продукта и эксплуатации программного обеспечения,
которая прививается команде как культура создания продукта.
Организациям, которым необходимы частые выпуски программного обеспечения, может
понадобиться DevOps, т.е. автоматизация технологических процессов сборки, настройки и
развёртывания программного обеспечения. Дневной цикл выпусков ПО может быть гораздо более
интенсивным у организаций, которые выпускают несколько разнонаправленных приложений.
Методология фокусируется на стандартизации окружений разработки с целью быстрого переноса
программного обеспечения через стадии жизненного цикла ПО, способствуя быстрому выпуску
версий программного продукта. В идеале, системы автоматизации сборки и выпуска должны быть
доступны всем разработчикам в любом окружении, и у разработчиков должен быть контроль над
окружением разработки, а информационно-технологическая инфраструктура должна становиться
более сфокусированной на приложении.
Задача инженеров автоматизации технологических процессов сборки, настройки и развёртывания
программного обеспечения (DevOps engineers) — сделать процессы разработки и поставки
программного обеспечения согласованным с эксплуатацией, объединив их в единое целое с
помощью инструментов автоматизации.
Движение за автоматизацию технологических процессов сборки, настройки и развёртывания
программного обеспечения (DevOps-движение) возникло в 2009 году и было призвано решить
проблемы взаимодействия команд разработки и эксплуатации программных продуктов. В том же
году в Бельгии была организована серия конференций «DevOps Days»[1][2]. Затем «DevOps-дни»
проходили в различных городах и странах мира.

Содержание

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

Возникновение[править | править код]

Истоками того, что стало современным DevOps, включая некоторые стандартные принципы, такие
как: автоматизация сборки и тестирование, непрерывная интеграция и непрерывная доставка —
возникли в мире Agile, который (неофициально) датируется 1990-ми годами, а формально —
2001 годом. Команды разработчиков, использующие такие методы, как экстремальное
программирование, не смогли бы «удовлетворить потребности заказчика, благодаря регулярной и
ранней поставке ценного программного обеспечения»[3], если бы эти методы не включали в себя
обязанности по настройке операций и поддержанию инфраструктуры разрабатываемого
приложения (в максимально автоматизированном режиме). Поскольку Scrum стал доминирующей
гибкой структурой в начале 2000-х годов, и в нем отсутствовали инженерные методы, которые были
частью многих Agile команд, движение за автоматизацию операций/функций инфраструктуры
отделилось от Agile и расширилось до того, что стало современными DevOps. Сегодня DevOps
фокусируется на развертывании разработанного программного обеспечения, независимо от того,
разработано ли оно с помощью гибких или других методологий.
Таким образом, косвенно, потребность в DevOps родилась из-за растущей популярности
методологии разработки Agile, поскольку это привело к увеличению количества выпускаемых
версий.

Набор инструментов[править | править код]

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

1. Кодирование — разработка и анализ кода, инструменты контроля версий, слияние кода;

2. Сборка — инструменты непрерывной интеграции, статус сборки;
3. Тестирование — инструменты непрерывного тестирования, обеспечивающие быструю и
своевременную оценку бизнес-рисков;
4. Упаковка — репозиторий артефактов, предварительная установка приложения;
5. Релиз — управление изменениями, официальное утверждение выпуска, автоматизация
выпуска;
6. Настройка — конфигурация и управление инфраструктурой, Инфраструктура как
инструменты кода;
7. Мониторинг — измерение производительности приложений, взаимодействие с конечным
пользователем;
8. Непрерывная поставка;
9. Непрерывная интеграция.
Несмотря на то, что доступно множество инструментов, некоторые категории из них имеют особо
важное значение в настройке инструментальных средств DevOps для использования в организации.
Некоторые попытки идентифицировать эти основные инструменты можно найти в существующей
литературе[5].
Такие инструменты, как управление контейнеризацией (Docker, Kubernetes), непрерывной
интеграцией (Jenkins, GitLab), развёртывания сред по шаблону (Puppet, Ansible, Terraform) и многие
другие — часто используются и часто упоминаются в дискуссиях по инструментам DevOps[6].

Сравнение с Continuous delivery[править | править код]

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

Архитектурные условия[править | править код]

Чтобы эффективно использовать DevOps, прикладные программы должны соответствовать набору
архитектурно значимых требований (ASR), таких как: возможность развертывания, изменяемость,
тестируемость и возможности мониторинга.
Хотя в принципе можно использовать DevOps с любым архитектурным стилем, стиль микросервисов
становится стандартом для построения постоянно развёрнутых[уточнить] систем. Поскольку размер
каждого сервиса невелик, появляется возможность изменять каждый отдельный сервис
посредством непрерывного рефакторинга, что уменьшает необходимость в большом
предварительном дизайне и позволяет выпускать программное обеспечение на ранней стадии
непрерывно.
GitOps[править | править код]
GitOps эволюционировал из DevOps[10][11][12]. В рамках этого подхода, специфическое состояние
конфигурации коммитится в Git, давшего имя подходу. В теории, вместо Git может использоваться
другая система контроля версий, но на практике это почти всегда Git. Использование системы
контроля версий позволяет применять практики код ревью, и откатывать конфигурацию назад.

Примечания[править | править код]

1. ↑ Debois, Patrick DevOps Days Ghent. DevopsDays. Дата обращения: 19 августа 2019. Архивировано 24
марта 2011 года.
2. ↑ Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост Архивная
копия от 25 августа 2019 на Wayback Machine об этом событии.
3. ↑ Основополагающие принципы Agile-манифеста. agilemanifesto.org. Дата обращения: 10 ноября
2021. Архивировано 20 января 2022 года.
4. ↑ Gartner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous
Delivery Value Chain (англ.) : journal. — Gartner, 2015. — 18 February.
5. ↑ Theakanath, Thomas DevOps Stack on a Shoestring Budget. laptrinhx.com. Дата обращения: 5 февраля
2016. Архивировано 21 марта 2022 года.
6. ↑ Stronger DevOps Culture with Puppet and Vagrant. Puppet Labs. Дата обращения: 22 октября 2015.
Архивировано из оригинала 29 января 2016 года.
7. ↑ Humble, Jez; Farley, David. Continuous Delivery: reliable software releases through build, test, and
deployment automation (англ.). — Pearson Education[en], 2011. — ISBN 978-0-321-60191-9.
8. ↑ Перейти обратно:1 2 Chen, Lianping. Continuous Delivery: Huge Benefits, but Challenges
Too (англ.) // IEEE Software[en] : journal. — 2015. — Vol. 32, no. 2. — P.
50. — doi:10.1109/MS.2015.27. Архивировано 9 июня 2016 года.
9. ↑ Bourne, James. New research questions strategic importance of DevOps despite rise in usage (англ.) //
CloudTech : journal. — 2017. — 23 January. Архивировано 1 марта 2017 года.
10. ↑ Getting Started with GitOps. TheNewStack.io (13 декабря 2021). Дата обращения: 5 апреля
2022. Архивировано 20 сентября 2022 года.
11. ↑ GitOps Workflows and Principles for Kubernetes. ContainerJournal.com (1 апреля 2022). Дата
обращения: 5 апреля 2022. Архивировано 20 сентября 2022 года.
12. ↑ Kubernetes at Scale without GitOps Is a Bad Idea. TheNewStack.io (7 марта 2022). Дата обращения: 5
апреля 2022. Архивировано 20 сентября 2022 года.