Как сократить время от появления идеи до выпуска готового приложенияДата публикации: 30.08.2017 Полный цикл статей о DevOps:
В первой статье, посвященной DevOps, мы уже упоминали о том, насколько важной для рынка программного обеспечения стала скорость доставки конечного продукта до пользователя. Собственно, идея DevOps как культуры разработки сводится к тому, чтобы оптимизировать и автоматизировать все процессы на этапе от появления идеи до готового продукта так, чтобы максимально сократить цикл разработки. В этой статье мы поговорим о двух конкретных практиках DevOps – непрерывное развертывание продукта (Continuous Deployment) и управление релизами (Release Management) – и о том, как они позволяют оптимизировать временные затраты. Если брать грубо, то среднестатистический цикл разработки программного обеспечения выглядит таким образом:
Возня с кодом вручную отрывает разработчика от дальнейшей работы над продуктом. Кроме того, на каждом из этих этапов человеческий фактор (даже если перед этим носитель этого фактора отлично справлялся со своей задачей, написал крутой код или нашел самые хитроумные ошибки) может здорово испортить все. Не специально, просто все мы люди. Разработчик может немного задуматься и собрать билд непонятно из чего и отправить QA-отделу не то, что планировалось. Или отправить на продакшн не проверенный код, а новый, криво работающий, с кучей прекрасных фич и багов. Или перепутать номер версии билда, потому что слишком много цифр или просто опечатка вкралась, в итоге тестировщики будут вносить найденные ими ошибки в трекер с неправильным указанием номера билда, и на этапе их исправления возникнет каша. Тест-лид может оказаться в отпуске или на больничном, ему сколько писем не пиши, он их не получит вовремя, и остальная команда не будет в курсе, что подоспел новый кусок программы на тест. Кто-то из QA перепутает версии или мало ли что еще может случиться. Любая проблема поправима, но требует времени на поиск и исправление ошибок. А время в разработке выливается в огромные деньги для заказчика. Что еще хуже – в итоге нетерпеливые пользователи могут убежать к конкурентам. Потому что конкурентов сегодня – хоть пруд пруди для любого сервиса или программы, пользователю вообще нет нужды оставаться лояльным. Особенно, если речь идет о каком-то очередном мобильном приложении, которое постоянно «вылетает» и совершенно не выполняет свои функции. Давайте посмотрим, как выглядел бы цикл разработки с применением DevOps-практик. Например, если бы для разработки программы использовалась служба Visual Studio Team Services, которая позволяет команде обмениваться кодом, проверять его работоспособность и доставлять заказчику по максимуму автоматизировав каждый этап.
В такой системе каждый член команды знает, когда следующий шаг за ним, время не проходит в пустую и ничего не теряется по дороге, всегда понятно, на каком свете находится создаваемый продукт. Не каждый билд, прошедший стадии разработки и тестирования, отправляется в продакшн – часть остается на любом из двух предыдущих этапах и ждет новых фрагментов кода. В системе управления релизами в Visual Studio Team Services можно проследить, до какого этапа дошел каждый из билдов и что он из себя представляет. Сервис позволяет просматривать изменения в том коде, который отправляется на продакшн, по сравнению с предыдущими версиями: какие (и кем) были исправлены баги, какие фичи добавились. В общем, что в итоге увидит пользователь у себя на устройстве. Никаких котов в мешке или неизвестных героев. Если что-то ломается на любом этапе, то причину можно установить за минуты. Это позволяет защититься от случайных ошибок ручной сборки, быстрее найти корень проблем и лучше понимать, какой конкретно продукт хвалят или ругают те, кому довелось им пользоваться. Описанная выше практика выглядит здорово в теории, но на деле, разумеется, требует вложения средств и времени команды в конкретные инструменты. Для бизнеса это расходы. И надо понимать, в каких единицах оценивать их окупаемость. В данном случае за единицу стоит брать время, которое проходит с момента возникновения идеи продукта до его доставки конечному пользователю. Потерянное время в конечном счете конвертируется в потерянные средства. Сэкономленное – в довольных заказчиков, пользователей и новые проекты. Полезные материалы по DevOps:
Источник: https://ain.ua/2016/06/29/kak-sokratit-vremya-ot-poyavleniya-idei-do-vypuska-gotovogo-prilozheniya Данный материал написан участником сообщества. В статье представлено мнение автора, которое может не совпадать с мнением корпорации Microsoft. Microsoft не несет ответственности за проблемы в работе аппаратного или программного обеспечения, которые могли возникнуть после использования материалов данной статьи.
|