Методология разработки — это набор принципов, подходов и инструментов, которые используются для организации и управления процессом создания программного обеспечения. Она определяет, как работает команда, как взаимодействуют её члены и распределяются задачи между ними, как контролируется качество продукта и многое другое. 

Цель методологии — это регламентировать процесс разработки и обеспечить реализацию проекта с учетом требований, сроков и бюджета.

В целом, в разработке программного обеспечения применяются разные методологии — от водопадной модели до экстремального программирования. Одна из них — это DevOps. 

В этой статье разберёмся, что же такое DevOps, зачем он нужен в процессе выпуска софта, какие проблемы решает и в чём заключается концепция методологии. Также отдельно рассмотрим роль DevOps-инженера и его задачи в команде и процессе разработки. 

Что такое DevOps

DevOps — это относительно новая концепция разработки программного обеспечения, которая со временем набирает всё большую популярность и постепенно смещает традиционные методологии разработки. Так, в 2020 году общий мировой рынок DevOps составлял около шести миллиардов долларов — к 2027 году по прогнозам ResearhAndMarket он вырастет до 25 миллиардов долларов. 

Само по себе определение DevOps широко. Дать этой методологии четкое определение довольно сложно, особенно по сравнению с другими областями IT.

Что такое DevOps простыми словами? Это методология, в которой разработка (Development) пересекается и объединяется с эксплуатацией программного обеспечения (Operations), а также с тестированием. Но такое определение вызывает несколько резонных вопросов:

• Где начинаются и заканчиваются границы DevOps?

• Какие части разработки, тестирование и сопровождения — уже не DevOps?

• В чем заключается необходимость связывать эти процессы?

Постараемся ответить на них ниже.

Традиционный процесс выпуска приложений

Разработка, тестирование и эксплуатация — это три основных этапа всего процесса выпуска программного обеспечения. Давайте рассмотрим этот процесс и его этапы подробнее.

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

Давайте рассмотрим традиционный способ разработки приложений — водопадную модель. От идеи будущего приложения до его развёртки на серверах:

• Рождается идея программного обеспечения.

• Эта идея трансформируется в список бизнес-требований к будущему продукту.

• Разработчики пишут код и создают приложение.

• Тестировщики проверяют работоспособность приложения и, при необходимости, возвращают его на доработку.

• Когда программного обеспечения готово, его нужно доставить конечным пользователям. Пусть это будет веб-приложение. Тогда нужно сделать его билд, настроить сервер, его окружение и после развернуть само приложение.

Теперь пользователи могут работать с приложением. При этом работа не останавливается — нужно убедиться, что у пользователей не возникает проблем как с продуктовой, так и с технической частью приложения. Например, нравится ли пользователям UI и выдерживает ли развёрнутое приложение нагрузку. 

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

И как раз одна из задач DevOps — сделать процесс обновления приложений быстрым и качественным. Рассмотрим, какие ещё проблемы помогает решить DevOps и с помощью чего. 

С какими проблемами сталкивается водопадная модель.

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

Рассмотрим несколько типичных проблем водопадной модели.

• Плохое взаимодействие между разработчиками, специалистами службы эксплуатации и тестировщиками

Как мы уже писали выше, выпуск приложения состоит из трёх основных этапов: разработки, тестирования и эксплуатации. В таком разделении разработчики отвечают за написание кода, тестировщики — за работоспособность приложения, а служба эксплуатации — за его развёртку и сопровождение. 

Между этими сущностями может возникать разрыв: разработчики не знают, как развёртывается, запускается и тестируется приложение, а тестировщики и служба эксплуатации — как оно работает. Например, из-за этого разработчики могут писать код, который не будет адаптирован под особенности деплоймента. Это приведёт к тому, что проект потребуется доработать. 

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

Такого рода недопонимания могут привести к увеличению TTM (Time To Market) — времени от рождения идеи до выпуска приложения. Помимо увеличения общих сроков реализации продукта, это приводит и к увеличению бюджета.

Сама проблема связана с тем, что в водопадной модели нет четкого автоматизированного процесса обмена требованиями между разработчиками, отделом эксплуатации и тестировщиками. 

• Конфликт интересов

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

Разные приоритеты команд и задачи приводят к конфликту интересов. Такой формат взаимодействия затрудняют сотрудничество каждой сущности.

• Команды могут остаться без работы

Одна из особенностей водопадной модели — последовательность. Сначала разработчики пишут код, потом его проверяют тестировщики, и только после служба эксплуатации развёртывает и сопровождает приложения.

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

Все эти проблемы приводят к тому, что сроки выпуска продукта или обновления увеличиваются, а бюджеты — раздуваются. Теперь расскажем, как с этими проблемами помогает справиться DevOps и с помощью чего.

Как DevOps помогает решить проблемы водопадной модели 

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

Методология DevOps объединяет подходы, практики и инструменты для достижения этой цели. Это комбинация всего, что позволяет быстро выпускать качественные продукты. 

