DevOps - DevOps

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

DevOps это набор практик, сочетающих разработка программного обеспечения (Dev) и ИТ-операции (Операции). Он направлен на сокращение жизненный цикл разработки систем и предоставить непрерывная доставка с высоким качество программного обеспечения.[1][2] DevOps дополняет Гибкая разработка программного обеспечения; несколько аспектов DevOps пришли из методологии Agile.

Определение

Ученые и практики не разработали однозначного определения термина «DevOps».[а][b][c][d]

С академической точки зрения, Лен Басс, Инго Вебер, и Лиминг Чжу —Три исследователя информатики из CSIRO и Институт программной инженерии - предложил определить DevOps как «набор практик, предназначенных для сокращения времени между фиксацией изменения в системе и внесением изменения в нормальное производство, обеспечивая при этом высокое качество».[6]

Однако термин DevOps использовался во многих контекстах.[7][ненадежный источник? ]

История

Многие идеи, лежащие в основе практики DevOps, вдохновлены такими практиками, как Худой и Деминга Планирование-выполнение-проверка-действие цикл, до Путь Toyota и Гибкий подход разбивки компонентов и размеров партий. Некоторые говорят, что DevOps возник отчасти как реакция на упреждающий подход "сверху вниз" ITIL в 1990-е гг. DevOps, как подход «снизу вверх», получил распространение и сохранился, потому что он был создан инженерами-программистами для разработчиков программного обеспечения и представляет собой гибкую практику, а не жесткую структуру.[8]

В 2009 году в г. Гент, Бельгия. Конференция была основана бельгийским консультантом, менеджером проектов и практиком Agile Патриком Дебуа.[9][ВОЗ? ][10] Конференция теперь распространилась на другие страны.[11]

В 2012 году Аланна Браун из Puppet разработала и выпустила отчет о состоянии DevOps.[12][13]По состоянию на 2014 год ежегодный отчет о состоянии DevOps был опубликован Николь Форсгрен, Джин Ким, Джез Хамбл и другие.[14][15]В 2014 году они обнаружили, что внедрение DevOps ускоряется.[14]Также в 2014 году Лиза Криспин и Джанет Грегори написали книгу «Более гибкое тестирование», содержащую главу о тестировании и DevOps.[16][17]

Цепочки инструментов

Основная статья: Набор инструментов DevOps

Поскольку DevOps задуман как кросс-функциональный режим работы, те, кто практикует эту методологию, используют разные наборы инструментов, называемые "инструменты "… А не один.[18] Ожидается, что эти инструментальные цепочки попадут в одну или несколько из следующих категорий, отражающих ключевые аспекты процесса разработки и доставки:[19][ненадежный источник? ][20][ненадежный источник? ]

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

Некоторые категории более важны в цепочке инструментов DevOps, чем другие; особенно непрерывная интеграция (например, Дженкинс, Gitlab, Bitbucket конвейеры) и инфраструктуру как код (например, Terraform, Ansible, Кукольный ).[21][ненадежный источник? ][22][ненадежный источник? ]

Форсгрен и другие. обнаружили, что производительность ИТ-отдела сильно коррелирует с такими практиками DevOps, как управление исходным кодом и непрерывная доставка.[14]

Отношение к другим подходам

Гибкий

Основная статья: Гибкая разработка программного обеспечения

Agile и DevOps выполняют взаимодополняющие роли: несколько стандартных практик DevOps, таких как автоматическая сборка и тестирование, непрерывная интеграция, и непрерывная доставка зародился в мире Agile, который (неофициально) восходит к 1990-м годам, а формально - к 2001 году.[23] Agile можно рассматривать как устранение пробелов в коммуникации между клиентами и разработчиками, в то время как DevOps устраняет пробелы между разработчиками и ИТ-операциями / инфраструктурой.[24] Кроме того, DevOps сосредоточен на развертывании разработанного программного обеспечения, независимо от того, разрабатывается ли оно с помощью Agile или других методологий.[23]

ArchOps

