CI/CD и DevOps. Нужны ли они вашей компании?

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

Однако такой подход называется «медленный релизный темп», и он сулит много проблем.

Что такое медленный релизный темп

Чтобы было понятнее, давайте представим простую аналогию. Допустим, вы хотите научиться водить машину. Идете в автошколу, и вам выдают… велосипед! По идее, он переносит вас из точки «А» в точку «Б» быстрее и проще, чем ноги, так что формально он относится к «средствам передвижения». Но вы-то хотели автомобиль.

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

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

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

Проходит еще год, и автошкола выкатывает вам Kia Rio c автоматической коробкой передач. По идее, тоже машина, но снова ваш опыт обнуляется.

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

Что такое быстрый релизный темп

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

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

Дополнительные плюсы — пользователи могут попросить быстро что-то подправить и не ждать еще год до следующего релиза.

Ну а владелец продукта может быстро проверить какую-то гипотезу (классическое «приклеить или прибить»), получив таким образом конкурентное преимущество.

Кто обеспечивает эту непрерывную деятельность?

За обеспечение этой связки между «бизнесом — программистами — поддержкой — пользователями — бизнесом» как раз и отвечает DevOps (от англ. development — разработка и operations — деятельность). Другими словами, это тот самый человек, который претворяет лозунг «мир — дружба — жвачка» в жизнь.

До его появления разные команды работают по отдельности, соприкасаясь лишь на моменте релиза, при этом регулярно пытаясь перебросить проблему друг на друга. C DevOps все команды работают вместе и работают непрерывно.

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

Добавим сюда управление инфраструктурой продукта (к примеру, как быстро развернуть обновления в нескольких филиалах или оперативно нарастить производительность в «горячий»/пиковый момент) и мы поймем, почему такой человек не может стоить дешево.

По сути, это такой технический директор компании, но в миниатюре.

Что такое CI/CD и почему это тоже важно?

А чтобы DevOps’у было проще жить, необходимо, чтобы участники проекта придерживались принципа CI/CD (непрерывной доставки и интеграции, от английского Continuous Integration и Continuous Delivery). Собственно, эта аббревиатура и есть одна из DevOps-практик.

Что понимается под CI (интеграция): это такая методология, при которой в код вносятся небольшие правки (условно, одна «фича» от команды за один мини-релиз), код от разных разработчиков (вероятно, на разных платформах и с разными инструментами), все объединяется, собирается в единый продукт и автоматически тестируется.

Затем начинается часть CD (доставка), в рамках которой собранный продукт развертывается на тестовых или продуктовых серверах, где становится доступным тестировщикам или конечным пользователям.

Все это обеспечивает быстрый релизный темп. И, как вы уже, наверное, догадались, работа в концепции CI/CD должна быть максимально автоматизирована, и это тоже забота DevOps.

Помимо CI/CD, существует еще несколько DevOps-методологий: здесь и контейнеризация приложений (здравствуй, Docker), и система контроля версий, и даже такие экзотические вещи как IAC (инфраструктура как код). Но о них надо рассказывать подробнее и в рамках совсем других статей и кейсов.

Почему быстрый релизный темп и DevOps-подходы могут вам не подойти?

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

Вот несколько причин, по которым CI/CD может быть губительным для вашего бизнеса:

• Ваше ПО используются в критических бизнес-процессах. Соответственно, вам требуется долгое, не автоматическое тестирование. В этом случае преимущества быстрого релизного темпа испаряются.
• Ваша организация скептически относится к экспериментам и будет рассматривать любое развертывание с «косяками» как неудачное.
• Ваша система примирования/мотивации разработчиков привязана с крупным релизам. Вы встретите сопротивление как «сверху», так и «снизу».
• Ваши методы автоматического тестирования еще недостаточно проработаны. Это не позволяет выпускать качественные мини-релизы постоянно. Результат как в пункте выше.
• Ваше ПО является некоей платформой, поверх которой клиенты настраивают приложение. И ваше тестирование недостаточно сложное, чтобы проверить достаточное количество вариантов использования.

Выводы

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

За год они обкатают пару десятков идей и сфокусируются именно на том, что нужно рынку.

Люди, обладающие знаниями в DevOps-концепции и привыкшие работать в парадигме CI/CD и Docker-контейнеризации, способны изменить сам ход ведения бизнеса. И, как видно из этого материала, они не могут стоит дешево. Слишком большой объем знаний должны вмещать их головы и слишком большое влияние на деятельность предприятия они оказывают.