DevOps (DevOps)

DevOps (сокращение от development и operations) — это методология, направленная на автоматизацию процессов сборки, настройки и развёртывания программного обеспечения. Она объединяет разработчиков и специалистов по IT-обслуживанию, способствуя тесному взаимодействию и интеграции их процессов для достижения высокого качества программного продукта.

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

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

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

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

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

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

Возникновение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

Методики 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. Использование системы контроля версий позволяет применять практики код ревью, и откатывать конфигурацию назад.

Примечания

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

[devopsdaysghent-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 года.

[CD_HJ-7] Humble, Jez; Farley, David. Continuous Delivery: reliable software releases through build, test, and deployment automation (англ.). — Pearson Education^[англ.], 2011. — ISBN 978-0-321-60191-9.

[ieeexplore.ieee.org-8] ¹ ² 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 июня 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 года.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]