DevOps внутри и снаружи: что это за культура и зачем на нее переходить

Помните такую индийскую притчу о слепых и слоне: когда слепым людям дали потрогать слона и попросили поделиться впечатлениями? У каждого была своя история о том, что есть слон, потому что ему довелось коснуться разной его части. С DevOps – похожая ситуация. Многие слышали об этом новом модном термине, который касается разработки программного обеспечения, некоторые даже сталкивались с отдельными ее частями, но все равно не представляют себе, что есть слон (то есть DevOps) с головы до пят. В этой статье мы постараемся разобраться в том, что же под собой подразумевает этот модный термин, который успел называться и культурой, и философией, и методологией разработки.

Откуда взялся DevOps?

Если стереть романтический налет, то DevOps – это культура разработки программного обеспечения, которая подразумевает, что разработчики ПО и IT-отделение тесно взаимодействуют друг с другом в рамках одного проекта. Это взаимодействие позволяет ускорить цикл выпуска новых программных продуктов и повысить эффективность работы команды.

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

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

Мир, где все держалось на крупных компаниях и бородатых админах, ушел в прошлое

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

Собственные приложения и сервисы срочно понадобились всем: и носителям бороды, и производителям смузи

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

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

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

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

Хорошая новость заключается в том, что стать таким специалистом – вполне выполнимая задача (конечно, если личностные особенности соответствуют требованиям профессии). Чтобы освоить новую специальность, не нужно переучиваться полностью и получать новые навыки – что всегда долго и страшно. Если программист захочет стать DevOps, ему нужно будет немного разобраться в том, как внедрять продукты. IT-специалисту, соответственно, подтянуть знания по программированию и автоматизации тестирования. Но ни тем, ни другим не придется открывать для себя Америку снова. Потребность в DevOps-специалистах есть, особенно на развитых рынках, и она растет. То есть это не сиюминутная прихоть, в результате которой можно потратить много времени непонятно на что, бесконечно отстать от реалий профессии и остаться не у дел.

Чем занимается DevOps в команде?

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

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

DevOps-специалист должен взаимодействовать с архитектором проекта в самом начале, чтобы в итоге получился продукт, который можно будет максимально безболезненно дорабатывать и масштабировать по мере того, как старый клиент (наверняка) будет обращаться с заказом новых фич или адаптацией продукта под изменение реалий его бизнеса. С разработчиками – чтобы не дублировались те вещи, которые были ранее созданы и весь код находился в гармонии с уже существующим продуктом. Со специалистами по внедрению – чтобы и этот процесс происходил максимально эффективно.

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

Еще одна хорошая новость: чтобы реализовать на практике все описанные выше вещи, нет необходимости внедрять и осваивать новые и непонятные технологии. Задачи DevOps решаются привычными инструментами. Использование облачных технологий (таких как, например, Microsoft Azure и им подобных, которые дают возможность абстрагироваться от инфраструктуры и использовать только необходимые проекту ресурсы) позволит сделать процесс разработки с DevOps проще, быстрее и надежнее.

Главное для DevOps – это облако

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