Если посмотреть на девяностые годы прошлого века, то они дали большое количество методологий (если кому больше нравиться фреймворков) разработки программного обеспечения: FDD (Feature driven development), Scrum, Rup, XP. Но самыми востребованными оказались не технические подходы, а ориентированные на людей. В 2001 году это все привело к появлению Agile-манифеста. Не надо нам качества, не надо нам поддержки изменений, дайте нам быстро то, на что можно посмотреть, а уж мы примем решение, что делать дальше. В настоящее время складывается ощущение, что социальные факторы себя исчерпали и для дальнейшего повышения скорости их уже не хватает. Подход, включающий не только «про людей», но и «про технологии», получил название DevOps. Давайте посмотрим на чем еще мы можем выиграть в скорости поставки полезности.

Если посмотреть на Agile-манифест, на то, что входит в Scrum, Kanban, то там все про людей. Про взаимодействие внутри команды, про взаимодействие с заказчиком, про организационные процессы. Нет, в FDD и XP, которые тоже относят к гибким методологиям, есть и инженерные вещи (кто, кстати, может сходу вспомнить, что там из инженерного в FDD?). И это работает. Собирая умных людей в одном месте, давая им организационные шаблоны, помогая организовать взаимодействие с заказчиком можно получить приемлемый, а зачастую и отличный результат.

Только вот, с возрастанием сложности разрабатываемых систем выясняется, что не все так радужно. Даже умным людям нужны инженерные практики, чтобы продолжать выдавать приемлемый результат в кратчайшие сроки. Понятно, что все уже придумано достаточно давно, взять тот-же «Тест Джоэла: 12 шагов к лучшему коду», и обнаружить, что ничего изобретать не надо. Но почему-то до сих пор можно встретить организации, в которых не используются билд-сервера. И в рамках борьбы с этим перекосом в сторону социально-организационных вопросов и появился DevOps. В отличии от других методологий, у которых есть родоначальники, а зачастую и целые институты, занимающиеся их разработкой (PMBOK разрабатывает PMI, ITIL разрабатывает AXELOS, да и под Agile-манивестом, подписанным в феврале 2001 в штате Юта США, стоят конкретные фамилии), что такое DevOps до сих пор вызывает споры и недопонимание. Нет, есть статья в википедии, проводятся конференции, но формального описания, что входит в DevOps, с которым все сообщество или хотя-бы большая часть разработчиков согласилась, нет.

Компания Gartner попыталась провести систематизацию подходов, применяемых в DevOps:

*источник изображения Gartner.

Как видно из картинки, DevOps включает в себя и то, за что ратует Agile: автономные, кросфункциональные команды; культуру доверия; совместные митинги. Но при все при этом, основной упор делается именно на технологии. Можете ли вы развернуть свое приложение в один клик? Используете ли вы непрерывную интеграцию и тестирование? Если на эти и многие другие вопросы, которые можно задать по блокам с картинки, ответа нет, то это и есть варианты совершенствования команд, процессов, продуктов в организации.

Возьмем для примера ChatOps. Эта практика подразумевает, что в командном чате собирается не только переписка, но и информация о запущенных билдах, внесенных изменениях в код и требования, ошибки, возникшие в продуктиве. Т.е. разработчику уже не надо отслеживать кучу мест (почту, всплывающие сообщения BuildAgent-а, командный чат). Все собирается в одном месте. А ведь в чате может присутствовать бот, который по команде разработчика может: инициировать развертывания в тестовую или даже боевую среду, даст информацию о прогрессе итерации, выдаст перечень критических ошибок и т.д. Большинство современных мессенджеров имеют API и реализовать такого бота не составляет большой проблемы.

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

Коллеги, поделитесь в комментариях, что вы используете из приведенных практик, чтобы экономить время? Или может у вас есть что-то не включенное в схему Gartner, но реально очень полезное? Да, если есть желание рассказать об этом не только на Хабре, то можно зарегистрироваться в качестве докладчика на DevOpsDays и обсудить ваш подход еще и в личном общении с людьми, которым это все очень интересно. Конференция пройдет 11 Марта этого года, и официальная продажа билетов уже началась. Посмотреть стоимость билеты можно по здесь. И вот вам небольшой подарок от меня лично. Первые 5 человек, которые напишут мне в ЛС или в комментарии, получат промо-код на скидку для покупки билетов.

DevOps — cкорость? Да, скорость