Agile DevOps ― гибкая разработка и эксплуатация ПО: Выравнивание процесса выпуска программного обеспечения

Как модель DevOps преображает процесс поставки программного обеспечения

Что значит «выровнять» процесс выпуска программного обеспечения? Как это повлияет на структуру организации? В первой статье из цикла Agile DevOps ― гибкая разработка и эксплуатация ПО эксперт в области подхода DevOps Пол Дюваль описывает, как разработчики и подразделения объединяются в группы поставки программного обеспечения для рационализации процесса разработки и выпуска ПО. Он обсуждает такие новые методы работы, как управляемые тестированием инфраструктуры, подвижные среды и Chaos Monkey - а также способы применения этих методов для ускорения поставок программного обеспечения пользователям.

Пол Дюваль, технический директор, Stelligent Incorporated

Paul DuvallПол Дюваль (Paul Duvall) является техническим директором компании Stelligent Incorporated – консалтинговой фирмы, которая помогает командам разработчиков оптимизировать гибкие методологии разработки программного обеспечения. Он также соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007 г.). Он принимал участие в создании книг UML 2 Toolkit (Wiley, 2003 г.) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007 г.).



01.03.2013

Об этом цикле статей

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

Когда речь заходит о поставке программного обеспечения пользователям, методам гибкой разработки во многих организациях еще только предстоит сдержать некоторые из своих обещаний. Причин этому много, но главная проблема ― это рассогласование в структуре организации. Чаще всего группы разработки и группы эксплуатации компании находятся в разных структурных подразделениях с единственным общим руговодителем — генеральным директором, который обычно поручает принимать соответствующие решения своим подчиненным. Цели этих двух групп вступают в неизбежный конфликт. Производительность разработки измеряется количеством функций, предоставленных бизнес-подразделениям, а группы эксплуатации ― временем непрерывной работы системы — ее стабильностью. Таким компаниям обычно недостает целостного представления о системе программного обеспечения, и ни одна из групп не имеет надлежащей мотивации к достижению цели регулярной поставки высококачественных функций, выполняемых в стабильной среде.

Изданная в 2005 году книга Томаса Фридмана The World is Flat (Мир ― плоский) показывает, что такие факторы, как глобализация, программное обеспечение, Интернет и открытие границ некоторых развивающихся стран приводят к «выравниванию», устраняя традиционные барьеры, препятствовавшие участию людей в мировой экономике. В настоящее время индустрия программного обеспечения демонстрирует свою собственную тенденцию к «выравниванию» внутри компаний, которые стремятся к конкурентному преимуществу: выравниванию выпусков программного обеспечения и организационных структур. Эта трансформация — ставшая возможной благодаря слиянию автоматизации, инструментария, сотрудничества и практических рекомендаций и моделей — ускоряет, улучшает и удешевляет поставку программного обеспечения этими компаниями.

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

Будьте в курсе

Раздел Agile transformation портала developerWorks содержит новости, обсуждения и учебные материалы, которые помогут вам и вашей организации строить фундамент на принципах гибкой разработки (EN).

Гибкая разработка плюс эксплуатация

Три из 12 принципов в Agile-манифеста (см. раздел Ресурсы) относятся к практике поставки программного обеспечения:

  • «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения».
  • «Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев».
  • «Работающий продукт — основной показатель прогресса».

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

В основе мотивации, ведущей к движению DevOps, лежит разочарование процессом выпуска и поддержки систем программного обеспечения разрозненными группами. В типичном проекте разработки программного обеспечения и в более широком плане ответственность за разработку и поставку ПО несут две группы: разработки и эксплуатации. Эти две группы должны сотрудничать, но часто их мотивы противоположны. Для группы разработки это добавление новых функций. А для группы эксплуатации ― обеспечение стабильности работы систем. Часто между группами возникает недопонимание, которое приводит к сбоям в конце процесса поставки программного обеспечения.

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


Модели

Модель программного обеспечения ― это решение задачи в конкретном контексте (при этом контекст служит ключом, определяющим отличие реальных моделей от образцовых). К категории Agile DevOps относятся такие модели, как автоматизированная инициализация среды (scripted environments), инфраструктура, управляемая тестами (test-driven infrastructures), Chaos Monkey, все под управлением версиями (versioning everything), конвейер поставки (delivery pipeline) и информационная панель DevOps (DevOps dashboard). Я представляю здесь все эти модели и в следующих статьях цикла буду уточнять их детали.

Автоматизированная инициализация среды

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

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

Средства автоматизации инфраструктуры, о которых мы будем говорить в этом цикле, поддерживают данную модель. Один из таких инструментов ― Puppet. Фрагмент кода, приведенный в листинге 1, иллюстрирует базовую программу Puppet, называемую манифестом.