ArchOps представляет собой расширение для практики DevOps, начиная с программная архитектура артефакты вместо исходного кода для развертывания операции.[25] ArchOps заявляет, что архитектурные модели являются первоклассными объектами в разработке, развертывании и эксплуатации программного обеспечения.

TestOps

TestOps - это то же самое, что DevOps для разработки программного обеспечения. Идея - это набор инструментов, который связывает дизайн и тест операции вместе. В случае аппаратного обеспечения дизайн означает EDA инструменты и CAD отдел, а тест означает электронное измерительное оборудование, такое как осциллографы и так далее.[26]

Непрерывная доставка

Основная статья: Непрерывная доставка

Непрерывная доставка и DevOps имеют общие цели и часто используются вместе, но между ними есть тонкие различия.[27][28]

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

DevOps и непрерывная доставка имеют общую основу в гибкие методы и склонность к мышлению: небольшие и частые изменения, ориентированные на конечного потребителя.[29][ненадежный источник? ]Бережливое управление и непрерывная поставка имеют фундаментальное значение для более быстрого и устойчивого предоставления ценности.[15]Непрерывная доставка направлена ​​на то, чтобы программное обеспечение всегда находилось в готовом к выпуску состоянии на протяжении всего жизненного цикла.[14] Это делает доставку программного обеспечения дешевле и менее рискованной.[14]

Улучшение сотрудничества и коммуникации как между организационными командами, так и внутри них может помочь достичь более быстрого пора торговать, с пониженными рисками.[30][31]

DataOps

Основная статья: DataOps

Применение непрерывной доставки и DevOps для анализа данных получило название DataOps. DataOps стремится интегрировать инженерию данных, интеграцию данных, качество данных, безопасность данных и конфиденциальность данных с операциями.[32][ненадежный источник? ] Он применяет принципы DevOps, Гибкая разработка и Статистическое управление процессами, используется в бережливого производства, чтобы сократить время цикла извлечения выгоды из анализа данных.[33][ненадежный источник? ]

Инжиниринг надежности сайта

Основная статья: Инжиниринг надежности сайта

В 2003 г. Google развитый проектирование надежности сайта (SRE), подход к непрерывному выпуску новых функций в крупномасштабные системы высокой доступности при сохранении высокого качества обслуживания конечных пользователей.[34] Хотя SRE предшествует разработке DevOps, они обычно рассматриваются как связанные друг с другом.[35][ненадежный источник? ]

Системное администрирование

DevOps часто рассматривается как подход к применению системное администрирование работать с облачными технологиями.[36]

WinOps

Основная статья: WinOps

WinOps это термин, используемый для практики DevOps для представления, ориентированного на Microsoft.[нужна цитата ]

Производственная система Toyota, бережливое мышление, кайдзен

Основная статья: Производственная система Toyota

Производственная система Toyota, также известная под аббревиатурой TPS, послужила источником вдохновения для склонность к мышлению с упором на постоянное улучшение, кайдзен, проточные и мелкие партии. В Принцип шнура Андона для создания быстрой обратной связи, роения и решения проблем проистекает из TPS.[37][38]

DevSecOps, перенос безопасности влево

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

Цели

Производительность ИТ можно измерить с точки зрения пропускной способности и стабильности.[14]Пропускную способность можно измерить по частоте развертывания и времени выполнения изменений; стабильность можно измерить по среднему времени восстановления. Отчет State of DevOps Reports показал, что инвестирование в методы, которые увеличивают эти показатели пропускной способности и стабильности, повышают производительность ИТ.[14][15]

Цели DevOps охватывают весь конвейер доставки. Они включают:[нужна цитата ]

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

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

Цели интеграции DevOps доставка продукции, непрерывное тестирование, проверка качества, разработка функций и выпуски обслуживания для повышения надежности и безопасности и более быстрого разработка и развертывание циклы.[нужна цитата ] Многие идеи (и люди), вовлеченные в DevOps, пришли из управление системами предприятия и гибкая разработка программного обеспечения движения.[40][ненадежный источник? ]

Практики, которые коррелируют с частотой развертывания:[14]

  • Непрерывная доставка
  • Использование контроля версий для всех производственных артефактов

