В разговорах о DevOps можно услышать множество понятий. На самом деле они не принадлежат движению DevOps. Это идеи, о которых мы уже слышали. Управление проектами, управление корпоративным контентом, Agile, Application Lifecycle Management (ALM) — лишь некоторые из исторических движений, которые использовали эти понятия с той же целью — идти вперед быстрее.
DevOps никогда не заканчивается. Это процесс, позволяющий постоянно улучшаться. Если вы думаете, что подошли к концу DevOps, значит, вы делаете что-то не так.
Читайте далее, чтобы узнать, почему DevOps — бесконечный процесс и почему понимание этой концепции важно для правильного использования DevOps.
Нежизнеспособный
Причина, по которой предыдущие движения перестали прогрессировать, заключается в том, что они определяли конечную точку.
Такие движения, как DevOps, должны быть основой. Вы — организация, которая использует структуру DevOps для выполнения работы. Это значит, что DevOps управляет всем.
Конечно, есть удобство в определении даты завершения. Более того, в традиционной корпоративной культуре это необходимо. Это связано с тем, что структура большинства предприятий — компенсация, основанная на проектах, которые были подписаны бизнес-пользователями.
Но видение DevOps как проекта приведет к тому, что проект будет казаться слишком долгим, завершение устаревшим, а функциональность — Франкенштейном, который является порождением слишком большого количества ресурсов среднего развития.
Если внедрить DevOps с практикой управления проектами Waterfall, то DevOps не будет проектом. А если и будет, то его результат будет очевидным.
Неправильный подход к DevOps
Когда организации рассматривают DevOps как конечный процесс, результатом становится автоматизация, которую невозможно адаптировать
Такой подход позволяет быть современным, но недолго. В конечном счете систему постигнет та же участь, что и Waterfall или любой другой процесс по улучшению проектов. Система устареет, и пользователи будут кричать: «Она не работает!»
Такой результат неизбежен потому, что новые языки программирования, инструменты автоматизации, структуры и инфраструктуры появляются ежедневно. И ваша организация и клиенты требуют, чтобы вы использовали эти усовершенствованные инструменты и процессы для создания лучших приложений. Но только что созданная среда DevOps не адаптировалась к усовершенствованиям.
Как выглядит «успех»
В среде разработки, основанной на методологии DevOps, успех постоянно измеряется. Он измеряется релизами и автоматизацией или количеством ошибок. Оба способа сосредоточены на результатах. Результаты связаны с приложениями, созданными средой, а не с внутренними контрольными списками.
Успешная среда разработки может использовать новую инфраструктуру, заменять исходные репозитории и внедрять новые инструменты тестирования, не обновляя конвейерную обработку. Это не значит, что изменения не происходят и не контролируются. Контроль изменений — не синоним Waterfalls. Это означает, что нет фиксированности.
Это делается через сосредоточение внимания на цепочке доставки программного обеспечения как самостоятельной. Цепочка будет иметь свои версии и станет мета-приложением для всего, над чем работает команда разработчиков. Но изменения могут быть сделаны итеративно и непрерывно при хорошо продуманной архитектуре.
Работа DevOps-инженеров никогда не заканчивается
Вот почему появилось новое название должности: DevOps-инженер. DevOps-инженер — инженер, осведомленный обо всех IT-процессах и процессах, связанных с созданием приложений. DevOps-инженер управляет процессами и может найти нужную технологию для выполнения работы. Он отвечает за построение как конвейерной стратегии, так и автоматизации. Таким образом, работа не заканчивается.
DevOps-инженер не диктует. Он выявляет, что нужно, чтобы релизы выходили чаще и лучшего качества. Это означает, что DevOps-инженер постоянно ищет новые инструменты для выполнения работы. Успех — улучшение цепочки поставок в течение определенного периода времени. Если релизы растут, а количество ошибок снижается, то DevOps-инженер продемонстрировал свою ценность. Но ошибки не исчезают, и релизы не выходят достаточно часто.
Тем не менее DevOps-инженер должен знать, что нужно для решения проблем: какие процессы и инструменты задействованы в восстановлении и самовосстановлении, чтобы проблемы решались тем же темпом или быстрее и чтобы технические неполадки не являлись темой совещаний.
Заключение: вхождение в зону
Очень удобно знать, что команда не только ищет способы итеративно и непрерывно развиваться, но и ориентируется на внешние и внутренние результаты. И это делается для пользователей, а не для завершения проектов ради завершения.
DevOps — это практика и основы, которые организации используют для ускорения релиза программного обеспечения более высокого качества. Это означает, что работа никогда не заканчивается. Это основа нововведений.