Листинг 1. Автоматизация инициализации среды: фрагмент манифеста Puppet httpd
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Как правило, сценарий инфраструктуры состоит из множества манифестов. Эти сценарии фиксируются в хранилище управления версиями, как код приложений.

Инфраструктура, управляемая тестами

Простой предпосылкой DevOps является применение передового опыта и передовых моделей от разработки до эксплуатации и от эксплуатации до разработки. Подход, управляемый тестами, состоит в написании тестов вместе с кодом, и его истоки кроются в разработке программного обеспечения. Когда средства автоматизации инфраструктуры стали более распространенными в организациях, инженеры начали применять к своей инфраструктуре методы, основанные на тестировании; инфраструктура описывается сценарием (как в листинге 1), и этот сценарий тестируется. Вот некоторые из многочисленных преимуществ инфраструктуры на основе тестов:

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

Листинг 2 иллюстрирует простой сценарий проверки работоспособности Web-сервера. В нем используется инструмент разработки на основе поведения (т.н. разработка на основе приемочных испытаний) Cucumber, в котором тесты описаны в форме сценариев.

Листинг 2. Тест инфраструктуры в Cucumber
Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

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

Chaos Monkey

Пару лет назад ИТ-группа компании Netflix разработала инструмент непрерывного тестирования Chaos Monkey. Этот инструмент регулярно ― намеренно и случайным образом ― отключает отдельные экземпляры в производственной инфраструктуре Netflix, чтобы убедиться, что в случае отказа система продолжает работать. Недавно он выпущен в виде ПО с открытым исходным кодом (см. раздел Ресурсы).

Принцип, которому следует Netflix, заключается в том, что «всё то и дело отказывает» ("everything fails, all the time" ― мантра, придуманная Вернером Фогельсом, техническим директором Amazon.com). Как утверждает Netflix, «Задача Chaos Monkey заключается в том, чтобы случайным образом убивать экземпляры систем и служб в нашей архитектуре. Если мы не будем постоянно проверять свою способность успешно работать, несмотря на отказы, то вряд ли сможем работать, когда это важнее всего — в случае внезапного отказа" (см. раздел Ресурсы). В следующих статьях этого цикла мы рассмотрим Chaos Monkey и его роль в правильно функционирующей среде DevOps.

Кратковременная среда

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

Когда среда полностью описана сценариями, она перестает быть уникальной. Все определено в шаблонах и проверено в системе с управлением версиями. Среду на базе сценариев можно безболезненно уничтожить. Этот подход создает два преимущества: он делает ресурсы доступными для других и укрепляет идею, что все нужно автоматизировать — а не лелеять и выращивать вручную неделями и месяцами. Мы еще поговорим о кратковременных средах в этом цикле статей.

Все под управлением версиями

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

Цель управления версиями всего ― установить единый источник истины (или каноническую версию, или систему регистрации) системы программного обеспечения; ПО рассматривается как единое целое. Когда все находится под управлением версиями, члены группы не пребывают в постоянном неведении и не жонглируют мириадами версий системы ПО. В этих статьях я расскажу также о новой практике управления версиями частей самой конфигурации системы поставки программного обеспечения.

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

Конвейер поставки

Сервер непрерывной интеграции, например, Jenkins, позволяет также настроить конвейер поставки. По сути, конвейер поставки представляет собой процесс, в котором выполняются задания различного типа, основанные на успехе предыдущего задания. В этом конвейере можно организовать различные этапы, включая стадию фиксации, стадию приемки и т.п. Каждый этап опирается на успех предыдущей стадии; такой подход гарантирует уменьшение риска для предварительных выпусков на каждом последовательном этапе вплоть до выпуска системы программного обеспечения в производство. Пример конвейера поставки — как он представлен в системе Jenkins — приведен на рисунке 1.

Рисунок 1. Конвейер поставки, как он представлен в сервере непрерывной интеграции Jenkins
Конвейер поставки, как он представлен в сервере непрерывной интеграции Jenkins Программное обеспечение проходит три отдельных этапа. Сначала выполняется всевозможная настройка с помощью задания SetupVariables после того, как сборка проходит процесс непрерывной интеграции. Затем создается целевая среда с помощью задания CreateTargetEnvironment, и, наконец, на третьем этапе приложение развертывается в целевую среду, как представлено в задании DeployManateeApplication. Эти три этапа работают как единая задача, которая не проходит в случае неудачи любого из заданий.

Информационная панель DevOps

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


Сотрудничество

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

Коллективная ответственность

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

Кроссфункциональные группы