Практики, которые соотносятся со сроком выполнения изменений:[14]

  • Использование контроля версий для всех производственных артефактов
  • Автоматизированное тестирование

Практики, которые коррелируют со средним временем восстановления после изменений:[14]

  • Использование контроля версий для всех производственных артефактов
  • Система мониторинга и работоспособность приложений

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

Отчет о состоянии DevOps за 2014 год показал, что «производительность ИТ сильно коррелирует с хорошо известными практиками DevOps, такими как использование контроля версий и непрерывная доставка».[14]

Критика

В академической литературе отсутствуют доказательства эффективности DevOps.[e]

Культурные изменения

Инициативы DevOps могут привести к культурным изменениям в компаниях[42] преобразовав способ операции, Разработчики, и тестеры сотрудничать в процессе разработки и доставки.[2] Заставить эти группы работать слаженно - важнейшая задача при внедрении корпоративного DevOps.[43][44] DevOps - это не только культура, но и набор инструментов.[45]

DevOps как должность

Хотя DevOps описывает подход к работе, а не отдельную роль (например, Системный администратор ) в объявлениях о вакансиях все чаще используются такие термины, как "DevOps инженер".[46][ненадежный источник? ][47]

В то время как DevOps отражает сложные темы, сообщество DevOps использует аналогии для передачи важных концепций,[соответствующий? – обсуждать] так же, как "Собор и базар "из сообщества разработчиков ПО с открытым исходным кодом.[48]

  • Cattle not Pets: парадигма одноразовой серверной инфраструктуры.[49]
  • 10 развертываний в день: история внедрения DevOps на Flickr.

Создание культуры DevOps

Организационная культура является сильным показателем эффективности ИТ и организации. Культурные обычаи, такие как поток информации, сотрудничество, разделение ответственности, обучение на ошибках и новые идеи, являются центральными для DevOps.[14] Психологическая безопасность - фундаментальный фактор развития культуры DevOps., и это отражено в Джин Ким «Пять идеалов» DevOps. Тимбилдинг и другое вовлечения сотрудников Действия часто используются для создания среды, которая способствует этому общению и культурным изменениям в организации.[50] Мероприятия по построению команды могут включать: настольные игры, доверительные мероприятия и семинары по вовлечению сотрудников.[51][ненадежный источник? ]DevOps как сервисный подход позволяет разработчикам и операторам лучше контролировать свои приложения и инфраструктуру без снижения скорости.

В отчете о состоянии DevOps за 2015 год было обнаружено, что семь основных показателей с наибольшей корреляцией с организационной культурой: 1. Организационные инвестиции в DevOps:[15]2. Опыт и эффективность руководителей команд. Непрерывная доставка 4. Способность различных дисциплин (разработки, эксплуатации и информационной безопасности) достигать беспроигрышных результатов. Организационная эффективность 6. Боль при развертывании 7. Практики бережливого управления.

Развертывание

Компаниям с очень частыми выпусками могут потребоваться знания о DevOps.[нужна цитата ] Например, компания, которая управляет веб-сайтом хостинга изображений Flickr разработал подход DevOps для поддержки десяти развертываний в день.[52] Ежедневные циклы развертывания будут намного выше в организациях, производящих многоцелевые или многофункциональные приложения.[нужна цитата ] Ежедневное развертывание называется непрерывное развертывание[53][ненадежный источник? ] или же непрерывная доставка[54][ненадежный источник? ] и был связан с бережливый стартап методология.[55][ненадежный источник? ] Профессиональные ассоциации и сообщения в блогах формируются по теме с 2009 года.[56][ненадежный источник? ][57][ненадежный источник? ]

Архитектурно значимые требования

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

Микросервисы

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

DevOps автоматизация

Автоматизация DevOps может быть достигнута путем переупаковки платформ, систем и приложений в повторно используемые строительные блоки.[60] за счет использования таких технологий, как виртуальные машины и контейнеризация.[61][ненадежный источник? ][62]

