Что такое методология DevOps и кому она нужна
О DevOps всё чаще пишут в иностранных и российских изданиях. Попробуем разобраться, в чём суть методологии и кому она может принести пользу.
Что такое DevOps
DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании. Если ИТ-специалисты из разных отделов недопонимают суть задач друг друга, выпуск новых приложений и обновлений для них затягивается.
DevOps формирует «бесшовный» цикл разработки, тем самым помогая ускорить выпуск программного продукта.
Ускорение достигается за счет внедрения систем автоматизации. Плюс программисты начинают участвовать в настройке серверов и поиске багов, например, они могут писать автоматизированные тесты.
Таким образом налаживается взаимодействие между отделами. Сотрудники начинают лучше понимать, какие этапы проходит программный продукт перед тем, как попасть в руки пользователя.
Когда разработчик понимает, с чем сталкивается администратор при настройке сервера, он постарается сгладить возможные «острые углы» в коде. Это сокращает количество багов при развертке приложения — по статистике оно уменьшается примерно в пять раз.
Кому нужна и не нужна методология
Многие ИТ-эксперты считают, что DevOps принесет пользу любой организации, которая занимается разработкой ПО. Это справедливо даже в том случае, если компания является простым потребители ИТ-сервисов и не разрабатывает собственные приложения. В этом случае внедрение DevOps-культуры поможет сконцентрироваться на инновациях.
Исключение составляют стартапы, но и здесь все зависит от масштабов проекта. Если ваша цель — запустить минимально жизнеспособный продукт (minimum viable product, MVP), чтобы протестировать новую идею, то можно обойтись и без DevOps. Например, основатель Groupon в начале работы над сервисом сам вручнуюразмещал все предложения на сайте и собирал заказы. Никаких инструментов автоматизации он не использовал.
Внедрять методологию и инструменты автоматизации имеет смысл только тогда, когда приложение начинает набирать популярность. Это поможет наладить бизнес-процессы и ускорить выход обновлений.
Как внедрить DevOps
Далее — несколько рекомендаций для перехода на новую методологию.
Выявите проблемы в бизнес-процессах. Перед внедрением методологии выделите цели и проблемы организации. От них будет зависеть стратегия перехода на DevOps. Для этого составьте список вопросов, например:
- На что уходит больше всего времени при обновлении ПО?
- Можно ли автоматизировать этот процесс?
- Влияет ли на это структура организации?
Подробно о выявлении проблем в организации можно почитать в книгах «Проект „Феникс“» и «Руководство по DevOps» от авторов методологии.
Поменяйте культуру в компании. Важно убедить всех сотрудников изменить привычные способы работы и расширить свой спектр компетенций. Например, в Facebook все программисты отвечают за жизненный цикл приложения целиком: от написания кода до внедрения. Также в Facebook нет отдельного отдела тестирования — тесты пишут сами разработчики.
Начните с малого. Выберите процесс, который отнимает больше всего времени и сил при выпуске обновлений, и автоматизируйте его. Это может быть тестирование или процесс развертывания приложений.
Эксперты советуют первым делом внедрить инструменты распределенного контроля версий. С ними проще управлять исходниками. Среди таких решений наиболее известны Git, Mercurial, Subversion (SVN) и CVS.
Также стоит обратить внимание на системы непрерывной интеграции, ответственные за сборку и тестирование конечного продукта. Примеры таких инструментов: Jenkins, TeamCity и Bamboo.
Оценивайте улучшения. Разработайте метрики эффективности внедренных решений и составьте чек-лист. Метриками могут служить частота релизов, время работы над программными функциями, количество багов в коде.
Обсуждайте результаты не только с менеджерами, но и с остальной командой, занятой на проекте. Спрашивайте, каких инструментов не хватает. Учитывайте эти запросы при дальнейшей оптимизации процессов.
Критика DevOps
Есть мнение, что программисты не должны разбираться в деталях работы системных администраторов. Якобы DevOps приводит к тому, что в компании вместо специалистов по разработке или администрированию появляются люди, разбирающиеся во всем, но поверхностно.
Также считается, что DevOps не работает при плохом менеджменте. Если у команд разработчиков и администраторов нет общих целей, в этом виноваты менеджеры, которые не организуют взаимодействие между командами. Чтобы решить эту проблему, нужна не новая методология, а система оценки менеджеров на основе отзывов от подчиненных. Вот здесь можно почитать, какие вопросы следует включать в формы опросов для сотрудников.
Подведем итог — как внедрить DevOps:
- Сформулируйте задачи, которые должна решить новая методология.
- Обсудите решение с командой. Выслушайте мнения сотрудников и определите, какие инструменты автоматизации имеет смысл внедрить.
- Автоматизируйте часть IT-процессов. Начните с задач, которые наибольшим образом годятся для автоматизации.
- Анализируйте метрики. Соотносятся ли усилия на внедрение DevOps с пользой, которую приносит методология? Если нет, стоит изменить подход к внедрению или попробовать другую методологию разработки. Если да, продолжайте внедрять и анализировать новые инструменты.
Что еще почитать в выходные:
Всегда был уверен, что DevOps - не методология, а вполне себе специальность человека, который занимается внедрением ПО вкупе с настройкой CI/CD, контейнеризацией и тд.
Спасибо, что прочитали.
В следующем материале как раз будет рассказ о работе DevOps-инженера: чем занимается такой специалист, какие компании нанимают, как в этой сфере развиваться и так далее.
Ага, у меня в конторе пару лет хотят внедрить DevOPS, даже соответствующие должности появились. Но кажется, за год никто так и не понял, кто такой DevOPS и для чего он нужен. Такое ощущение, что просто хотят ухватиться за 'моду'.
Хотелось бы рассмотреть более конкретные примеры взаимодействия DevOPS с администраторами и разработчиками.
Комментарий недоступен
"Mercurial, Subversion (SVN) и CVS" - автор из берлоги вышел, где писал 5 лет статью?
"DevOps — это методология разработки ПО, задача которой наладить взаимодействие программистов и сисадминов в компании."
Написано странно и непонятно.
Как это зародилось в реале: DevOps родился как ответ на проблему, когда серверов стало много, а конфигурация и развертываение(deployment) приложений стали настолько сложны, что обычные сисадмины стали для этого неэффективны. Поэтому начали набирать отдельных программистов DevOps, которые еще что-то понимали в сисадминстве и могли писать сценарии для deployment, конфигурировать сервера в облаках и адаптировать приложения под новые реалии.
Нужен ли Вам отдел DevOps или нет - зависит, соответственно, от количества серверов, количества и сложности приложений и навыков текущих сисадминов, может они уже по факту и так исполняют DevOps :)
Посмеялась ;)
А разве одмин не может пользоваться например puppet или на крайний случай этому бездельнику могут и контейнер сразу подкидывать .
Затраты при devops больше, но про это почему-то ни слова нет.
test и stage-среды нужно где-то разворачивать, надо их поддерживать ( даже на уровне chef/puppet в связке с Docker/OpenVZ )
кол-во тестов в итоге начинает превышать кол-во кода и контора начинает дружно писать тесты для тестов тестов