Непрерывная поставка: коммерческая ценность, преимущества, недостатки и показатели

1. Скорость

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

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

2. Производительность

Эффективная работа приносит удовлетворение и радость, а команды с таким настроем всегда активней вовлечены в работу.

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

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

3. Устойчивость

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

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

Бюджет: слишком строгие рамки?

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

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

У вас есть прогрессивные мыслители?

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

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

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

Отсутствие приоритетов

Ни один владелец продукта не скажет вам: «Давайте все остановим и построим конвейеры непрерывной поставки!»

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

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

Конвейеры гигиеничны по своей природе. Если вы хотите сохранить свой бизнес, спросите себя: «Важна ли гигиена?» Конечно да!

Через конвейеры проходит огромное количество транзакционных данных

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

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

Проанализируем транзакционные данные конвейера

Можно ли анализировать транзакционные данные, чтобы извлекать ценную информацию? Конечно да!

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

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

Еще один пример. Мы узнали, что статический анализ кода приложения B в последние несколько кварталов выдавал все больше и больше ошибок. Это могло означать, что пора (пере)обучить команду по разработке приложения B, чтобы повысить качество создаваемого кода. Параллельно выяснилось, что статические анализаторы кода выдавали ложноположительные результаты, то есть принимали правильный код за ошибочный. Мы заменили используемый ранее анализатор на стандартный отраслевой инструмент, и количество ложноположительных результатов несколько снизилось. Мы провели семинар по разработке кода, в ходе которого обсудили реальные ошибки, выявленные при статическом анализе, и возможность их устранения. В результате работа команды снова вошла в нужное русло.

Еще один интересный вывод заключался в том, что модульные тесты приложения A обеспечивали меньшее покрытие кода, чем у приложений B и C, однако приложение A имело наименьшее количество проблем в рабочей среде за последний год. Писать модульные тесты и измерять покрытие кода — это нормальная практика. Чрезмерное усердие здесь непродуктивно для команды и бесполезно для клиентов. Урок усвоен.

Ключевые показатели эффективности (KPI)

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

KPI организации и KPI отдела

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

Ошибки в тестах, промежуточная среда и рабочая среда

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

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

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

Индекс стабильности

После определения KPI важно понять, не находится ли какой-то из показателей под влиянием субъективных факторов и не смещается ли он в каком-то конкретном направлении. Если это так, необходимо сбалансировать его с другими показателями, сместив их общий центр тяжести ближе к середине. Одним из таких показателей является стабильность.

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

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

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

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

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

Индекс качества кода

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

KPI с точки зрения бизнеса и технические KPI

Еще одним популярным KPI, который организации любят отслеживать, является ценность, создаваемая за один спринт. Считать количество релизов — очень распространенная, хотя и порочная практика, поскольку сами по себе релизы не добавляют ценности. Можно перемещать отдельные компоненты из точки A в точку B, не развивая при этом свой бизнес, и пользы от такой работы мало. Некоторые организации подсчитывают количество тестов, добавленных в ходе спринта, или общее количество выполненных тестов. Но и это не является показателем эффективности бизнеса, поскольку отражает только усилия разработчиков. Ценность, созданная за спринт, должна оцениваться с точки зрения бизнеса.

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

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

Счастливого пути!