Внедрение автоматизации DevOps в IT-организации сильно зависит от инструментов,[14][63][ненадежный источник? ] которые требуется[нужна цитата ] для покрытия различных областей жизненный цикл разработки систем (SDLC):

  1. Инфраструктура как код
  2. CI / CD
  3. Автоматизация тестирования
  4. Контейнеризация
  5. Оркестровка
  6. Развертывание программного обеспечения
  7. Программное обеспечение измерения

Принятие

Практика и внедрение DevOps

Джаббари и др.[41] определили методы DevOps и их зависимости. Они разработали сеть зависимости преимуществ[64][циркулярная ссылка ] который связывает потенциальные выгоды с упорядоченной цепочкой практик. Используя эту сеть, организации могут выбрать путь, который позволит выполнить их цели.

Некоторые статьи в литературе DevOps предполагают или рекомендуют значительное участие в инициативах DevOps извне организации. ЭТО отдела, например: "DevOps - это просто гибкий принцип, взятый на полное предприятие ».[65][ненадежный источник? ]

В обзоре, опубликованном в январе 2016 года компанией, занимающейся облачными вычислениями SaaS RightScale, Внедрение DevOps увеличилось с 66 процентов в 2015 году до 74 процентов в 2016 году.[нужна цитата ] А среди крупных корпоративных организаций внедрение DevOps еще выше - 81 процент.[66][ненадежный источник? ]

Принятие DevOps обусловлено многими факторами, в том числе:[нужна цитата ]

  1. Использование agile и других процессы разработки и методы;
  2. Спрос на увеличение количества выпусков продукции - от приложений и бизнес-единиц заинтересованные стороны;
  3. Широкая доступность виртуализированных[67][ненадежный источник? ] и облачная инфраструктура - от внутренних и внешних провайдеров;
  4. Увеличение использования Дата центр автоматизация[68][ненадежный источник? ] и управление конфигурацией инструменты;
  5. Повышенное внимание к автоматизация тестирования[69][ненадежный источник? ] и непрерывная интеграция методы;
  6. Критическая масса общедоступных передовых практик.

Смотрите также

Примечания

  1. ^ Dyck et. al (2015) «Насколько нам известно, не существует единого определения терминов« релиз-инжиниринг »и« DevOps ». Как следствие, многие люди используют свои собственные определения или полагаются на другие, что приводит к путанице в отношении этих терминов».[3]
  2. ^ Jabbari et. al (2016) «Результаты этого исследования показали необходимость определения, поскольку отдельные исследования не всегда определяют DevOps».[4]
  3. ^ Erich et. al (2017) «Мы заметили, что существуют различные пробелы в изучении DevOps: нет единого мнения о том, какие концепции охватывает DevOps и как определяется DevOps».[5]
  4. ^ Erich et. al (2017) «Мы обнаружили, что в академической литературе существует небольшое согласие относительно характеристик DevOps».[5]
  5. ^ Erich et. al (2017) «Мы заметили, что есть различные пробелы в изучении DevOps: [...] Отсутствуют доказательства эффективности DevOps.[5][41]