Каждый член кроссфункциональной группы в равной мере отвечает за процесс поставки. Любой человек из группы может изменить любую часть системы программного обеспечения. Это противоположность изолированным группам: когда группы разработки, тестирования и эксплуатации имеют свои собственные сценарии и процессы и не являются частью одной команды.

Кроссфункциональные группы состоят из представителей всех необходимых дисциплин. Вместо того чтобы рассматривать каждую дисциплину как отдельную централизованную обслуживающую организацию, ключевым организационным элементом становится группа поставки. Группы работают вместе целенаправленным образом для согласованной поставки программного обеспечения без неувязок во времени, характерных для групп, взаимодействующих через организацию. В состав каждой группы должны входить (по крайней мере) бизнес-аналитики, представители клиента, администраторы баз данных, разработчики, руководители проектов и инженеры по контролю качества и выпуску. Кроссфункциональная группа ослабляет синдром «это не мое дело», который душит взаимодействие, и многочисленные «барьеры», препятствующие эффективной связи между группами внутри физических площадок и между ними.

Инженеры широкой квалификации

Инженер широкой квалификации ― это член группы, квалифицированный во всех областях процесса поставки программного обеспечения. Разработчики должны понимать, как вносить изменения в базу данных. Администраторы баз данных должны уметь писать функциональные тесты. Руководители проектов должны уметь добавлять сценарии автоматических тестов. В целом же члены команды продолжают выполнять свои функции в соответствии с их ролями. (Например, администраторы баз данных по-прежнему сосредоточены на базах данных.) Однако общие знания значительно понижают коммуникационные барьеры в больших, географически распределенных организациях. К тому же это ограничивает необходимость полагаться на нескольких ключевых лиц для получения программного обеспечения, предлагаемого пользователям.


Инструменты

Инструменты ― важный компонент модели Agile DevOps. Выбор инструментов для проекта зависит от требований, но одна из их важнейших характеристик: любой инструмент должен работать из командной строки. Потому что конвейер должен функционировать в автоматическом режиме, или по одному щелчку кнопки мыши. (Если какой-то унаследованный инструмент не поддерживает работу из командной строки, можно попробовать применить анализатор экранных данных для его запуска в автоматическом режиме, но это ― неидеальное решение, которое часто требует регулярного технического обслуживания.) В таблице 1 приведен список некоторых видов инструментов из типичного набора DevOps; упор делается на типы инструментов, а не на их названия.

Таблица 1. Инструменты, поддерживающие работу DevOps
Тип инструментаИнструменты
Автоматизация инфраструктуры Bcfg2, CFEngine, Chef, CloudFormation, IBM Tivoli, Puppet
Автоматизации развертыванияCapistrano, ControlTier, Func, Glu, RunDeck
Инфраструктура как услугиAmazon Web Services, CloudStack, IBM SmartCloud, OpenStack, Rackspace
Автоматизация сборки Ant, Maven, Rake, Gradle
Автоматизация тестированияJUnit, Selenium, Cucumber, easyb
Управление версиямиSubversion, Git, IBM Rational ClearCase
Непрерывная интеграцияJenkins, CruiseControl, IBM Rational BuildForge

Имейте в виду, что это список носит иллюстративный характер и не является исчерпывающим (более подробный перечень инструментов см. в разделе Ресурсы).


Подробности о поставке программного обеспечения ― впереди

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

Следующая статья познакомит читателя со средствами автоматизации инфраструктуры, которые поддерживают модель среды на основе сценариев. Я расскажу об основных инструментах автоматизации инфраструктуры с открытым исходным кодом: Chef и Puppet.

Ресурсы

Научиться

  • Оригинал статьи: Agile DevOps: The flattening of the software release process.
  • Принципы Agile-манифеста (Agile Manifesto, 2001): принципы манифеста нацелены на частые поставки работающего программного обеспечения.
  • DevOps: статья в Википедии, посвященная методологиям и мотивации движения DevOps.
  • 5 Lessons We've Learned Using AWS (John Ciancutti, The Netflix Tech Blog, декабрь 2010 г.): Chaos Monkey стал одним из первых инструментов, построенных инженерами компании Netflix для поддержки своих облачных систем.
  • Список инструментов для непрерывной поставки: компания Stelligent предоставляет исчерпывающий перечень инструментов для реализации модели непрерывной поставки.
  • DevOps for mobile development (Michael Rowe, developerWorks, июль 2012 г.): о том, как DevOps помогает в решении задач развертывания разных версий приложений для разных устройств.

Получить продукты и технологии

  • Chaos Monkey: первый выпуск программного обеспечения из «обезьяньей армии» компании Netflix.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=860110
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Выравнивание процесса выпуска программного обеспечения
publish-date=03012013