DevOps

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

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

Общее обозначение[править | править вики-текст]

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

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

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

Термин «DevOps» был популяризован серией встреч «DevOps Days», которые начали проходить в 2009 году в Бельгии[1]. С тех пор «DevOps-дни» прошли в Индии, США, Бразилии, Австралии, Германии и Швеции, России[2].

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

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

  1. Code — разработка и анализ кода, инструменты контроля версий, слияние кода;
  2. Build — инструменты непрерывной интеграции, статус сборки;
  3. Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;
  4. Пакет — репозиторий артефактов, предварительная установка приложения;
  5. Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;
  6. Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;
  7. Мониторинг — мониторинг производительности приложений, опыт работы с конечным пользователем.

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

Такие инструменты, как Docker (контейнеризация), Jenkins (непрерывная интеграция), Puppet (инфраструктура как код) и Vagrant (платформа виртуализации) — и многие другие — часто используются и часто упоминаются в дискуссиях по инструментам 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, сообщили о значительных преимуществах, в том числе: значительно сокращении времени выхода на рынок, улучшении удовлетворенности клиентов, улучшении качества продукции, более надежных выпусках, повышении производительности и эффективности, а также увеличении способности создавать правильный продукт путем быстрого экспериментирования.[9]

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

Ссылки[править | править вики-текст]

  1. Debois, Patrick DevOps Days Ghent. DevopsDays (2009). Проверено 31 марта 2011.
  2. Debois, Patrick DevOps Days. DevOps Days. Проверено 31 марта 2011.
  3. 'Gartner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain', Gartner, 18 February 2015 
  4. Theakanath, Thomas DevOps Stack on a Shoestring Budget. devops.com.
  5. Stronger DevOps Culture with Puppet and Vagrant. Puppet Labs. Проверено 22 октября 2015.
  6. Ambler, Scott W. (12 February 2014). «We need more Agile IT Now!». Dr. Dobb’s The world of software Development (UBM).
  7. Humble Jez. Continuous Delivery: reliable software releases through build, test, and deployment automation. — Pearson Education Inc.. — ISBN 978-0-321-60191-9.
  8. (2015) «Continuous Delivery: Huge Benefits, but Challenges Too». IEEE Software 32 (2): 50. DOI:10.1109/MS.2015.27.
  9. (2015) «Continuous Delivery: Huge Benefits, but Challenges Too». IEEE Software 32 (2): 50. DOI:10.1109/MS.2015.27.
  10. Bourne, James (23 January 2017). «New research questions strategic importance of DevOps despite rise in usage». CloudTech.