Рекомендации

  1. ^ Мала, Д.Дж. (2019). Интеграция Интернета вещей в практику разработки программного обеспечения. Достижения в области системного анализа, разработки программного обеспечения и высокопроизводительных вычислений. IGI Global. п. 16. ISBN  978-1-5225-7791-1. Получено 4 апреля 2019.
  2. ^ а б Лукидес, Майк (7 июня 2012 г.). "Что такое DevOps?". O'Reilly Media.
  3. ^ Дайк, Андрей; Пеннерс, Ральф; Лихтер, Хорст (19 мая 2015 г.). «К определениям для разработки релизов и DevOps». Труды 3-го международного семинара IEEE / ACM 2015 года по разработке релизов. IEEE: 3. Дои:10.1109 / RELENG.2015.10. ISBN  978-1-4673-7070-7. S2CID  4659735.
  4. ^ Джаббари, Рамтин; бин Али, Науман; Петерсен, Кай; Танвир, Биниш (май 2016 г.). «Что такое DevOps ?: систематическое сопоставление определений и практик». Материалы научно-практического семинара 2016 г.. Ассоциация вычислительной техники.
  5. ^ а б c Erich, F.M.A .; Amrit, C .; Данева М. (июнь 2017 г.). «Качественное исследование использования DevOps на практике». Журнал программного обеспечения: эволюция и процесс. 29 (6): e1885. Дои:10.1002 / smr.1885.
  6. ^ Бас, Лен; Вебер, Инго; Чжу, Лиминг (2015). DevOps: взгляд архитектора программного обеспечения. ISBN  978-0134049847.
  7. ^ «Сюрприз! Широкое согласие по определению DevOps». DevOps.com. 13 мая 2015.
  8. ^ "История и эволюция DevOps | Том Герати". Получено 29 ноябрь 2020.
  9. ^ Мезак, Стив (25 января 2018 г.). «Истоки DevOps: что в названии?». DevOps.com. Получено 6 мая 2019.
  10. ^ Дебуа, Патрик. "Agile 2008 Торонто". Достаточно документированной информации. Получено 12 марта 2015.
  11. ^ Дебуа, Патрик. «Дни DevOps». Дни DevOps. Получено 31 марта 2011.
  12. ^ Алана Браун; Николь Форсгрен; Jez Humble; Найджел Керстен; Джин Ким (2016). «Отчет о состоянии DevOps за 2016 год» (PDF). Puppet Labs, DORA (исследования DevOps. Получено 6 мая 2019.
  13. ^ "Марионетка - Аланна Браун". Кукольные лаборатории. Получено 27 апреля 2019.
  14. ^ а б c d е ж грамм час я j k л м Николь Форсгрен; Джин Ким; Найджел Керстен; Jez Humble (2014). «Отчет о состоянии DevOps за 2014 год» (PDF). Puppet Labs, IT Revolution Press и ThoughtWorks. Получено 27 апреля 2019.
  15. ^ а б c d «Отчет о состоянии DevOps за 2015 год» (PDF). Puppet Labs, Pwc, IT Revolution Press. 2015 г.. Получено 6 мая 2019.
  16. ^ «Более гибкое тестирование» (PDF). Октябрь 2014 г.. Получено 6 мая 2019.
  17. ^ Криспин, Лиза; Грегори, Джанет (октябрь 2014 г.). Более гибкое тестирование. ISBN  9780133749571. Получено 6 мая 2019.
  18. ^ Тенденции рынка Gartner: DevOps - не рынок, а философия, ориентированная на инструменты, поддерживающая непрерывную цепочку создания стоимости (отчет). Gartner. 18 февраля 2015.
  19. ^ Эдвардс, Дэймон. «Интеграция инструментов DevOps в платформу предоставления услуг». dev2ops.org.
  20. ^ Серотер, Ричард. «Изучение ВСЕЙ цепочки инструментов DevOps для (облачных) команд». infoq.com.
  21. ^ Теаканат, Томас (5 февраля 2016 г.). «DevOps Stack в ограниченном бюджете». DevOps.com.
  22. ^ «Более сильная культура DevOps с Puppet и Vagrant». Кукольные лаборатории. Получено 22 октября 2015.
  23. ^ а б Уоттс, Стивен; Кидд, Крисси (10 августа 2017 г.). «DevOps vs Agile: в чем разница и как они связаны?». bmc.com. Получено 1 марта 2019.
  24. ^ «Agile vs DevOps: в чем разница?». guru99.com. Получено 1 марта 2019.
  25. ^ Кастелланос, Камило; Корреаль, Дарио (15 сентября 2018 г.). Выполнение архитектурных моделей для аналитики больших данных. Конспект лекций по информатике. 11048. С. 364–371. Дои:10.1007/978-3-030-00761-4_24. ISBN  978-3-030-00760-7.
  26. ^ Keysight (19 марта 2019 г.). «Манифест TestOps: план для подключенного, гибкого проектирования и тестирования» (PDF). Получено 11 сентября 2019. Компании, использующие рабочие процессы DevOps, сообщают о повышении производительности своих инженеров на 29%. TestOps - DevOps для проектирования и тестирования - обещает аналогичные преимущества.
  27. ^ а б Скромный, Джез; Фарли, Дэвид (2011). Непрерывная доставка: надежные выпуски программного обеспечения за счет автоматизации сборки, тестирования и развертывания. Pearson Education Inc. ISBN  978-0-321-60191-9.
  28. ^ Хаммонд, Джеффри (9 сентября 2011 г.). «Взаимосвязь между DevOps и непрерывной доставкой». Forrester Research.
  29. ^ Эмблер, Скотт В. (12 февраля 2014 г.). «Нам нужно больше Agile IT прямо сейчас!». Доктор Добб "Мир разработки программного обеспечения".
  30. ^ а б Чен, Ляньпин (2015). «Непрерывная доставка: огромные преимущества, но и проблемы». Программное обеспечение IEEE. 32 (2): 50–54. Дои:10.1109 / MS.2015.27. S2CID  1241241.
  31. ^ а б Чен, Ляньпин (2018). Микросервисы: проектирование для непрерывной доставки и DevOps. Международная конференция IEEE по архитектуре программного обеспечения (ICSA 2018). IEEE.
  32. ^ «От DevOps к DataOps, Энди Палмер - Tamr Inc». Tamr Inc. 7 мая 2015. Получено 23 августа 2017.
  33. ^ DataKitchen (15 марта 2017 г.). «Как стать восходящей звездой с помощью аналитики данных». дата-операторы. Получено 23 августа 2017.
  34. ^ Бейер, Бетси; Джонс, Крис; Петофф, Дженнифер; Мерфи, Найл Ричард (апрель 2016 г.). Проектирование надежности сайта. O'Reilly Media. ISBN  978-1-4919-2909-4.
  35. ^ «SRE против DevOps - ложное различие? - DevOps.com». 18 мая 2017.
  36. ^ «Как оставаться актуальным в эпоху DevOps: руководство системного администратора по выживанию».
  37. ^ Анализ ДНК DevOps, Брент Аарон Рид, Вилли Шауб, 14 ноября 2018 г.
  38. ^ Справочник DevOps: как добиться гибкости, надежности и безопасности мирового класса в технологических организациях, Джин Ким, Патрик Дебуа, Джон Уиллис, Джезз Хамбл, 2016 г.
  39. ^ "Что такое DevOps?". NewRelic.com. Получено 21 октября 2014.
  40. ^ Насрат, Пол. «Гибкая инфраструктура». InfoQ. Получено 31 марта 2011.
  41. ^ а б Джаббари, Рамтин; Али, Науман бин; Петерсен, Кай; Танвир, Биниш (ноябрь 2018 г.). «К сети зависимости преимуществ для DevOps на основе систематического обзора литературы». Журнал программного обеспечения: эволюция и процесс. 30 (11): e1957. Дои:10.1002 / smr.1957.
  42. ^ Анализ новых технологий: DevOps - это культурный сдвиг, а не технология (отчет). Gartner.
  43. ^ «Глоссарий Gartner IT - DevOps». Gartner. Получено 30 октября 2015.
  44. ^ Джонс, Стивен; Ноппен, Йуст; Леттис, Фиона (21 июля 2016 г.). Труды 2-го Международного семинара по качественным разработчикам Операции - QUDOS 2016 (PDF). С. 7–11. Дои:10.1145/2945408.2945410. ISBN  9781450344111. S2CID  515140.
  45. ^ Mandi Walls (25 сентября 2015 г.). «Создание культуры DevOps». О'Рейли.
  46. ^ «DevOps - это титул? - DevOps.com». DevOps.com. 20 марта 2014 г.. Получено 22 июля 2017.
  47. ^ «DevOps: должность или научная школа?». Совет по карьере монстра. Получено 22 июля 2017.
  48. ^ «Какие мемы считаются полезными и вводящими в заблуждение в культуре DevOps?». DevOps.stackexchange.com. Получено 29 июн 2017.
  49. ^ Шарвуд, Саймон. "Ваши серверы домашние животные или крупный рогатый скот?". Реестр. Получено 2 июля 2018.
  50. ^ Стены, Манди (15 апреля 2013 г.). Создание культуры DevOps. OReilly Media. ISBN  9781449368364.
  51. ^ Роуч, Патрик (8 октября 2015 г.). "Dice Breakers: Использование принципов DevOps и умения переосмыслить построение команды". DevOps.com.
  52. ^ «10+ развертываний в день: сотрудничество разработчиков и операторов на Flickr». 23 июня 2009 г.
  53. ^ «SAM SIG: Прикладные идеи бережливого стартапа: непрерывное развертывание в компании kaChing». SVForum. Архивировано из оригинал 20 октября 2012 г.. Получено 20 июн 2011.
  54. ^ Скромный, Джез. «Почему предприятия должны использовать Devops, чтобы обеспечить непрерывную доставку». Cutter IT Journal.
  55. ^ «Прикладные идеи экономичного стартапа: непрерывное развертывание в компании kaChing». 26 мая 2010 г.
  56. ^ «Конференция DevOps Days 2009».
  57. ^ Эдвардс, Дэймон. «Итоги встречи DevOps».
  58. ^ Чен, Ляньпин (2015). К архитектуре для непрерывной доставки. 12-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA 2015). Монреаль, Канада: IEEE. Дои:10.1109 / WICSA.2015.23.
  59. ^ Чен, Ляньпин; Али Бабар, Мухаммед (2014). К основанному на фактах пониманию появления архитектуры посредством непрерывного рефакторинга в гибкой разработке программного обеспечения. 11-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA 2014). IEEE. Дои:10.1109 / WICSA.2014.45. Архивировано из оригинала| архив-url = требует | url = (помощь) 30 июля 2014 г.
  60. ^ Кляйн, Брэндон; Шахтер, Джон (2018). DevOps: изображения, скрипты, API, о боже!. Саммит НЛИТ 2018. ОСТИ. OSTI  1512856.
  61. ^ «Раскрытие всего потенциала контейнеризации для DevOps». 20 сентября 2017 г.. Получено 20 июн 2018.
  62. ^ «Контейнеры против виртуальных машин: упрощенный ответ на сложный вопрос».
  63. ^ «Лучшие практики DevOps: какая автоматизация вам нужна?». TechBeacon. Получено 14 ноября 2018.
  64. ^ «Сеть зависимости выгоды». Википедия. 31 мая 2020.
  65. ^ «DevOps - это гибкость для остальной компании». DevOps.com. 4 марта 2015 г.
  66. ^ Харви, Синтия (9 января 2017 г.). «10 способов, которыми DevOps меняет предприятие». Датамация.
  67. ^ «Продукты виртуальной инфраструктуры: сравнение характеристик». Добро пожаловать в IT 2.0: ИТ-инфраструктуры нового поколения.
  68. ^ Эллард, Дженнифер. «Наведение порядка в хаос с помощью автоматизации центров обработки данных». Управление информацией. SourceMedia. Архивировано из оригинал 11 июня 2010 г.
  69. ^ «Влияние DevOps на тестирование». DevOps.com. 21 августа 2015.

дальнейшее чтение

  • Дэвис, Дженнифер; Дэниелс, Рин (30 мая 2016 г.). Эффективный DevOps: создание культуры сотрудничества, близости и масштабного использования инструментов. Севастополь, Калифорния: О'Рейли. ISBN  9781491926437. OCLC  951434424.
  • Ким, Джин; Дебуа, Патрик; Уиллис, Джон; Скромный, Джез; Олспоу, Джон (7 октября 2015 г.). Справочник DevOps: как обеспечить гибкость, надежность и безопасность мирового уровня в технологических организациях (Первое изд.). Портленд, штат Орегон. ISBN  9781942788003. OCLC  907166314.
  • Форсгрен, Николь; Скромный, Джез; Ким, Джин (27 марта 2018 г.). Accelerate: наука об экономичном программном обеспечении и DevOps: создание и масштабирование высокопроизводительных технологических организаций (Первое изд.). IT Revolution Press. ISBN  9781942788331.