Текст книги "Философия DevOps. Искусство управления IT"

Развитие методологий разработки программного обеспечения

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

В 2004 году программист Алистер Кокберн, являющийся одним из соавторов манифеста гибкого программирования (Agile Manifesto), описал методологию разработки ПО Crystal Clear[7]7
  Alistair Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams (Boston: Addison Wesley, 2004).


[Закрыть]. Эта методология основана на десятилетнем опыте изучения успешных команд и предназначена для небольших групп разработчиков. Алистер описал три основных метода, используемых в Crystal Clear:

• Быстрая доставка полезного кода, переход от больших и редких развертываний кода к меньшим и более частым развертываниям.

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

• Осмотическая коммуникация, осуществляемая между разработчиками. Если разработчики находятся в одной комнате, информация воспринимается ими неформально, как фоновый шум. Этот процесс напоминает явление осмоса.

Эта методология развивалась несколько лет, приобретая все большее влияние. В этот период времени системный администратор Марсель Вегерманн написал эссе, посвященное использованию принципов разработки программного обеспечения Crystal Clear, Scrum и Agile в области системного администрирования. В дополнение к блиц-докладу по теме, в котором были предложены такие идеи, как контроль версий для каталога /etc операционной системы Linux, парное администрирование системы и операционные ретроспективы, в 2008 году Марсель также создал список рассылки Agile System Administration.

Приложения с открытым исходным кодом и собственные услуги

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

В 2006 году компания электронной коммерции Amazon.com, Inc., которая ранее была известна своим сайтом по продаже книг и других товаров, предназначенных для широкого круга потребителей, запустила два сервиса: Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (S3). Эти сервисы представляли собой первую попытку реализации виртуальных компьютерных экземпляров и виртуального хранилища с помощью собственной службы. В результате пользователи получили доступ к вычислительным ресурсам без предварительных инвестиций в оборудование. Также можно было запрашивать дополнительные ресурсы по мере необходимости. Как и в случае появления компьютеров из семейства System/360, этот сервис был быстро принят пользователями, став стандартом «де факто» благодаря простоте использования, невысоким начальным затратам и гибкости.

По мере роста и развития веб-технологий появлялись новые способы коммуникации и сотрудничества в Интернете. В 2006 году появился онлайновый сетевой сервис Твиттер. Изначально этот сервис применялся пользователями, которые хотели делиться информацией, представленной в сокращенном формате. Эта информация использовалась в качестве средства привлечения внимания как простыми пользователями, так и знаменитостями. Но в 2007-м популярность Твиттера буквально взлетела до небес благодаря конференции South by Southwest Interactive (SXSW). Эта конференция транслировалась в режиме реального времени с помощью твитов на экранах, установленных в холлах.

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

Гибкая инфраструктура

На конференции Agile 2008, проходящей в Торонто, системный администратор и ИТ-консультант Патрик Дебуа в своем докладе «Agile Operations and Infrastructure: How Infra-gile are You?» рассказывал о включении методологии Scrum в эксплуатационную работу. Патрик работал с командами по разработке и эксплуатации над проектом по тестированию передачи информации в центр обработки данных. И он предпочитал один день работать в команде разработчиков, а на следующий день – в эксплуатационной команде. Если же переключаться между выполнением двух задач в течение одного дня, теряется примерно 20 % от обычной производительности[8]8
  Gerald Weinberg, Quality Management: Systems Thinking (New York: Dorset House Publishing Company, 1997).


[Закрыть].

На этой же конференции бывший программист Эндрю Клэй Шафер, который начал проявлять большой интерес к связанным с ИТ проблемам, предложил провести сеанс гибкой инфраструктуры (Agile Infrastructure). Эндрю почему-то считал, что предложенная им тема никого не заинтересует, поэтому пропустил собственноручно объявленный сеанс. Когда Патрик увидел это, он понял, что кроме него есть другие люди, интересующиеся гибким системным администрированием. После этого Патрик связался с Эндрю и предложил ему подробнее обсудить данную концепцию.

