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

Практика 1.

Выполнив свои задачи, разработчик создает рабочую копию будущего приложения. Но потом над ней еще работают разные функциональные группы специалистов, каждая из которых регулярно вносит в рабочую версию новые изменения. Поэтому практика непрерывной интеграции предусматривает использование автоматизированных продуктов, систем и сервисов (например, TeamCity или TFS/Team Foundation Server), которые запускают сборку проекта после каждого внесенного изменения и оповещает всех участников.
Что дает: помогает вовремя обнаружить и устранить проблемы интеграции, автоматизирует процесс сборки приложения.

Практика 2.

Когда сборка готова, начинается ее автоматическое тестирование (при помощи Unit- и UX-тестов, интеграционных тестов и т.д.). Ручные тесты, результаты которых зачастую зависят от человеческого фактора, такой практикой не предусмотрены вообще.
Что дает: оперативно и точно оценивает состояние сборки, экономит ресурсы (автоматические тесты всегда обходятся дешевле, чем ручные)

Практика 3.

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

Практика 4.

Когда сборка готова и протестирована, начинается ее автоматическая установка в выбранную среду: тестовую или рабочую (продуктовую).
Что дает: автоматизирует и ускоряет процесс поставки приложения.

Практика 5.

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

Практика 6.

Это нагрузочное тестирование, при котором проверяется работоспособность приложения в условиях запланированных рабочих нагрузок. Проще говоря, вы проверяете, сможет ли приложение корректно работать, когда им начнут пользоваться сотни или тысячи клиентов.
Что дает: позволяет выявить проблемные места сборки до того, как их обнаружит конечный потребитель; повышает качество сборки.

Практика 7.

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