DevOps — подход, про который вы наверняка слышали. Про него любят рассуждать многие, но есть ли понимание того, что это такое на самом деле? По данным рекрутинговых порталов, профессия DevOps-инженера — актуальна и хорошо оплачивается. Общее количество вакансий в России — около 500. Это значит, что хороших специалистов на рынке не так много, несмотря на обилие обучающих курсов. Разбираемся — что же такое DevOps и как он устроен.
Суть
Основа DevOps-подхода — это документ. «DevOps Manifesto», в котором подробно расписаны области его применения. Согласно ему, DevOps — это не просто утвержденные способы сертификации, набор ролей, инструментов или предписаний, а целая «философия», которая состоит из следующих установок:
- коммуникация между командами разработки (Development) и ИТ-операций (Operations) должна быть прозрачной и эффективной;
- фокус — на продукты, а не проекты;
- большая часть аспектов работы должна быть автоматизирована;
- работа над продуктом не заканчивается после релиза;
- создание продукта считается завершенным только тогда, когда он снят с производства.
Инструменты
Devops должен очень хорошо быть знакомым с процессом организации разработки программного обеспечения. Можно выделить 2 наиболее распространенных подхода:
GitHub Flow
Его используют для продуктов с одной версией, которая обновляется не очень часто. Например, веб-сайтов. Главный плюс этого инструмента — с ним разработчикам проще понимать и организовывать свою работу. Главное требование к коду здесь такое: в мастер-ветке не допускаются ошибки, и код должен быть готов к развертыванию в любой момент.
Еще один важный принцип здесь — нужно подробно вносить все коммиты в ветви. Именно благодаря этому все члены команды могут в любой момент времени понять, что конкретно сделано, а что предстоит сделать. Кроме того, это сделает быстрее и полезнее обратную связь.
GitLab Flow
Фактически, это расширение GitHub Flow, цель которого — еще больше стандартизировать процесс разработки и сделать связь между кодом и решаемыми проблемами более прозрачной. Для этого здесь введены дополнительные виды веток, например, ветки среды и выпуска. Также важная вещь здесь следующая — любое значительное изменение в коде должно сопровождаться подробным объяснением причин этого.
Также следует упомянуть систему управления конфигурациями Ansible, с помощью которой можно автоматизировать настройку и развертывание ПО. Она входит в состав большинства дистрибутивов Linux. Ее главное преимущество заключается в том, что она не требует установки клиента в системе.
Практики DevOps
Главные цели DevOps — автоматизация рабочих процессов и непрерывное улучшение продукта. Для их достижения используются следующие практики, применяемые на разных этапах.
Непрерывная интеграция. Ее суть в том, что команда постоянно объединяет изменения программного кода в центральном репозитории, после чего автоматически происходят его сборка, тестирование и запуск. Главные преимущества этой практики — быстрый поиск и исправление ошибок, улучшение качества ПО и сокращение временных затрат на проверку и выпуск обновлений.
В командах, где непрерывная интеграция не применяется, вполне возможна ситуация, когда люди работают изолированно и объединяют изменения с основной частью проекта только в момент завершения своей части проекта. Такая схема делает слияние кода крайне сложной задачей, в ходе выполнения которой можно совершить большое количество ошибок.
Непрерывное тестирование. Смысл этой практики — регулярное тестирование продукта перед обновлением для минимизации количества ошибок. Стоит особо отметить, что тестирование в DevOps — это ответственность всех членов команды. Задача разработчиков — заложить метрики качества в код и собрать результаты тестов. Работа специалистов по контролю качества — формировать тестовую среду и задавать настройки. Все тесты в DevOps проводятся быстро и автоматизировано, чтобы качественно отслеживать изменения в коде. Непрерывное развертывание и доставка. Суть этих практик — в автоматизации оперативного внедрения измененного или нового кода. Они дают возможность полностью автоматически развернуть код после каждой новой интеграции, без «ручного» участия членов команды. Благодаря этим практикам удобнее поддерживать согласованность ПО на разных платформах и средах развертывания.
Мониторинг. Согласно этой практике, постоянному мониторингу подвергается не только существующие виды кода, но и цикл обратной связи. Благодаря средствам непрерывного мониторинга команда разработчиков постоянно отслеживает показатели работы ПО и повышает его стабильность. Автоматизация процесса поиска конкретных проблем позволяет экономить время и часто их выявление происходит на опережение.
Инфраструктура как код. Смысл практики — в настройке инфраструктуры по тем же принципам, что и создание программных продуктов. В результате устраняются границы между созданием приложений и организацией сред для них. Иными словами, код здесь — это конкретный план. Можно можем принести преимущества организации работы конвейеров DevOps в новые классы «кода» .
В этой практике все может иметь свой собственный DevOps-процесс. Процесс для приложений, конфигурации приложений, конфигурации кластера, образов и другого. Причем у каждого процесса своя скорость, и они не зависят друг от друга. Это выводит скорость и качество работы на совершенно другой уровень.
Итоги применения DevOps-подхода
Среди итогов применения DevOps можно назвать следующие:
- высокая удовлетворенность пользователей продуктом;
- быстрое добавление функциональности;
- активное применения инноваций в работе;
- постоянное улучшение рабочих процессов;
- мониторинг прогресса в проектах в наглядном визуальном виде;
- рациональное и оправданное использование имеющихся ресурсов.
Таким образом, DevOps-подхода подойдет любой компании, где в разработке ПО участвуют более 5 человек. В этом случае внедрение DevOps уже имеет смысл и способно сделать работу эффективнее. Эта методика активно применяется в FAANG, телекоме, финтехе и других технологических компаниях.
Если же попытаться составить некий усредненный портрет DevOps-инженера, это будет сильный системный администратор с опытом более 3-х лет, который хорошо умеет взаимодействовать с разработчиками. А альтернативой сотрудника в штате может стать обращение к компании-подрядчику, которая выступит в роли стороннего DevOps-инженера.
Предыдущая статья
