Сегодня при обсуждении программного обеспечения часто всплывают такие, на первый взгляд, сложные понятия как CI/CD, контейнеризация, пайплайн, политика деплоя и т.д.
Все они относятся к области, которую мы разберем в этом материале. После прочтения, вы не только будете комфортно себя чувствовать, когда разработчики перейдут на «птичий язык», но и также понимать, как их слова переводятся на язык денег.
Что такое DevOps
Это методология, которая направлена на то, чтобы как можно быстрее поставлять исправный функционал пользователям.
Чтобы понять, какие проблемы решает DevOps, рассмотрим цепочку создания ПО при классическом подходе:
Программисты пишут код → QA-специалисты тестируют → администраторы переносят на сервера;
Работы ведутся последовательно разными командами. Для каждого функционального изменения весь цикл повторяется снова и снова. В реальности этапы слабо связаны между собой. При каждой передаче на следующего по цепочке неизбежно возникают операционные издержки и неприятное перекладывание ответственности: «у нас все работает, это у вас окружение настроено неправильно».
Чтобы управлять издержками сложилась практика копить жалобы и пожелания пока не наберется достаточное для осмысленного релиза количество.
Такой подход казался нормальным, пока в 2009 году впервые не предложили способ совместить разработку (Development) и эксплуатацию (Operations). Так появился продолжающий идеи бережливого производства DevOps. Если грубо, это идейный наследник гибких методологий. Здесь тоже есть манифест, устоявшиеся практики и масса инструментов для внедрения.
Зачем внедрять DevOps и что это даст бизнесу
Как было раньше, мы разобрали, теперь рассмотрим как происходит разработка по этой методологии: от формирования задачи до тестирования и запуска.
Инфраструктура и платформа как сервис
Чтобы запустить написанный программистом код нужна инфраструктура — стейдж-сервера для тестирования работоспособности и продакшн-сервера, на которых размещается действующая версия продукта, доступная конечным пользователям.
Фундамент DevOps — это инфраструктура как сервис. Если вы размещали сайт на хостинге, то понять эту концепцию будет несложно.
Хостинг провайдер по тарифному плану дает серверные мощности, чтобы вы разместили приложение в вебе. При этом у вас практически отсутствуют рычаги управления этими мощностями — гибко настроить такой сервер получается редко, все приходится делать через согласования с провайдером и смену тарифа, что отнимает время. Поэтому, настройкой и отладкой этой инфраструктуры часто занимаются системные администраторы.
Благодаря развитию облачных технологий управлять инфраструктурой стало проще. Разработчик может гибко настраивать виртуальную машину под нужды проекта: выбрать объем хранилища, HDD или SSD, количество ядер процессора. Сделать это можно командой из консоли прямо в IDE, в которой программист пишет код. При этом зависимость от конкретного поставщика облачного хранилища сведена к минимуму.
Это существенно ускоряет процесс создания и сопровождения продукта. Возросла нагрузка — добавить мощностей не составит никаких проблем, точно также как и уменьшить их. Можно даже автоматизировать этот процесс с помощью инструментов вроде Terraform.
Дополнительный важный, но необязательный аспект DevOps — платформа как сервис.
Поставщики облачных решений также позаботились о настройке серверного окружения, скриптах для поддержки версии языка программирования, базы данных и так далее. Разработчик выбирает заготовленную платформу для хранения образов с установленной операционной системой и развернутой кодовой базой в так называемых контейнерах для комфортной дальнейшей работы.
Это дешевле, чем самостоятельно настраивать виртуальные машины с нуля. Конечно, с помощью мощного инструмента вроде Kubernetes, можно сделать такую платформу самому, не прибегая к готовым решениям.
Непрерывный конвейер: доставка, тестирование, развертывание и мониторинг
Итак, если администрирование серверов стало намного проще, то как это повлияло на общий процесс разработки?
Вся идеология DevOps направлена на то, чтобы наладить непрерывную доставку исправного функционала, его развертывание и интеграцию.
Давайте разберем на примере: когда программист написал новый функционал и подготовил сборку, нужно провести тестирование. Если разработчик проведет это тестирование на своем компьютере, то вероятно возникнет ситуация, когда у него код работает, а у коллеги нет. Виной всему локальные отличия в среде разработки. Избежать такое поможет контейнеризация. Внутри контейнера эталонный образ системы, к которому применяются изменения. После тестирования, их можно интегрировать в проект.
Рассмотрев пример непрерывного тестирования, мы подобрались к понятию CI/CD, которое обозначает непрерывную интеграцию и развертывание кода.
После автотестов, новый код можно переносить на «боевой» сервер. Для безопасного развертывания есть ряд политик деплоймента. Рассмотрим популярные:
- открыть новый функционал только группе пользователей, чтобы собрать от них обратную связь и уже для остальных ввести этот функционал с учетом пожеланий.
- перенести все изменения на отдельный сервер, и только убедившись в его корректной работе, отключить сервер с устаревшей версией системы и направить пользователей на новый.
DevOps не заканчивается после того, как функционал оказался на «боевом» сервере. Здесь также важно настроить сбор обратной связи от пользователей с помощью логирования, мониторинга и трейсинга.
- Логирование — учет событий внутри приложения, например о том, что пользователь положил товар в корзину. Настроить логирование можно с помощью Kibana.
- Мониторинг — это проверка перебоев в работе сервера. Разработчик может написать метрику, например используя Prometheus, и инструмент с заданной периодичностью будет проверять, не упал ли сайт. Для визуализации логов подойдет Grafana.
- Трейсинг — отслеживание движений запросов, чтобы понимать, как между собой взаимодействуют сервера. Для этого подойдет Jaeger.
Все это позволяет отслеживать любые неполадки и вовремя их устранять.
Для каждого проекта создаются уникальные правила, которые формируют пайплайн — конвейерный процесс.
Почему и когда следует отдать DevOps на аутсорс?
Каждый рассмотренный нами аспект по отдельности дает ряд преимуществ, ценность которых сводится к раннему обнаружению дефектов и следовательно более дешевому устранению. Насколько дешевому?
Стоимость внесения любых изменений экспоненциально растет по мере движения по цепочке создания цифрового продукта: чем дальше, тем дороже. Допустив дефект на продакшн-сервер, бизнес не только упускает потенциальную выгоду, но и несет прямые убытки.
Неважно, речь о продуктовых или о сервисных компаниях: DevOps одинаково полезен везде, где разрабатываются информационные системы. Аутсорсинг DevOps позволит чаще и быстрее вносить изменения, избегать простоев при внедрении, а также быстро восстанавливаться в случае сбоев в работе.
К сожалению, нанять профессионального «инженера-девопсера», который придет и единоразово наведет порядок в производственных процессах нельзя. Такого не бывает. DevOps — это идеология, которую должны разделять все члены команды. Внедрить ее в свой IT-отдел не столь просто.
Обращаясь в аутсорсинговую компанию вы получите выделенную команду, которая уже знает о преимуществах метода и постепенно организует непрерывный производственный процесс на вашем проекте.
Наши специалисты
В Work Solutions вертикальная оргструктура. Есть старшие разработчики и тимлиды с многолетним опытом коммерческой разработки. Эти специалисты проходят курсы и активно читают профессиональную литературу. Постепенно накопленный опыт переносится на процесс разработки и передается младшим специалистам. Таким образом складывается общая корпоративная культура, в которой проверенные практики DevOps становятся обязательным требованием для всех.
Почему мы
У нас есть опыт формирования выделенных команд и внедрения DevOps на проектах. Наши разработчики внедряли метод для создания white-label решений в области финансовых технологий, а также делились опытом с поставщиками облачных сервисов. Обращайтесь за консультацией, чтобы понять как внедрить передовые практики на вашем проекте.
