Глава 4. Основные термины и концепции
73
Непрерывная доставка
Методология непрерывной доставки (Continuous Delivery; CD) представляет со- бой набор общих принципов по разработке программного обеспечения, которые позволяют часто создавать новые релизы программного обеспечения с привлече- нием автоматизированного тестирования и непрерывной интеграции. Эта мето- дология тесно связана с непрерывной интеграцией и часто воспринимается как расширение непрерывной интеграции. Это позволяет убедиться в том, что новые изменения могут быть интегрированы без обращения к автоматическим тестам.
В случае непрерывной доставки обеспечивается развертывание изменений.
Непрерывное развертывание
Непрерывное развертывание (Continuous deployment; CD) — это процесс раз- вертывания изменений при разработке путем создания тестов и проверок, позво- ляющих свести риск ошибок к минимуму. В то время как непрерывная доставка позволяет гарантировать развертывание новых изменений, непрерывное развер- тывание означает, что выполняется развертывание изменений в производствен- ном цикле.
Чем быстрее изменения программного обеспечения внедряются в производство, тем быстрее сотрудники увидят результаты своей работы. Благодаря «прозрач- ности» возрастает степень удовлетворенности работой, появляются позитивные эмоции, что, в свою очередь, способствует росту производительности. Также появ- ляются возможности для быстрого обучения. Если в коде функции или в дизайне программы допущена серьезная ошибка, ее легче обнаружить и исправить путем просмотра недавно измененного рабочего контента.
Благодаря непрерывному развертыванию заказчики быстрее получают свои про- дукты, что способствует росту степени удовлетворенности. Конечно, так происходит далеко не всегда. Вряд ли заказчики положительно оценят обновленный продукт, если не была устранена ни одна из ранее возникших проблем. Поэтому с помощью альтер- нативных методов тщательно проверяйте готовый программный продукт на предмет отсутствия ошибок. В условиях непрерывного развертывания ускоряется тестирова- ние разработанных программ, что позволяет командам и организациям разработчиков в случае необходимости ускорять рабочие итерации и изменять код быстрее.
С тех пор как методологии непрерывной доставки и непрерывного развер- тывания завоевали популярность в среде разработчиков, многократно обсу- ждались различия между ними. Джез Хамбл, автор концепции непрерывной доставки, определил эту методологию как общий набор принципов, который может применяться к произвольному проекту разработки ПО, включая Интер- нет вещей (IoT, internet of things) и внедренное программное обеспечение, в то время как непрерывное развертывание относится к веб-приложениям. Чтобы получить больше сведений о различиях между этими двумя концепциями, обратитесь к дополнительным ресурсам.
74
Часть I. Основы devops
Минимально жизнеспособный продукт
В последние годы особенно актуальной стала тема уменьшения затрат, связанных с разработкой ПО, и сокращения отходов производства. Если организация по- тратила годы на продвижение нового продукта на рынке только для того, чтобы понять, что он не удовлетворяет потребности новых или имеющихся заказчиков, это будет напрасная трата времени, энергии и денег.
Минимально жизнеспособный продукт (Minimum Viable Product; MVP) — это про- тотип готового продукта, который можно проверить на соответствие требованиям с приложением минимальных усилий. Создание минимально жизнеспособного продукта целесообразно в тех случаях, когда высока вероятность внесения серьез- ных изменений в готовый продукт. При этом вы сэкономите значительный объем времени и усилий. В минимально жизнеспособном продукте отключены некоторые второстепенные функции или расширенные настройки, которые не нужны для оцен- ки базовых концепций, либо делается упор на функциях, а не на дизайне или про- изводительности. Подобно методологиям бережливой разработки и непрерывной доставки, минимально жизнеспособный продукт позволяет быстрее осуществлять рабочие итерации и улучшать продукт, уменьшая затраты и количество отходов.
Концепции, относящиеся к инфраструктуре
Любая компьютерная программа выполняется на базе какой-либо инфраструк- туры. В качестве подобной инфраструктуры может применяться оборудование, находящееся в собственности организации и управляемое этой же организаци- ей. Либо оборудование может находиться в собственности одной организации, а управляться другой организацией. Могут также выделяться компьютерные ресурсы по требованию, которые при необходимости легко масштабируются.
Концепции, связанные с инфраструктурой, обычно находятся в компетенции инженеров из отдела эксплуатации, но важны для всех, кто имеет отношение к программному продукту и работает в условиях, в которых размываются границы между разработкой программного продукта и его эксплуатацией.
Управление конфигурацией
В 1950-х годах Министерство обороны США в качестве технической дисциплины менеджмента разработало методологию управления конфигурацией (Configuration
Management; CM). Позднее эта методология была принята во многих других об- ластях. Управление конфигурацией — это процесс установления и поддержки согласованности между функциональными и физическими атрибутами, а также управление производительностью на протяжении всего жизненного цикла. Эта методология включает политики, процессы, документацию и инструменты, тре- буемые для реализации согласованной производительности, функциональности и атрибутов.
Глава 4. Основные термины и концепции
75
Различные организации и органы по стандартизации, такие как ITIL, IEEE
(Institute of Electrical and Electronics Engineers, Институт инженеров по элек- тротехнике и электронике), ISO (International Organization for Standardization,
Международная организация по стандартизации) и SEI (Software Engineering
Institute, Институт программной инженерии) предложили стандарт управления конфигурированием, который используется в индустрии разработки программ- ного обеспечения. Как и в случае с другими народными моделями, появление подобного стандарта привело к некоторой путанице с применяемыми ранее опре- делениями.
Зачастую управление конфигурацией сочетается с разными формами автомати- зации инфраструктуры, контроля версий или выделения ресурсов, что приводит к появлению разногласий по поводу применения этого термина в других дисци- плинах. Чтобы выработать общее понимание для читателей книги, определим управлением конфигурированием как процесс идентификации, управления, мо- ниторинга и аудита продукта на протяжении всего его жизненного цикла, вклю- чая процессы, документацию, людей, инструменты, программное обеспечение и системы.
Облачные вычисления
Облачные вычисления, которые часто называют просто «облако», — это совместно выполняемые интернет-вычисления. Заказчики могут приобретать и использовать общие компьютерные ресурсы, предлагаемые разными провайдерами облачных вычислений. Облачные вычисления и хранилища позволят организациям сэконо- мить на приобретении, установке и поддержке своего собственного оборудования.
Сочетание высокой производительности, экономия затрат, а также гибкость и удобство, предлагаемые многими облачными решениями, представляют собой идеальный выбор для организаций, которые хотят минимизировать затраты и уве- личить скорость итераций на этапе разработки. Ускорение итераций и уменьшение времени на цикл разработки являются ключевыми факторами, играющими роль при создании devops-культуры.
В то время как некоторые пользователи представляют облачные вычисления как синоним devops, это не всегда так. Ключевая часть devops — возможность оценивать и анализировать разные инструменты и процессы в целях иденти- фикации средств, которые будут наиболее эффективны для вашей среды. Это вполне возможно сделать даже без перехода к облачной инфраструктуре.
Автоматизация инфраструктуры
Автоматизация инфраструктуры — это способ создания систем, позволяющий уменьшить нагрузку на персонал, связанную с управлением системами и отно- сящимися к ним службами. Благодаря автоматизации повышается качество,
76
Часть I. Основы devops точность и корректность сервиса, предоставляемого заказчикам. Автоматизация в целом представляет собой способ уменьшения количества повторяющихся опе- раций, что позволяет свести к минимуму ошибки и сэкономить время и энергию операторов-людей.
Например, вместо того чтобы выполнять одни и те же командные оболочки вруч- ную на каждом сервере, входящем в инфраструктуру организации, можно вклю- чить эти команды в сценарий оболочки. Этот сценарий можно выполнить отдель- но, за один шаг, вместо выполнения множества мелких шагов.
Управление артефактами
Артефакты создаются в результате выполнения любого этапа в процессе раз- работки программного обеспечения. В зависимости от используемого языка под артефактами могут подразумеваться разные объекты, включая файлы JAR
(архивные файлы Java), WAR (архивные файлы веб-приложений), библиотеки, ресурсы и приложения. Управление артефактами может быть столь же простым, как управление веб-сервером с контролем доступа, обеспечивающим управ- ление файлами вручную. Управление файлами также может быть сложным и предусматривать использование разных расширенных средств. Как и в случае с рассмотренным раньше контролем версий для исходного кода, управление артефактами может выполняться разными способами, с учетом возможностей вашего бюджета.
В общем случае хранилище артефактов может выступать в качестве:
центрального пункта управления бинарными файлами и зависимостями;
настраиваемого прокси-сервера, установленного между организацией и об- щественными хранилищами;
интегрированного хранилища, предназначенного для продвижения разра- ботанного в организации программного обеспечения.
Контейнеры
Одна из самых серьезных болевых точек, которые традиционно возникают при взаимодействии команд разработчиков и поддержки, способ максимально быстрого выполнения изменений, требуемых для эффективной разработки, не рискуя при этом стабильностью производственной среды и инфраструктуры. Относительно новая технология, которая позволит в какой-то степени избавиться от этой болевой точки, заключается в использовании программных контейнеров. Это изолированные структуры, которые могут разрабатываться и развертываться относительно незави- симо от основной операционной системы или оборудования.
Подобно виртуальным машинам, контейнеры обеспечивают помещение кода в «песочницу», который будет выполняться здесь, но, в отличие от виртуальных
Глава 4. Основные термины и концепции
77
машин, при этом уменьшаются накладные расходы и меньше степень зависимости от операционной системы и оборудования. В результате облегчается разработка приложений в контейнерах (в локальной среде) с дальнейшим развертыванием этого контейнера в производстве. При этом минимизируется риск и накладные расходы при разработке, а также уменьшаются усилия при развертывании, требу- емые от инженеров из отдела эксплуатации.
Культурные концепции
Финальные концепции, которые будут определены в этой главе, относятся к куль- туре. В то время как некоторые методологии разработки программного обеспече- ния, например гибкая разработка, определяют основные способы взаимодействия разработчиков ПО, требуются дополнительные способы взаимодействия между людьми и связанные с ними культурные концепции, которые будут рассмотрены как в этой главе, так и в следующих главах книги.
Ретроспектива
Ретроспектива — это обсуждение проекта, которое имеет место после его завер- шения. В частности, анализируется, что было сделано хорошо, а что можно улуч- шить в будущем при выполнении следующих проектов. Ретроспективы обычно происходят на регулярной основе (возможно, и не слишком часто), например ежеквартально либо после завершения проектов. Основная цель ретроспективы заключается в локальном обучении. Обсуждается опыт успехов и неудач проекта, который может применяться в будущих проектах. Стили ретроспективы могут изменяться, но обычно обсуждаются следующие вопросы:
Что произошло?
Каковы были цели проекта и что мы получили после его завершения.
Что было сделано хорошо?
Что было успешного в этом проекте, что в проекте особенно нравится команде разработчиков и что можно использовать в будущих проектах.
Что пошло не так?
Что было сделано неправильно, с какими ошибками пришлось столкнуться, на- сколько были сорваны сроки и чего нужно избегать в будущих проектах.
Постмортем
В отличие от планового регулярного характера ретроспективы постмортем имеет место после какого-то незапланированного инцидента либо сбоя. Обычно это происходит тогда, когда последствия происшедшего события были неожиданными
78
Часть I. Основы devops для участников проекта, а также обнаруживается как минимум один выход из строя системы или сбой в работе организации. В то время как ретроспективы имеют место по завершении проектов и планируются заранее, постмортем произ- носится неожиданно в силу непредсказуемости соответствующего события. Цель постмортема заключается в проведении обучения на уровне организации. При этом можно воспользоваться преимуществами, связанными с системным и после- довательным подходом к постмортему. Не забудьте упомянуть следующие темы:
Что случилось?
Хронология инцидента от начала до конца, часто вместе с журналами обще- ния или системных ошибок.
Опрос
Каждый человек, имеющий отношение к инциденту, высказывает свою точ- ку зрения о происшедших событиях, в том числе о своих мыслях во время событий.
Что нужно исправить?
Что нужно исправить, чтобы улучшить безопасность системы и избежать повторения в будущем подобных инцидентов.
В сообществе devops большое внимание удаляется тому, чтобы во время прове- дения ретроспективы или произнесения постмортема не высказывались упреки.
Конечно, в постмортеме могут содержаться упреки, адресованные виновникам инцидента, но эта политика противоречит акценту на обучение, занимающему центральное место в движении devops.
Безупречность
Концепция безупречности является противоположной культуре, основанной на обвинениях. Несмотря на то что эта концепция обсуждалась уже несколько лет, в основном Сидни Деккером и его сторонниками, настоящую известность она по- лучила после появления поста Джона Оллспоу, посвященного постмортемам, не содержащим упреков (https://codeascraft.com/2012/05/22/blameless-postmortems/).
Суть этого поста заключается в том, что ретроспектива инцидента будет более эффективной в случае акцента на обучении, а не на наказании.
Культура безупречности направлена не на то, чтобы дать людям возможность уйти от ответственности, а на то, чтобы люди чувствовали себя комфортно при обсужде- нии подробностей происшедшего инцидента, даже если они являются виновника- ми этого происшествия. Обучение будет успешным только после осознания всех деталей происшедшего события.