Файл: Дэвис Дженнифер, Дэниелс КэтринД94 Философия DevOps. Искусство управления it. Спб. Питер, 2017. 416 с. ил. Серия Бестселлеры OReilly.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 371
Скачиваний: 25
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
ГЛАВА 4
Основные термины и концепции
Чтобы создать прочный фундамент, необходимый для внедрения эффективных devops-методов, следует обсудить некоторые ключевые термины и понятия. Неко- торые из этих концепций могут быть знакомы читателям, многие были упомянуты в контексте истории программной инженерии либо хорошо известны читателям, имеющим опыт работы с различными методологиями разработки программного обеспечения.
На протяжении всей истории вычислительной техники был описан ряд методо- логий, применяемых для улучшения и облегчения разработки или эксплуатации программного обеспечения. В каждой методологии предусматривается разби- ение работы на фазы, каждая из которых представляет собой отдельный набор действий. Для многих методологий типично отделение процесса разработки от эксплуатации, что приводит к конфликту целей у разных команд. Помимо этого, если вынуждать членов других команд следовать тем или иным методологиям, не соответствующим используемым в этих командах процессам и идеям, это может привести к недовольству и разочарованию. Знание особенностей и преимуществ разных методологий поможет улучшить понимание сути возникающих проблем и уменьшит трение между членами команды.
Методы devops определены не столь жестко, как методологии, основанные на запретах. Изначально идеи devops появились среди практиков, которые были приверженцами гибкого системного администрирования и кооперации между командами разработчиков и эксплуатации. Подробности применяемой при этом практики зависели от среды. На страницах этой книги вы неоднократно встретитесь с утверждением о том, что ключевой частью devops является возможность оценивать и анализировать различные инструменты и процессы с целью найти наиболее эффективные среди них.
Глава 4. Основные термины и концепции
65
Методологии, применяемые при разработке
программного обеспечения
Процесс разбиения деятельности по разработке ПО на отдельные фазы называется
методологией разработки программного обеспечения.
Обычно выделяются следующие фазы:
спецификация конечных результатов работы или артефактов;
разработка и верификация кода в соответствии со спецификацией;
развертывание кода в финальной потребительской или производственной среде.
Рассмотрение абсолютно всех методологий, применяемых при разработке про- граммного обеспечения, выходит за рамки этой главы, поэтому коснемся лишь тех из них, которые в какой-то степени связаны с devops.
Каскад
Каскадная методология (или модель) представляет собой процесс управления про- ектом, в котором выделяется последовательная прогрессия от одной стадии процесса до другой. Изначально эта методология использовалась в обрабатывающей и стро- ительной промышленности, позднее в аппаратной инженерии, ну а для разработки программного обеспечения начала применяться в первой половине 1980-х годов
1
Изначально стадии каскадной модели назывались следующим образом: специ- фикация требований, проектирование, внедрение, интеграция, тестирование, установка и техническое обслуживание. Эти этапы показаны на рис. 4.1 (в форме диаграммы).
Разработка программного обеспечения, осуществляемая в соответствии с каскад- ной моделью, является в высшей степени структурированной. Много времени тратится на этапах спецификации требований и проектирования, что позволяет сократить количество ошибок, допускаемых на следующих этапах.
Во времена активного использования каскадной модели имела место высокая стоимость доставки программного обеспечения, распространяемого на компакт- дисках или на дискетах. К тому же еще приходилось учитывать стоимость ручной установки программ, выполняемой на рабочем месте заказчика. В случае необ- ходимости устранения ошибок нужно было записывать и распространять новые дискеты или компакт-диски. Из-за подобных расходов было целесообразнее по- тратить больше времени и сил на стадии спецификации требований, чем пытаться устранять ошибки на следующих стадиях.
1
Herbert D. Benington, Production of Large Computer Programs. IEEE Annals of the History of
Computing, October 1, 1983, http://bit.ly/benington-production.
66
Часть I. Основы devops
Рис. 4.1. Каскадная модель
Гибкая методология разработки ПО
Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легки- ми» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.
Мы выявляем более эффективные способы разработки программного обеспечения, а также помогаем это делать другим. В процессе выполне- ния этой работы мы пришли к выводам о том, что ценность:
• отдельных людей и взаимодействий выше ценности процессов и ин- струментов;
• рабочей документации выше ценности исчерпывающей документации;
• сотрудничества с заказчиками выше ценности переговоров, проводи- мых в процессе заключения контракта;
• реагирования на изменение ситуации выше ценности точного следо- вания плану.
Как видите, компоненты, находящиеся в левой части списка, оценивают- ся выше компонентов, расположенных в правой части списка.
Глава 4. Основные термины и концепции
67
К гибким методологиям относится Scrum, которая будет рассмотрена в одном из следующих разделов, и другие методы, при использовании которых во главу угла ставится сотрудничество, гибкость и конечный результат в виде работоспособного программного обеспечения.
ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?
Методология devops имеет много общего с гибкими методиками разработки программного обеспечения, особенно если учитывать фокус на отдельных людях, взаимодействиях и сотрудничестве. В связи с этим у вас, наверное, уже возник вопрос о том, не является ли devops просто «ребрендингом» гибких методик. Несомненно, методология devops сформировалась на основе гибких методик, но все же она является самостоятельным культурным движением. Это движение связано с историей компьютерной индустрии и включает гораздо больше, чем разработчики программ. Движение devops адаптирует и рас- ширяет принципы гибкой разработки программ и применяет их на уровне организации в целом, а не только в процессе разработки программ. Как будет подробно показано в следующих главах, devops приводит к культурным по- следствиям, выходящим за пределы области гибкой разработки. Изменения, вызванные внедрением devops, гораздо шире, чем банальное увеличение скорости доставки новых версий программ.
Scrum
В середине 1990-х годов Кен Швабер и доктор Джефф Сазерленд, принимавшие участие в создании Agile-манифеста, объединили усилия с целью формирования нового процесса создания программного обеспечения под названием Scrum. В ме- тодологии Scrum основной упор делается на максимизации способностей ко манды разработчиков к быстрому реагированию на изменение требований к самому проекту и со стороны заказчиков. При этом используются предопределенные циклы разработки, называемые спринты. Обычно длина циклов варьируется от одной недели до одного месяца. Процесс разработки ПО начинается с совещания по планированию спринтов, на котором определяются цели, выполняется обзор спринтов и производится ретроспектива спринтов. Это нужно для оценки степени выполнения спринтов и каких-либо проблем, которые могут возникнуть в процес- се выполнения спринта.
Одна из ключевых особенностей методологии Scrum — проведение ежедневных
Scrum-встреч либо ежедневных собраний, на которых члены команды как можно быстрее дают ответы на следующие три вопроса:
Что из того, что я сделал, помогло команде достичь целей спринта?
Что я планирую сделать сегодня, чтобы помочь команде достичь этих целей?
Что делать в том случае, когда какое-либо препятствие мешает мне или команде достичь целей?
68
Часть I. Основы devops
На ежедневных встречах, проходящих по утрам, scrum-мастер помогает сотруд- никам с повесткой дня, а также способствует устранению проблем. Роль scrum- мастера включает такие обязанности, как оказание помощи команде в самоорга- низации, координирование усилий, прилагаемых в процессе работы, устранение препятствий в работе. В результате команда будет продолжать добиваться успеха, а также привлекать владельцев проекта и заинтересованные стороны. В резуль- тате вырабатывается общее понимание того, что означает «сделано», и критериев оценки прогресса. Принципы Scrum часто неформально применяются во многих современных методологиях разработки программного обеспечения.
Методологии эксплуатации
Подобно тому как в методологиях разработки программного обеспечения пре- дусмотрено разбиение работы на отдельные стадии, можно также разделить на отдельные операции или иным образом организовать процесс эксплуатации. Как и в случае с методологиями, применяемыми для разработки ПО, рассмотрение всех методологий эксплуатации выходит за рамки этой книги.
ITIL
Методология ITIL, ранее известная как Information Technology Infrastructure Library
(Библиотека инфраструктуры информационных технологий), представляет собой набор методов, предназначенных для управления ИТ-услугами. Эта методология изложена в пяти книгах. В этих книгах описываются способы осуществления про- цессов, процедур и задач, а также составления контрольных списков, необходимых при эксплуатации. Эта методология позволяет установить соответствие разрабо- танных программ сформулированным критериям, а также оценить прогресс на пути к достижению целей. Методология ITIL сформировалась на основе практических методик, применявшихся в 1980-х годах во многих ИТ-организациях.
Британское центральное компьютерное и телекоммуникационное агентство разра- ботало набор рекомендаций по стандартизации этих практических методик. Первая публикация методологии ITIL имела место в 1989 году, а последняя — в 2011 году.
За это время она эволюционировала с пяти основных разделов до многотомного собрания и теперь включает описание стратегии техобслуживания, проектирования услуг, перехода к услугам, выполнения услуг и непрерывного улучшения услуг.
ИТ-аналитик и консультант Стивен Манн отмечает, что наряду со многими преи- муществами, которые дает ITIL-стандартизация и наличие более 1,5 млн ITIL-сер- тифицированных специалистов во всем мире, существуют и проблемы. Одна из ос- новных проблем — недостаточное внимание к отдельным практическим областям.
Согласно утверждению Манна, методология ITIL чаще является реактивной, а не проактивной, поэтому организациям, использующим ITIL, рекомендуется уделить больше внимания проактивному планированию и заказчикам.
Глава 4. Основные термины и концепции
69
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) Джеймс П. Вомак, Дэниел
Т. Джонс и Дэниел Рус ввели термин «бережливое производство»
1
. Вомак и Джонс выработали следующие пять принципов бережливого мышления
2
:
ценность;
процесс создания ценности;
поток;
вытягивание;
совершенствование.
1
James P. Womack, Daniel T. Jones, and Daniel Roos, Machine Changed the World (New York: Raw.
son Associates, 1990).
2
James P. Womack and Daniel T. Jones, Lean Thinking (New York: Simon & Schuster, 1996).
70
Часть I. Основы devops
Эти идеи, в частности стремление к совершенству с помощью системной иден- тификации и утилизации отходов, привели к появлению термина бережливость, олицетворяющего максимизацию ценности заказчиков и минимизацию отходов.
Бережливые системы сконцентрированы на компонентах, ценность которых возрастает за счет повсеместного устранения отходов, будь то перепроизводство некоторых частей и бракованных товаров, которые должны быть восстановлены, либо время, потраченное на ожидание появления других компонентов системы.
В результате развития этих систем возникли концепции бережливых ИТ-техно- логий и бережливой разработки программного обеспечения. В рамках этих кон- цепций одни и те же понятия используются в процессах разработки программного обеспечения и оказания ИТ-услуг.
В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:
невостребованные функции программного обеспечения;
задержки при общении;
замедленный отклик приложения;
бюрократические процессы.
Отходы в контексте бережливости противоположны ценностям. Мэри Поппендик и Томас Поппендик сопоставили отходы бережливого производства с отходами про- изводства программного обеспечения. В результате появился следующий список
1
:
частично выполненная работа;
дополнительные возможности;
переучивание;
ненужные передачи обслуживания;
переключение между задачами;
задержки;
дефекты.
Как и в случае с devops, не существует единственно верного способа внедрения бережливой разработки программного обеспечения. В процессе бережливой раз- работки ПО применяются два основных подхода: фокус на устранении отходов с помощью набора инструментов и улучшение рабочего потока, также известное под названием «путь Тойоты»
2
. Оба подхода направлены на достижение одной и той же цели, но в силу их различий могут приводить к разным результатам.
1
Mary Poppendieck and Thomas David Poppendieck. Implementing Lean Software Development
(Upper Saddle River, NJ: Addison-Wesley, 2007).
2
Jeffrey K. Liker, Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer (New
York: McGraw-Hill, 2004).
Глава 4. Основные термины и концепции
71
Концепции разработки,
релиза и развертывания ПО
При рассмотрении разработки, релиза и развертывания программного обеспече- ния следует упомянуть еще несколько концепций, которые ранее не рассматрива- лись в этой главе. Эти концепции описывают порядок разработки и развертывания программного обеспечения и дают представление о степени связи между ними.
После ознакомления с этими концепциями у читателя выработается более зрелое понимание способов использования инструментов, облегчающих применение требуемых практик.
Контроль версий
Система контроля версий фиксирует изменения файлов или наборов файлов, которые хранятся в системе. Это могут быть файлы исходного кода, ресурсы и другие документы, которые являются частью процесса разработки программного обеспечения. Разработчики вносят изменения в форме пакетов, называемых фик-
сациями, или ревизиями. Каждая ревизия, наравне с метаданными, такими как «кто внес изменения и когда», «хранится в системе в той или иной форме», находится в системе в каком-либо виде.
При наличии возможностей по фиксации, сравнению, выполнению слияния и вос- становлению прежних ревизий объектов в хранилище можно организовать расши- ренную кооперацию и сотрудничество внутри команды и между командами. Это сводит к минимуму возможные риски, поскольку появляется способ вернуться к предыдущим версиям объектов.
Разработка через тестирование
При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемо- го для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантиру- ется безупречная работа новых функций, а также становится более очевидным назначение кода.
Если разработчики сами разрабатывают тесты, циклы обратной связи сущест- венно сокращаются. К тому же разработчики принимают на себя больше ответ- ственности за создание качественного кода. Подобное разделение ответствен- ности и уменьшение времени, выделяемого на цикл разработки программного обеспечения, и в наши дни продолжают оставаться важными компонентами devops-культуры.
72
Часть I. Основы devops
Развертывание приложений
Развертывание приложений представляет собой процесс планирования, техниче- ского обслуживания и доставки релизов программного обеспечения. В общем слу- чае при развертывании приложений следует учитывать изменения, которые имеют место на уровне, находящемся ниже уровня системы. При наличии автоматизации инфраструктуры построения зависимостей, используемых для выполнения кон- кретного приложения, будь то вычислительная программа, операционная система или другие зависимости, минимизируется влияние возможных несоответствий на выпущенное программное обеспечение.
В зависимости от типа приложения могут проявляться разные инженерные про- блемы. Например, для баз данных могут понадобиться гарантии обеспечения совместимости. Выполняемые в базах данных транзакции отражаются на данных.
Развертывание приложений является критическим аспектом, обеспечивающим качество программной инженерии.
Непрерывная интеграция
Непрерывная интеграция (Continuous Integration; CI) — это процесс интегри- рования нового кода, написанного разработчиками, в основной код или ветку
«мастер», осуществляемый в течение рабочего дня. Этот подход отличается от методики, в соответствии с которой разработчики работают с независимыми вет- ками неделями или месяцами, выполняя слияние кода в основную ветку только после полного завершения работы над проектом. Длительные периоды времени между слияниями приводят к тому, что в код вносится очень много изменений, что повышает вероятность появления ошибок. При работе с большими пакетами изме- нений гораздо труднее изолировать и идентифицировать фрагмент кода, который вызвал сбой. Если же используются небольшие наборы изменений, для которых часто выполняется слияние, поиск ошибок значительно упрощается. Постарайтесь избежать проблем, связанных с интеграцией, которые неизбежно появятся при слиянии больших наборов изменений.
В системах непрерывной интеграции после завершения слияния новых изменений обычно автоматически выполняется набор тестов. Эти тесты выполняются после фиксации изменений и завершения слияний. Это позволяет избежать накладных расходов, связанных с использованием ручного труда тестеров. Чем больше на- кладных расходов требует выполняемое действие, тем меньше вероятность, что оно будет выполнено, особенно в случае нехватки времени. Результаты выпол- нения этих тестов часто визуализируются. Если результаты выделены зеленым цветом, значит, тест завершился успешно, а только что интегрированный про- граммный релиз не содержит ошибок. Провальные или «красные» тесты означают, что релиз содержит ошибки и должен быть исправлен. Благодаря использованию этого рабочего потока идентификация и устранение проблем осуществляются намного быстрее.
Основные термины и концепции
Чтобы создать прочный фундамент, необходимый для внедрения эффективных devops-методов, следует обсудить некоторые ключевые термины и понятия. Неко- торые из этих концепций могут быть знакомы читателям, многие были упомянуты в контексте истории программной инженерии либо хорошо известны читателям, имеющим опыт работы с различными методологиями разработки программного обеспечения.
На протяжении всей истории вычислительной техники был описан ряд методо- логий, применяемых для улучшения и облегчения разработки или эксплуатации программного обеспечения. В каждой методологии предусматривается разби- ение работы на фазы, каждая из которых представляет собой отдельный набор действий. Для многих методологий типично отделение процесса разработки от эксплуатации, что приводит к конфликту целей у разных команд. Помимо этого, если вынуждать членов других команд следовать тем или иным методологиям, не соответствующим используемым в этих командах процессам и идеям, это может привести к недовольству и разочарованию. Знание особенностей и преимуществ разных методологий поможет улучшить понимание сути возникающих проблем и уменьшит трение между членами команды.
Методы devops определены не столь жестко, как методологии, основанные на запретах. Изначально идеи devops появились среди практиков, которые были приверженцами гибкого системного администрирования и кооперации между командами разработчиков и эксплуатации. Подробности применяемой при этом практики зависели от среды. На страницах этой книги вы неоднократно встретитесь с утверждением о том, что ключевой частью devops является возможность оценивать и анализировать различные инструменты и процессы с целью найти наиболее эффективные среди них.
Глава 4. Основные термины и концепции
65
Методологии, применяемые при разработке
программного обеспечения
Процесс разбиения деятельности по разработке ПО на отдельные фазы называется
методологией разработки программного обеспечения.
Обычно выделяются следующие фазы:
спецификация конечных результатов работы или артефактов;
разработка и верификация кода в соответствии со спецификацией;
развертывание кода в финальной потребительской или производственной среде.
Рассмотрение абсолютно всех методологий, применяемых при разработке про- граммного обеспечения, выходит за рамки этой главы, поэтому коснемся лишь тех из них, которые в какой-то степени связаны с devops.
Каскад
Каскадная методология (или модель) представляет собой процесс управления про- ектом, в котором выделяется последовательная прогрессия от одной стадии процесса до другой. Изначально эта методология использовалась в обрабатывающей и стро- ительной промышленности, позднее в аппаратной инженерии, ну а для разработки программного обеспечения начала применяться в первой половине 1980-х годов
1
Изначально стадии каскадной модели назывались следующим образом: специ- фикация требований, проектирование, внедрение, интеграция, тестирование, установка и техническое обслуживание. Эти этапы показаны на рис. 4.1 (в форме диаграммы).
Разработка программного обеспечения, осуществляемая в соответствии с каскад- ной моделью, является в высшей степени структурированной. Много времени тратится на этапах спецификации требований и проектирования, что позволяет сократить количество ошибок, допускаемых на следующих этапах.
Во времена активного использования каскадной модели имела место высокая стоимость доставки программного обеспечения, распространяемого на компакт- дисках или на дискетах. К тому же еще приходилось учитывать стоимость ручной установки программ, выполняемой на рабочем месте заказчика. В случае необ- ходимости устранения ошибок нужно было записывать и распространять новые дискеты или компакт-диски. Из-за подобных расходов было целесообразнее по- тратить больше времени и сил на стадии спецификации требований, чем пытаться устранять ошибки на следующих стадиях.
1
Herbert D. Benington, Production of Large Computer Programs. IEEE Annals of the History of
Computing, October 1, 1983, http://bit.ly/benington-production.
66
Часть I. Основы devops
Рис. 4.1. Каскадная модель
Гибкая методология разработки ПО
Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легки- ми» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.
Мы выявляем более эффективные способы разработки программного обеспечения, а также помогаем это делать другим. В процессе выполне- ния этой работы мы пришли к выводам о том, что ценность:
• отдельных людей и взаимодействий выше ценности процессов и ин- струментов;
• рабочей документации выше ценности исчерпывающей документации;
• сотрудничества с заказчиками выше ценности переговоров, проводи- мых в процессе заключения контракта;
• реагирования на изменение ситуации выше ценности точного следо- вания плану.
Как видите, компоненты, находящиеся в левой части списка, оценивают- ся выше компонентов, расположенных в правой части списка.
Глава 4. Основные термины и концепции
67
К гибким методологиям относится Scrum, которая будет рассмотрена в одном из следующих разделов, и другие методы, при использовании которых во главу угла ставится сотрудничество, гибкость и конечный результат в виде работоспособного программного обеспечения.
ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?
Методология devops имеет много общего с гибкими методиками разработки программного обеспечения, особенно если учитывать фокус на отдельных людях, взаимодействиях и сотрудничестве. В связи с этим у вас, наверное, уже возник вопрос о том, не является ли devops просто «ребрендингом» гибких методик. Несомненно, методология devops сформировалась на основе гибких методик, но все же она является самостоятельным культурным движением. Это движение связано с историей компьютерной индустрии и включает гораздо больше, чем разработчики программ. Движение devops адаптирует и рас- ширяет принципы гибкой разработки программ и применяет их на уровне организации в целом, а не только в процессе разработки программ. Как будет подробно показано в следующих главах, devops приводит к культурным по- следствиям, выходящим за пределы области гибкой разработки. Изменения, вызванные внедрением devops, гораздо шире, чем банальное увеличение скорости доставки новых версий программ.
Scrum
В середине 1990-х годов Кен Швабер и доктор Джефф Сазерленд, принимавшие участие в создании Agile-манифеста, объединили усилия с целью формирования нового процесса создания программного обеспечения под названием Scrum. В ме- тодологии Scrum основной упор делается на максимизации способностей ко манды разработчиков к быстрому реагированию на изменение требований к самому проекту и со стороны заказчиков. При этом используются предопределенные циклы разработки, называемые спринты. Обычно длина циклов варьируется от одной недели до одного месяца. Процесс разработки ПО начинается с совещания по планированию спринтов, на котором определяются цели, выполняется обзор спринтов и производится ретроспектива спринтов. Это нужно для оценки степени выполнения спринтов и каких-либо проблем, которые могут возникнуть в процес- се выполнения спринта.
Одна из ключевых особенностей методологии Scrum — проведение ежедневных
Scrum-встреч либо ежедневных собраний, на которых члены команды как можно быстрее дают ответы на следующие три вопроса:
Что из того, что я сделал, помогло команде достичь целей спринта?
Что я планирую сделать сегодня, чтобы помочь команде достичь этих целей?
Что делать в том случае, когда какое-либо препятствие мешает мне или команде достичь целей?
68
Часть I. Основы devops
На ежедневных встречах, проходящих по утрам, scrum-мастер помогает сотруд- никам с повесткой дня, а также способствует устранению проблем. Роль scrum- мастера включает такие обязанности, как оказание помощи команде в самоорга- низации, координирование усилий, прилагаемых в процессе работы, устранение препятствий в работе. В результате команда будет продолжать добиваться успеха, а также привлекать владельцев проекта и заинтересованные стороны. В резуль- тате вырабатывается общее понимание того, что означает «сделано», и критериев оценки прогресса. Принципы Scrum часто неформально применяются во многих современных методологиях разработки программного обеспечения.
Методологии эксплуатации
Подобно тому как в методологиях разработки программного обеспечения пре- дусмотрено разбиение работы на отдельные стадии, можно также разделить на отдельные операции или иным образом организовать процесс эксплуатации. Как и в случае с методологиями, применяемыми для разработки ПО, рассмотрение всех методологий эксплуатации выходит за рамки этой книги.
ITIL
Методология ITIL, ранее известная как Information Technology Infrastructure Library
(Библиотека инфраструктуры информационных технологий), представляет собой набор методов, предназначенных для управления ИТ-услугами. Эта методология изложена в пяти книгах. В этих книгах описываются способы осуществления про- цессов, процедур и задач, а также составления контрольных списков, необходимых при эксплуатации. Эта методология позволяет установить соответствие разрабо- танных программ сформулированным критериям, а также оценить прогресс на пути к достижению целей. Методология ITIL сформировалась на основе практических методик, применявшихся в 1980-х годах во многих ИТ-организациях.
Британское центральное компьютерное и телекоммуникационное агентство разра- ботало набор рекомендаций по стандартизации этих практических методик. Первая публикация методологии ITIL имела место в 1989 году, а последняя — в 2011 году.
За это время она эволюционировала с пяти основных разделов до многотомного собрания и теперь включает описание стратегии техобслуживания, проектирования услуг, перехода к услугам, выполнения услуг и непрерывного улучшения услуг.
ИТ-аналитик и консультант Стивен Манн отмечает, что наряду со многими преи- муществами, которые дает ITIL-стандартизация и наличие более 1,5 млн ITIL-сер- тифицированных специалистов во всем мире, существуют и проблемы. Одна из ос- новных проблем — недостаточное внимание к отдельным практическим областям.
Согласно утверждению Манна, методология ITIL чаще является реактивной, а не проактивной, поэтому организациям, использующим ITIL, рекомендуется уделить больше внимания проактивному планированию и заказчикам.
Глава 4. Основные термины и концепции
69
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) Джеймс П. Вомак, Дэниел
Т. Джонс и Дэниел Рус ввели термин «бережливое производство»
1
. Вомак и Джонс выработали следующие пять принципов бережливого мышления
2
:
ценность;
процесс создания ценности;
поток;
вытягивание;
совершенствование.
1
James P. Womack, Daniel T. Jones, and Daniel Roos, Machine Changed the World (New York: Raw.
son Associates, 1990).
2
James P. Womack and Daniel T. Jones, Lean Thinking (New York: Simon & Schuster, 1996).
70
Часть I. Основы devops
Эти идеи, в частности стремление к совершенству с помощью системной иден- тификации и утилизации отходов, привели к появлению термина бережливость, олицетворяющего максимизацию ценности заказчиков и минимизацию отходов.
Бережливые системы сконцентрированы на компонентах, ценность которых возрастает за счет повсеместного устранения отходов, будь то перепроизводство некоторых частей и бракованных товаров, которые должны быть восстановлены, либо время, потраченное на ожидание появления других компонентов системы.
В результате развития этих систем возникли концепции бережливых ИТ-техно- логий и бережливой разработки программного обеспечения. В рамках этих кон- цепций одни и те же понятия используются в процессах разработки программного обеспечения и оказания ИТ-услуг.
В бережливых методологиях разработки ПО и оказания ИТ-услуг появляются следующие отходы:
невостребованные функции программного обеспечения;
задержки при общении;
замедленный отклик приложения;
бюрократические процессы.
Отходы в контексте бережливости противоположны ценностям. Мэри Поппендик и Томас Поппендик сопоставили отходы бережливого производства с отходами про- изводства программного обеспечения. В результате появился следующий список
1
:
частично выполненная работа;
дополнительные возможности;
переучивание;
ненужные передачи обслуживания;
переключение между задачами;
задержки;
дефекты.
Как и в случае с devops, не существует единственно верного способа внедрения бережливой разработки программного обеспечения. В процессе бережливой раз- работки ПО применяются два основных подхода: фокус на устранении отходов с помощью набора инструментов и улучшение рабочего потока, также известное под названием «путь Тойоты»
2
. Оба подхода направлены на достижение одной и той же цели, но в силу их различий могут приводить к разным результатам.
1
Mary Poppendieck and Thomas David Poppendieck. Implementing Lean Software Development
(Upper Saddle River, NJ: Addison-Wesley, 2007).
2
Jeffrey K. Liker, Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer (New
York: McGraw-Hill, 2004).
Глава 4. Основные термины и концепции
71
Концепции разработки,
релиза и развертывания ПО
При рассмотрении разработки, релиза и развертывания программного обеспече- ния следует упомянуть еще несколько концепций, которые ранее не рассматрива- лись в этой главе. Эти концепции описывают порядок разработки и развертывания программного обеспечения и дают представление о степени связи между ними.
После ознакомления с этими концепциями у читателя выработается более зрелое понимание способов использования инструментов, облегчающих применение требуемых практик.
Контроль версий
Система контроля версий фиксирует изменения файлов или наборов файлов, которые хранятся в системе. Это могут быть файлы исходного кода, ресурсы и другие документы, которые являются частью процесса разработки программного обеспечения. Разработчики вносят изменения в форме пакетов, называемых фик-
сациями, или ревизиями. Каждая ревизия, наравне с метаданными, такими как «кто внес изменения и когда», «хранится в системе в той или иной форме», находится в системе в каком-либо виде.
При наличии возможностей по фиксации, сравнению, выполнению слияния и вос- становлению прежних ревизий объектов в хранилище можно организовать расши- ренную кооперацию и сотрудничество внутри команды и между командами. Это сводит к минимуму возможные риски, поскольку появляется способ вернуться к предыдущим версиям объектов.
Разработка через тестирование
При выполнении разработки через тестирование (Test Driven Development; TDD) разработчик начинает с написания проверяемого функционал-теста, применяемо- го для проверки функциональности нового кода. После этого создается сам код, затем начинается тестирование этого кода. Благодаря тестированию гарантиру- ется безупречная работа новых функций, а также становится более очевидным назначение кода.
Если разработчики сами разрабатывают тесты, циклы обратной связи сущест- венно сокращаются. К тому же разработчики принимают на себя больше ответ- ственности за создание качественного кода. Подобное разделение ответствен- ности и уменьшение времени, выделяемого на цикл разработки программного обеспечения, и в наши дни продолжают оставаться важными компонентами devops-культуры.
72
Часть I. Основы devops
Развертывание приложений
Развертывание приложений представляет собой процесс планирования, техниче- ского обслуживания и доставки релизов программного обеспечения. В общем слу- чае при развертывании приложений следует учитывать изменения, которые имеют место на уровне, находящемся ниже уровня системы. При наличии автоматизации инфраструктуры построения зависимостей, используемых для выполнения кон- кретного приложения, будь то вычислительная программа, операционная система или другие зависимости, минимизируется влияние возможных несоответствий на выпущенное программное обеспечение.
В зависимости от типа приложения могут проявляться разные инженерные про- блемы. Например, для баз данных могут понадобиться гарантии обеспечения совместимости. Выполняемые в базах данных транзакции отражаются на данных.
Развертывание приложений является критическим аспектом, обеспечивающим качество программной инженерии.
Непрерывная интеграция
Непрерывная интеграция (Continuous Integration; CI) — это процесс интегри- рования нового кода, написанного разработчиками, в основной код или ветку
«мастер», осуществляемый в течение рабочего дня. Этот подход отличается от методики, в соответствии с которой разработчики работают с независимыми вет- ками неделями или месяцами, выполняя слияние кода в основную ветку только после полного завершения работы над проектом. Длительные периоды времени между слияниями приводят к тому, что в код вносится очень много изменений, что повышает вероятность появления ошибок. При работе с большими пакетами изме- нений гораздо труднее изолировать и идентифицировать фрагмент кода, который вызвал сбой. Если же используются небольшие наборы изменений, для которых часто выполняется слияние, поиск ошибок значительно упрощается. Постарайтесь избежать проблем, связанных с интеграцией, которые неизбежно появятся при слиянии больших наборов изменений.
В системах непрерывной интеграции после завершения слияния новых изменений обычно автоматически выполняется набор тестов. Эти тесты выполняются после фиксации изменений и завершения слияний. Это позволяет избежать накладных расходов, связанных с использованием ручного труда тестеров. Чем больше на- кладных расходов требует выполняемое действие, тем меньше вероятность, что оно будет выполнено, особенно в случае нехватки времени. Результаты выпол- нения этих тестов часто визуализируются. Если результаты выделены зеленым цветом, значит, тест завершился успешно, а только что интегрированный про- граммный релиз не содержит ошибок. Провальные или «красные» тесты означают, что релиз содержит ошибки и должен быть исправлен. Благодаря использованию этого рабочего потока идентификация и устранение проблем осуществляются намного быстрее.