Отдельные компании начали не только добиваться больших успехов во внедрении процессов, позволивших им идти в ногу с постоянно ускоряющимися изменениями Интернета, но и делиться своим опытом в сообществах. Эти сообщества формировались вокруг таких популярных конференций, как O’Reilly Velocity Conference (http://conferences.oreilly.com/velocity).

Одной из таких компаний является Flickr, популярное интернет-сообщество фотографов. После приобретения компанией Yahoo в 2005 году Flickr потребовалось переместить все сервисы и данные из Канады в США. Джон Оллспоу, энтузиаст в области эксплуатации веб-приложений с многолетним опытом работы по техобслуживанию систем, присоединился к компании Flickr в качестве ведущего инженера по эксплуатации. Его цель заключалась в оказании помощи при масштабировании нового проекта по миграции данных. В 2007 году к группе разработчиков Flickr присоединился Пол Хэммонд. В 2008 году Пол стал техническим директором Flickr, возглавив отдел разработки ПО вместе с Оллспоу.

На конференции Velocity Santa Clara 2009 Хэммонд и Оллспоу совместно представили доклад «10+ Deploys per Day: Dev and Ops Cooperation at Flickr». В этом докладе они описали революционные изменения, которые позволят команде быстро продвигаться вперед. Они не предлагали ломать барьеры между сотрудниками либо формировать большое профессиональное и культурное движение. Они просто делились своим опытом совместной работы в Flickr, который серьезно отличался от опыта предыдущей работы Оллспоу в компании Friendster, где брали верх эмоции и моральное давление, а сотрудничество между членами команды практически отсутствовало.

Не произносите фразы типа «технология devops успешно внедрена», поскольку «выполняется до 10 развертываний в день». Обращайте внимание на конкретные проблемы, которые вы пытаетесь решить в своей организации, а не на показатели, относящиеся к другим организациям. Подумайте о том, почему выполняются определенные изменения, а не просто о количестве развертываний или о других произвольных метриках.

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

Конференции devopsdays

Не ограничивайтесь простым «нет», относитесь уважительно к проблемам других людей… #velocityconf #devops #workingtogether

– Эндрю Клэй Шафер (@littleidea)

Этот твит, созданный 23 июня 2009 года Эндрю Клэй Шафером, побудил Патрика Дебуа пожаловаться в Твиттере на то, что он не сможет посетить лично ежегодную конференцию Velocity. Прис Нэсрат, который в то время выполнял обязанности ведущего системного интегратора в Guardian, отправил ответное сообщение в Твиттере. В этом сообщении он спросил о том, почему бы не организовать собственную конференцию Velocity в Бельгии. Вдохновленный этими словами Патрик поступил практически в полном соответствии с данным советом. Он организовал локальную конференцию, на которой разработчики, системные администраторы, системные программисты и другие специалисты, работающие в этой области, могли обмениваться информацией. В октябре этого же года в Генте прошла первая конференция devopsdays. Двумя неделями позже Дебуа писал следующее:

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

Первая конференция devopsdays воспламенила пороховую бочку с неудовлетворенными потребностями людей, изолированных друг от друга. Эти люди испытывали разочарование в связи со статусом-кво, отождествляемым с devops, и способом описания работы, которую, по их мнению, они уже выполняют. По мере того как отдельные энтузиасты организовывали локальные конференции в новых уголках мира, росли масштабы и количество участвующих в этих конференциях людей. Благодаря возможности коммуникаций в режиме реального времени с помощью Твиттера потенциал роста этих конференций практически безграничен, а хэштег #devops просто обречен на популярность.

Текущее состояние devops

За шесть лет, прошедших с момента проведения первых devopsdays в Бельгии (под руководством Патрика Дебуа), движения devops ушло далеко вперед. В отчете «2015 State of Devops Report» (https://puppet.com/resources/white-paper/2015-state-devops-report), опубликованном компанией Puppet, отмечается, что компании, использующие devops, имеют лучшие показатели, чем компании, которые не применяют devops. На убедительном языке цифр продемонстрированы факты, о которых многие люди догадывались на интуитивном уровне. Отдельные сотрудники и команды, которые эффективно сотрудничают друг с другом, работают лучше, чем группа сотрудников, находящихся в одной комнате и не умеющих работать вместе. Высокоэффективные devops-организации чаще развертывают код, реже допускают ошибки, быстрее восстанавливаются после сбоев, а сотрудники этих организаций – более счастливые люди.

Количество конференций devopsdays выросло с одной в 2009 году до двадцати двух в 2015 году (во всем мире). Каждый год знаменуется новыми событиями devopsdays, проходящими в разных городах и странах. Эти конференции не связаны с такими центрами развития технологий, как Силиконовая долина или Нью-Йорк. Существуют десятки локальных групп, объединяющих в своих рядах тысячи членов, которые буквально разбросаны по всему земному шару, не говоря уже о множестве бесед на эту тему, происходящих ежедневно в Твиттере.

Выводы

Размышляя о нашей истории, мы видим склонность к концентрации на результатах, а не на людях и процессах. Многие вещи были позаимствованы из презентации Джона Оллспоу и Пола Хэммонда «10+ Deploys a Day», в которой подчеркивается, что важно развертывать более 10 программ в день. Ну а подзаголовок «Dev & Ops Cooperation at Flickr» многие просто не замечали.

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

Сосредоточение на культуре и процессах способствует итеративному улучшению способов производства и качества производимого продукта. Благодаря переключению внимания от «что» к «как» предоставляются свобода и доверие, необходимые для достижения цели и смысла работы. Именно это является ключевым компонентом удовлетворенности от проделанной работы. Наличие обратной связи с рабочими процессами позитивно влияет на результат даже без концентрации на достижении определенных показателей. Счастливые и продуктивные люди смогут создать условия для скачка в развитии всего человечества.

Благодаря внедрению devops изменился способ производства. Произошло переключение внимания на людей и процессы, начали поощряться сотрудничество и кооперация, исчезла конкуренция среди специалистов.

Глава 4. Основные термины и концепции

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

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

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

Методологии, применяемые при разработке программного обеспечения

Процесс разбиения деятельности по разработке ПО на отдельные фазы называется методологией разработки программного обеспечения.

Обычно выделяются следующие фазы:

• спецификация конечных результатов работы или артефактов;

• разработка и верификация кода в соответствии со спецификацией;

• развертывание кода в финальной потребительской или производственной среде.

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

Каскад

Каскадная методология (или модель) представляет собой процесс управления проектом, в котором выделяется последовательная прогрессия от одной стадии процесса до другой. Изначально эта методология использовалась в обрабатывающей и строительной промышленности, позднее в аппаратной инженерии, ну а для разработки программного обеспечения начала применяться в первой половине 1980-х годов[9]9
  Herbert D. Benington, Production of Large Computer Programs. IEEE Annals of the History of Computing, October 1, 1983, http://bit.ly/benington-production.


[Закрыть].

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

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

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

Рис. 4.1. Каскадная модель

Гибкая методология разработки ПО

Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легкими» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.

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

• отдельных людей и взаимодействий выше ценности процессов и инструментов;

• рабочей документации выше ценности исчерпывающей документации;

• сотрудничества с заказчиками выше ценности переговоров, проводимых в процессе заключения контракта;

• реагирования на изменение ситуации выше ценности точного следования плану.

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

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

ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?

Методология devops имеет много общего с гибкими методиками разработки программного обеспечения, особенно если учитывать фокус на отдельных людях, взаимодействиях и сотрудничестве. В связи с этим у вас, наверное, уже возник вопрос о том, не является ли devops просто «ребрендингом» гибких методик. Несомненно, методология devops сформировалась на основе гибких методик, но все же она является самостоятельным культурным движением. Это движение связано с историей компьютерной индустрии и включает гораздо больше, чем разработчики программ. Движение devops адаптирует и расширяет принципы гибкой разработки программ и применяет их на уровне организации в целом, а не только в процессе разработки программ. Как будет подробно показано в следующих главах, devops приводит к культурным последствиям, выходящим за пределы области гибкой разработки. Изменения, вызванные внедрением devops, гораздо шире, чем банальное увеличение скорости доставки новых версий программ.

Scrum

В середине 1990-х годов Кен Швабер и доктор Джефф Сазерленд, принимавшие участие в создании Agile-манифеста, объединили усилия с целью формирования нового процесса создания программного обеспечения под названием Scrum. В методологии Scrum основной упор делается на максимизации способностей команды разработчиков к быстрому реагированию на изменение требований к самому проекту и со стороны заказчиков. При этом используются предопределенные циклы разработки, называемые спринты. Обычно длина циклов варьируется от одной недели до одного месяца. Процесс разработки ПО начинается с совещания по планированию спринтов, на котором определяются цели, выполняется обзор спринтов и производится ретроспектива спринтов. Это нужно для оценки степени выполнения спринтов и каких-либо проблем, которые могут возникнуть в процессе выполнения спринта.

Одна из ключевых особенностей методологии Scrum – проведение ежедневных Scrum-встреч либо ежедневных собраний, на которых члены команды как можно быстрее дают ответы на следующие три вопроса:

• Что из того, что я сделал, помогло команде достичь целей спринта?

• Что я планирую сделать сегодня, чтобы помочь команде достичь этих целей?

• Что делать в том случае, когда какое-либо препятствие мешает мне или команде достичь целей?

На ежедневных встречах, проходящих по утрам, scrum-мастер помогает сотрудникам с повесткой дня, а также способствует устранению проблем. Роль scrum-мастера включает такие обязанности, как оказание помощи команде в самоорганизации, координирование усилий, прилагаемых в процессе работы, устранение препятствий в работе. В результате команда будет продолжать добиваться успеха, а также привлекать владельцев проекта и заинтересованные стороны. В результате вырабатывается общее понимание того, что означает «сделано», и критериев оценки прогресса. Принципы Scrum часто неформально применяются во многих современных методологиях разработки программного обеспечения.

Методологии эксплуатации

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

ITIL

Методология ITIL, ранее известная как Information Technology Infrastructure Library (Библиотека инфраструктуры информационных технологий), представляет собой набор методов, предназначенных для управления ИТ-услугами. Эта методология изложена в пяти книгах. В этих книгах описываются способы осуществления процессов, процедур и задач, а также составления контрольных списков, необходимых при эксплуатации. Эта методология позволяет установить соответствие разработанных программ сформулированным критериям, а также оценить прогресс на пути к достижению целей. Методология ITIL сформировалась на основе практических методик, применявшихся в 1980-х годах во многих ИТ-организациях.

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

ИТ-аналитик и консультант Стивен Манн отмечает, что наряду со многими преимуществами, которые дает ITIL-стандартизация и наличие более 1,5 млн ITIL-сертифицированных специалистов во всем мире, существуют и проблемы. Одна из основных проблем – недостаточное внимание к отдельным практическим областям. Согласно утверждению Манна, методология ITIL чаще является реактивной, а не проактивной, поэтому организациям, использующим ITIL, рекомендуется уделить больше внимания проактивному планированию и заказчикам.

COBIT

Методология COBIT (Control Objectives for Information and Related Technology; Задачи управления для информационных и смежных технологий) представляет собой каркас ISACA, предназначенный для управления информацией и технологиями. Эта методология была впервые обнародована в 1996 году. Основной принцип COBIT заключается в согласовании бизнес-целей с ИТ-целями.

Методология COBIT основана на следующих пяти принципах:

• удовлетворение нужд заинтересованных сторон;

• полный охват предприятия;

• применение простого интегрированного каркаса;

• обеспечение целостного подхода;

• отделение управления от менеджмента.

Системные методологии

Некоторые методики сосредоточиваются на системах в целом, а не на более конкретных областях, таких как разработка программного обеспечения либо техобслуживание компьютеров. Навыки системного мышления критически важны для тех, кто работает со сложными системами, такими как многие современные программы. Читателям, желающим получить представление о системном мышлении в целом, рекомендуется обратиться к книгам Thinking in Systems (Donella Meadows) и How Complex Systems Fail (Dr. Richard Cook).

Бережливость

По итогам пятилетнего изучения тенденций в развитии автомобильной промышленности и производственной системы «Тойоты» (TPS) Джеймс П. Вомак, Дэниел Т. Джонс и Дэниел Рус ввели термин «бережливое производство»[10]10
  James P. Womack, Daniel T. Jones, and Daniel Roos, Machine Changed the World (New York: Raw.son Associates, 1990).


[Закрыть]. Вомак и Джонс выработали следующие пять принципов бережливого мышления[11]11
  James P. Womack and Daniel T. Jones, Lean Thinking (New York: Simon & Schuster, 1996).


[Закрыть]:

• ценность;

• процесс создания ценности;

• поток;

• вытягивание;

• совершенствование.

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

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

В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:

• невостребованные функции программного обеспечения;

• задержки при общении;

• замедленный отклик приложения;

• бюрократические процессы.

Отходы в контексте бережливости противоположны ценностям. Мэри Поппендик и Томас Поппендик сопоставили отходы бережливого производства с отходами производства программного обеспечения. В результате появился следующий список[12]12
  Mary Poppendieck and Thomas David Poppendieck. Implementing Lean Software Development (Upper Saddle River, NJ: Addison-Wesley, 2007).


[Закрыть]:

• частично выполненная работа;

• дополнительные возможности;

• переучивание;

• ненужные передачи обслуживания;

• переключение между задачами;

• задержки;

• дефекты.

Как и в случае с devops, не существует единственно верного способа внедрения бережливой разработки программного обеспечения. В процессе бережливой разработки ПО применяются два основных подхода: фокус на устранении отходов с помощью набора инструментов и улучшение рабочего потока, также известное под названием «путь Тойоты»[13]13
  Jeffrey K. Liker, Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer (New York: McGraw-Hill, 2004).


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

Концепции разработки, релиза и развертывания ПО

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

Контроль версий

Система контроля версий фиксирует изменения файлов или наборов файлов, которые хранятся в системе. Это могут быть файлы исходного кода, ресурсы и другие документы, которые являются частью процесса разработки программного обеспечения. Разработчики вносят изменения в форме пакетов, называемых фиксациями, или ревизиями. Каждая ревизия, наравне с метаданными, такими как «кто внес изменения и когда», «хранится в системе в той или иной форме», находится в системе в каком-либо виде.

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

Разработка через тестирование

При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемого для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантируется безупречная работа новых функций, а также становится более очевидным назначение кода.

Если разработчики сами разрабатывают тесты, циклы обратной связи существенно сокращаются. К тому же разработчики принимают на себя больше ответственности за создание качественного кода. Подобное разделение ответственности и уменьшение времени, выделяемого на цикл разработки программного обеспечения, и в наши дни продолжают оставаться важными компонентами devops-культуры.

Развертывание приложений

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