Джин Ким - Руководство по DevOps

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

• созданию основы нашего конвейера развертывания;

• быстрому и надежному автоматизированному тестированию;

• организации непрерывных интеграции и тестирования;

• обеспечению возможности низкорисковых релизов, их проектирование и автоматизация.

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

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

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

Слишком часто мы обнаруживаем, как наши приложения работают в среде, приближенной к производственной, только во время развертывания — когда уже слишком поздно, чтобы устранять проблемы без негативного влияния на клиентов. Наглядный пример широкого спектра проблем, вызванных рассогласованием приложений и сред, — программа Enterprise Data Warehouse. Ее созданием в крупной австралийской телекоммуникационной компании в 2009 г. руководила Эм Кэмпбел-Претти. Она стала генеральным менеджером и бизнес-спонсором этой программы, стоившей 200 миллионов долларов, и одновременно получила ответственность за все стратегические цели, связанные с этой платформой.

В презентации на конференции DevOps Enterprise Summit в 2014 г. Кэмпбел-Претти пояснила, что «в то время параллельно шли десять потоков работы, все с помощью водопадного метода, и все десять потоков значительно отставали от графика. Только один из потоков успешно дошел до стадии приемочных испытаний, проводимых пользователями (User Acceptance Testing, UAT), в запланированный срок, и еще шесть месяцев потребовались для завершения этих испытаний, которые показали, что результирующая производительность оказалась намного ниже ожидаемой. Эта недостаточная производительность явилась основным катализатором преобразования отдела по технологии Agile».

Однако после использования Agile в течение почти года разработчики добились только небольших улучшений, по-прежнему не получая необходимых результатов в бизнесе. Кэмпбел-Претти провела ретроспективный обзор программы и задала команде вопрос: «Если учесть весь опыт, накопленный нами за время последнего релиза, то какие вещи мы могли бы сделать, чтобы удвоить нашу продуктивность?»

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

Новая команда интеграции и сборки стала ответственной за «создание качества внутри процессов вместо проверки качества после создания продукта». Первоначально она была в составе команды администраторов баз данных (DBA), и специалисты получили задачу по автоматизации процесса создания среды. Команда быстро сделала удивительное открытие: только 50 % исходного кода в средах разработки и тестирования соответствовало производственной среде.