Такая характеристика слишком широкая, чтобы понять, в чём именно заключается DevOps. Это привело к тому, что на практике компании реализовывали идею DevOps разными способами. В итоге это сформировало общие наборы инструментов, подходов и практик DevOps, которые стали применяться в индустрии.

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

На примере этой роли расскажем, какие практики, DevOps-инструменты и подходы применяются в этой методологии. 

Что делает DevOps-инженер

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

Автоматизация и CI/CD

Основной подход в DevOps — это автоматизация разработки, тестирования и развёртки приложений. Благодаря ей, команда может ускорить и стандартизировать все процессы и создать цикл непрерывной интеграции (Continuous Integration) и непрерывного развертывания (Continuous Deployment) приложений — CI/CD-конвейер.

Рассмотрим отдельные этапы в DevOps для выпуска приложений и инструментов, которые применяются на них:

• Код. В DevOps разработка осуществляется в общем репозитории, например GitLab, где хранится код приложения. Это позволяет создать единый процесс работы над кодом и автоматизировать его передачу на дальнейшие этапы.

• Тестирование. После того, как в коде произошли изменения, они передаются на автоматическое тестирование по подготовленному набору тестов для приложения. Если обновления не приводят к ошибкам, код передаётся на сборку.

• Сборка приложения. С помощью пакетных менеджеров и инструментов сборки код собирается в приложение. Здесь набор инструментов зависит от языка программирования. Например, для JavaScript применяется npm, а для Java — Maven или Gradle. 

• Контейнеризация и оркестрация. Контейнеры позволяют минимизировать количество зависимостей и упростить развёртку приложений за счёт единого окружения. Поэтому часто в DevOps используют именно их. В основном используют Docker. Если таких контейнеров немного, то ими можно управлять с помощью Docker Compose, если много — потребуется более мощный инструмент вроде Kubernetes. Также полученные образы необходимо хранить в репозитории. В качестве него может выступать Nexus или Docker Hub. 

• Развёртка. Для автоматизации деплоймента приложений часто используется Jenkins.

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

kube

Работа с инфраструктурой

Благодаря CI/CD-конвейеру, команда может автоматически развёртывать приложение и обновления на сервере. Многие компании предпочитают в качестве серверов использовать облака вместо физических серверов. Они позволяют автоматизировать масштабирование, работу с окружением и многое другое. В общем, упростить работу с инфраструктурой. 

Мониторинг

В реалтайм-режиме важно следить за работоспособностью приложения: возникают ли проблемы у пользователей с доступностью к продукту и т.п. 

Для этого используются мониторинг — программное обеспечение, которое отслеживает метрики приложения: нагрузку, доступность продукта. Среди таких сервисов — Prometheus и Nagios. 

IaC — Infrastructure as Code

В DevOps на каждом этапе CI/CD используется обширное количество инструментов. Чтобы не настраивать их вручную, можно использовать IaC — инструменты для автоматического настройки инфраструктуры. В качестве такого сервиса можно использовать Terraform. Он позволит автоматизировать процесс настройки инфраструктуры и сделать его более прозрачным и однообразным. 

Скрипты

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

Здесь в качестве инструмента можно использовать специфичные для операционных систем, такие как Bash для Linux и PowerShell для Windows. Также можно использовать общие для всех систем языки программирования: Ruby, Go или Python — его применяют чаще всего. 

Системы контроля версий

Они позволяют хранить не только код приложения, но и всей инфраструктуры. Например, при использовании Terraform.

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

Взаимодействие между отделами

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

Например, DevOps для эксплуатации и разработки — это способ наладить коммуникацию и выработать единый процесс работы.

Почему бизнесу стоит внедрить DevOps

Преимущества DevOps — это: 

• Скорость. Благодаря автоматизации тестирования, сборки и развёртки компании могут выпускать обновления быстрее, при этом не теряя в качестве продукта. Такая гибкость и скорость позволяет быстро реагировать на изменения рынка и требований пользователей.

• Предсказуемость и качество. За счёт автоматизации релизы в DevOps-проекты выходят часто и с предсказуемыми сроками. Такая особенность помогает контролировать бюджет.

• Экономия на сопровождении и эксплуатации. Автоматическое управление инфраструктурой и мониторинг приложений позволяет быстро реагировать на проблемы и устранять их без больших трудозатрат. Также это помогает максимизировать SLA, снижая время, когда приложение недоступно пользователям.

При этом есть минусы и особенности:

• DevOps изменяет организационную культуру. Компании может потребоваться время и инвестиции для адаптации к новым процессам и методам работы.

• Компания может поставить производство ошибок на поток. При неправильной настройке автоматизации могут возникать новые проблемы, связанные с ошибками в скриптах или конфигурациях. Их нужно тщательно проверять и тестировать.

• Нужны инвестиции. Внедрение DevOps потребует инвестиций в новые инструменты и технологии для автоматизации процессов.

Заключение

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

Если решите интегрировать DevOps в свой процесс разработки, в Timeweb Cloud есть сервисы, которые помогут это сделать: облачные серверы, Kubernetes и Terraform, которые снимут часть нагрузки с вас.