В первой статье, посвященной DevOps, мы уже упоминали о том, насколько важной для рынка программного обеспечения стала скорость доставки конечного продукта до пользователя. Собственно, идея DevOps как культуры разработки сводится к тому, чтобы оптимизировать и автоматизировать все процессы на этапе от появления идеи до готового продукта так, чтобы максимально сократить цикл разработки. В этой статье мы поговорим о двух конкретных практиках DevOps – непрерывное развертывание продукта (Continuous Deployment) и управление релизами (Release Management) – и о том, как они позволяют оптимизировать временные затраты.

Если брать грубо, то среднестатистический цикл разработки программного обеспечения выглядит таким образом:

  • разработчик пишет код и отправляет его в репозиторий;
  • из кода в репозитории вручную собирается билд и отправляется в среду разработки для предварительного тестирования, где проверяется, способен ли он работать где-то еще за пределами «машины» разработчика, нет ли у него явных дефектов и вообще есть ли у него шансы на жизнь;
  • если все здорово на этом этапе, то код отправляется к QA (если не работает – обратно до достижения той кондиции, когда код можно показывать тестировщикам);
  • тестировщики проводят свои тесты;
  • как только они готовы подписаться под качеством, код попадает на продакшн;
  • новая (или обновленная) программа попадает к конечному пользователю.

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

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

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

Любая проблема поправима, но требует времени на поиск и исправление ошибок. А время в разработке выливается в огромные деньги для заказчика. Что еще хуже – в итоге нетерпеливые пользователи могут убежать к конкурентам. Потому что конкурентов сегодня – хоть пруд пруди для любого сервиса или программы, пользователю вообще нет нужды оставаться лояльным. Особенно, если речь идет о каком-то очередном мобильном приложении, которое постоянно «вылетает» и совершенно не выполняет свои функции.

Давайте посмотрим, как выглядел бы цикл разработки с применением DevOps-практик. Например, если бы для разработки программы использовалась служба Visual Studio Team Services, которая позволяет команде обмениваться кодом, проверять его работоспособность и доставлять заказчику по максимуму автоматизировав каждый этап.

  1. Разработчик пишет код и отправляет его в репозиторий. Потом идет пить кофе, есть печеньки и созваниваться в Skype с рекрутами из Силиконовой долины. Или писать код дальше. В общем, он заканчивает с этим кодом и забывает о нем навсегда до тех пор, пока не надо будет исправлять в нем баги.
  2. Код попадает в репозиторий, где автоматически формируется билд и отправляется в среду для разработчиков с правильно проставленным номером и понятными свойствами (автоматика едва ли сможет собрать что-то не то). Там при помощи автоматических тестов проходит первичная проверка его работоспособности. Автоматическое тестирование в Visual Studio Team Services проходит максимально информативно: в службе отображается, какие тесты были запущены и с каким успехом они были пройдены. Можно настраивать процесс таким образом, чтобы после провала одного из тестов код не проходил на следующий этап или проходил, но соответствующий специалист получал оповещения об ошибках. Если код успешно проходит тесты, то соответствующий специалист, который должен проверить, что тесты запустились и прошли успешно, дает добро на дальнейшую передачу кода QA-специалистам.
  3. Руководитель QA автоматически получает сообщение на почту о том, что его команда может приступать к работе с этим кодом. Кроме почты он получает это сообщение везде в той среде, где работает. Чтобы процесс не стопорился, если QA-лид, например, в отпуске или на больничном, разработчик может добавить в список тех, кто может принять код в работу, других членов команды, которые потенциально могут принять решение. Любой из них может отправить код на следующий этап. Если QA-лид знает, что, например, вся команда еще занимается тестированием предыдущей версии, он может не начинать работу над новой, чтобы не создавать кашу в существующих версиях программы. В таком случае статус проекта (еще не прошел тестирование) отображается соответствующим образом. Все понимают, что дальше этот билд не готов отправляться.
  4. Как только тестировщики берут в работу новый код, это тоже отображается в системе управления релизами. Дальше все происходит точно так же, как и на первом этапе. QA-команда проводит тестирование, одобряют протестированный код и отправляют его на продакшн. После этого статус проекта тут же меняется. В Visual Studio Team Services можно добавлять автоматические тесты или новые среды для тестирования буквально на лету – клонируя и немного исправляя существующие или используя один из готовых шаблонов. Облачная платформа Microsoft Azure располагает огромным количеством инструментов для создания новых сред.

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

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

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

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