1. Обзор
В этой статье мы разберемся с основами принципов и практик DevOps. Мы увидим, почему это актуально и полезно при разработке программного обеспечения. Мы также поймем, как мы можем осмысленно внедрить DevOps и какие инструменты помогут нам в этом путешествии.
2. Исторический контекст
Мы не сможем оценить DevOps в его нынешнем виде, не оглянувшись немного в историю. Первые дни разработки программного обеспечения в основном характеризовались тем, что мы называем методологией водопада. Фактически это означает, что программное обеспечение последовательно концептуализировалось, проектировалось, разрабатывалось, тестировалось и распространялось .
Каждый шаг был максимально детализирован, так как обратный путь стоил очень дорого . На самом деле это означало гораздо более длительный период ожидания между мыслью и действием. Однако это не было такой проблемой, поскольку технологический ландшафт был гораздо менее изменчивым, а сбои были слишком распространены.
Интересно, что эта модель просуществовала недолго. Поскольку темпы развития технологий изменились, и сбои стали происходить часто, предприятия начали ощущать жару. Им нужно было быстрее тестировать новые идеи . Это означало более быстрые изменения во всех аспектах бизнеса, включая программное обеспечение.
Это породило совершенно новый мир методологий разработки программного обеспечения, которые в общих чертах рассматриваются под эгидой Agile. Agile-манифест устанавливает набор принципов, которым необходимо следовать при доставке программного обеспечения небольшими порциями с более быстрым циклом обратной связи . На практике существует несколько гибких фреймворков, таких как Scrum и Kanban .
3. Что такое DevOps ?
Мы видели, что поэтапная разработка с более быстрой обратной связью стала сегодня краеугольным камнем доставки программного обеспечения. Но как этого добиться? Хотя традиционные гибкие методологии приводят нас к разумной точке, она все же не идеальна.
Гибкие методологии продолжают совершенствоваться, поскольку они постоянно стремятся сломать разрозненность.
Традиционно у нас всегда были разные команды, которые отвечали за разработку и поставку программного обеспечения. Эти команды часто действовали изолированно. Это фактически привело к гораздо более длинному циклу обратной связи, чего мы не желаем при использовании гибких методологий.
Таким образом, не требуется много рассуждений, чтобы понять, что хорошо интегрированные межфункциональные agile-команды гораздо лучше подходят для достижения своих целей. DevOps — это практика, которая поощряет общение, совместную работу, интеграцию и автоматизацию между командами разработки программного обеспечения и эксплуатации . Это лучше позволяет нам реализовывать поэтапное развитие с более быстрой обратной связью.
Следующая диаграмма объясняет возможный рабочий процесс для практики DevOps:
Хотя мы подробно рассмотрим эти шаги позже в этом руководстве, давайте разберемся с некоторыми ключевыми принципами DevOps:
- Ценностно-ориентированный подход (в понимании конечного пользователя)
- Культура сотрудничества (с эффективной коммуникацией, процессами и инструментами)
- Автоматизация процессов (для повышения эффективности и уменьшения ошибок)
- Измеримые результаты (для измерения относительно целей)
- Непрерывная обратная связь (с тенденцией к быстрому улучшению)
4. Как начать путешествие?
Хотя теория проста и привлекательна, настоящие проблемы заключаются в осмысленном применении DevOps. Как мы уже выяснили, DevOps в основном касается людей, а не команд .
Общие цели, эффективная коммуникация и кросс-функциональные навыки являются отличительными чертами таких команд. Поскольку большая часть этих изменений связана с культурой, они часто происходят медленно и не без трения.
4.1. Мотивация
Тот факт, что существует популярная практика, не обязательно делает ее подходящей для нас. Нам нужно понять нашу мотивацию для любого перехода — тем более, если мы вносим изменения в сторону гибкости. Полезно определить цели, которых мы хотим достичь .
Цели DevOps в любой организации зависят от амбиций, культуры и зрелости этой организации. Вот некоторые из наиболее распространенных целей DevOps:
- Лучший опыт для конечных пользователей
- Более быстрый выход на рынок
- Улучшенное среднее время восстановления
4.2. Принятие
Помните, что DevOps — это не конечное состояние, а непрерывный процесс улучшения для достижения целей. Следовательно, каждый в команде должен стремиться выявлять препятствия и быстро их устранять . Вот несколько действий, которые могут помочь нам начать:
- Четко понимать текущее состояние идеи производственного цикла
- Соберите некоторые из очевидных узких мест и используйте метрики для принятия фактических решений.
- Определите приоритеты узких мест, которые добавят наибольшую ценность при устранении.
- Определите итеративный план для постепенного предоставления ценности приоритетным элементам.
- Следуйте коротким циклам «Разработка-Развертывание-Измерение» для достижения целей.
5. Практики DevOps
Есть несколько практик, которым нужно следовать, но идея не должна использовать какую-либо из них в качестве золотого стандарта. Мы должны тщательно изучить каждую практику на фоне нашего состояния и целей, а затем принимать обоснованные решения. Однако почти все практики стремятся максимально автоматизировать процессы.
5.1. Гибкое планирование
Agile-планирование — это практика определения работы небольшими шагами. Хотя конечная цель должна быть ясной, нет необходимости заранее определять и детализировать все приложение. Ключевым моментом здесь является расстановка приоритетов в работе на основе ценности, которую она может принести .
Затем его следует разбить на итерацию коротких, но функционирующих приращений.
5.2. Инфраструктура как код (IaC)
Это практика управления и предоставления инфраструктуры с помощью машиночитаемых файлов конфигурации . Мы также управляем этими конфигурациями в системе контроля версий, как мы управляем нашей кодовой базой. Существует много предметно-ориентированных языков для декларативного создания этих файлов конфигурации.
5.3. Автоматизация тестирования
Тестирование программного обеспечения традиционно выполнялось вручную, часто разрозненно. Это плохо сочетается с гибкими принципами. Следовательно, крайне важно, чтобы мы пытались автоматизировать тестирование программного обеспечения на всех уровнях, таких как модульное тестирование, функциональное тестирование, тестирование безопасности и тестирование производительности .
5.4. Непрерывная интеграция (CI)
Непрерывная интеграция — это практика более частого слияния рабочего кода небольшими порциями в общий репозиторий . Обычно в этом общем репозитории часто выполняются автоматические сборки и проверки, чтобы как можно скорее предупредить нас о любых нарушениях кода.
5.5. Непрерывная доставка/развертывание (CD)
Непрерывная поставка — это практика выпуска программного обеспечения небольшими порциями, как только оно проходит все проверки . Это часто практикуется вместе с непрерывной интеграцией и может выиграть от автоматического механизма выпуска (называемого непрерывным развертыванием).
5.6. Непрерывный мониторинг
Мониторинг — возможно, центр DevOps — обеспечивает более быструю обратную связь. Определение правильных показателей для мониторинга всех аспектов программного обеспечения, включая инфраструктуру, имеет решающее значение . Наличие правильных показателей в сочетании с эффективной аналитикой в режиме реального времени может помочь быстрее выявлять и решать проблемы. Более того, он напрямую связан с agile-планированием.
Этот список далеко не полный и постоянно пополняется. Команды, практикующие DevOps, постоянно ищут лучшие способы достижения своих целей. Некоторые из других практик, о которых стоит упомянуть, — это контейнеризация, облачная разработка и микросервисы, и это лишь некоторые из них.
6. Торговые инструменты
Обсуждение DevOps невозможно без обсуждения инструментов. Это одна из областей, где за последние несколько лет произошел взрыв. К тому времени, когда мы закончим читать этот урок, может появиться новый инструмент! Хотя это заманчиво и ошеломляюще одновременно, необходимо проявлять осторожность.
Мы не должны начинать свой путь DevOps с инструментов в первую очередь. Мы должны изучить и установить наши цели, людей (культуру) и практики, прежде чем найти правильные инструменты . Разобравшись с этим, давайте посмотрим, какие из проверенных временем инструментов нам доступны.
6.1. Планирование
Как мы видели, зрелый DevOps всегда начинается с гибкого планирования. Несмотря на ясность целей, необходимо только расставить приоритеты и определить работу для нескольких коротких итераций. Отзывы об этих ранних итерациях бесценны для формирования будущих и, в конечном счете, всего программного обеспечения. Эффективный инструмент поможет нам с легкостью осуществить этот процесс.
Jira — это продукт для отслеживания проблем с самым высоким рейтингом, разработанный Atlassian. Он имеет множество встроенных инструментов гибкого планирования и мониторинга. По большому счету, это коммерческий продукт, который мы можем либо запускать локально, либо использовать в качестве размещенного приложения.
6.2. Разработка
Идея Agile заключается в том, чтобы быстрее создавать прототипы и получать отзывы о фактическом программном обеспечении. Разработчики должны вносить изменения и быстрее объединяться в общую версию программного обеспечения. Еще более важно, чтобы общение между членами команды было плавным и быстрым.
Давайте рассмотрим некоторые повсеместно распространенные инструменты в этой области.
Git — это распределенная система контроля версий. Он довольно популярен, и существует множество размещенных сервисов, предоставляющих репозитории git и дополнительные функции. Первоначально разработанный Линусом Торвальдсом, он делает сотрудничество между разработчиками программного обеспечения весьма удобным.
Confluence — это инструмент для совместной работы, разработанный Atlassian . Сотрудничество — ключ к успеху любой agile-команды. Фактическая семантика совместной работы довольно контекстуальна, но инструмент, который делает усилия плавными, тем не менее бесценен. Confluence точно соответствует этому месту. Кроме того, он хорошо интегрируется с Jira!
Slack — это платформа для обмена мгновенными сообщениями, разработанная Slack Technologies. Как мы уже говорили, agile -команды должны иметь возможность сотрудничать и общаться, предпочтительно в режиме реального времени . Помимо обмена мгновенными сообщениями, Slack предлагает множество способов общения с одним пользователем или группой пользователей — и он хорошо интегрируется с другими инструментами, такими как Jira и GitHub!
6.3. Интеграция
Изменения, вносимые разработчиками, должны постоянно проверяться на соответствие. То, что представляет собой соответствие, зависит от команды и приложения. Тем не менее, статический и динамический анализ кода, а также измерения функциональных и нефункциональных метрик обычно рассматриваются как компоненты соответствия требованиям.
Давайте кратко рассмотрим пару популярных инструментов интеграции.
Jenkins — это привлекательный бесплатный сервер автоматизации с открытым исходным кодом. Он существует в отрасли уже много лет и достаточно созрел, чтобы обслуживать широкий спектр вариантов использования автоматизации. Он предлагает декларативный способ определения подпрограммы автоматизации и множество способов запускать ее автоматически или вручную. Кроме того, он имеет богатый набор плагинов, которые служат нескольким дополнительным функциям для создания мощных конвейеров автоматизации.
SonarQube — это платформа непрерывного контроля с открытым исходным кодом, разработанная SonarSource. SonarQube имеет богатый набор правил статического анализа для многих языков программирования. Это помогает обнаруживать запахи кода как можно раньше. Кроме того, SonarQube предлагает панель инструментов, которая может интегрировать другие показатели, такие как покрытие кода, сложность кода и многие другие. И это хорошо работает с Jenkins Server.
6.4. Доставка
Очень важно быстро вносить изменения и новые функции в программное обеспечение. Как только мы установим, что внесенные в репозиторий изменения соответствуют нашим стандартам и политикам, мы сможем быстро доставить их конечным пользователям. Это помогает нам собирать отзывы и улучшать программное обеспечение.
Здесь есть несколько инструментов, которые могут помочь нам автоматизировать некоторые аспекты доставки до такой степени, что мы обеспечим непрерывное развертывание.
Docker — распространенный инструмент для быстрой контейнеризации любого типа приложений. Он использует виртуализацию на уровне ОС для изоляции программного обеспечения в пакетах, называемых контейнерами. Контейнеризация имеет непосредственное преимущество с точки зрения более надежной доставки программного обеспечения . Контейнеры Docker взаимодействуют друг с другом по четко определенным каналам. Кроме того, это довольно легко по сравнению с другими способами изоляции, такими как виртуальные машины.
Chef / Puppet / Ansible — инструменты управления конфигурацией. Как мы знаем, фактически работающий экземпляр программного приложения представляет собой комбинацию сборки кодовой базы и ее конфигураций. И хотя сборка кодовой базы часто неизменна в разных средах, конфигурации — нет. Именно здесь нам нужен инструмент управления конфигурацией для простого и быстрого развертывания нашего приложения . В этой области есть несколько популярных инструментов, каждый из которых имеет свои особенности, но Chef, Puppet и Ansible в значительной степени охватывают основы.
HashiCorp Terraform может помочь нам с предоставлением инфраструктуры , что было утомительной и трудоемкой задачей со времен частных центров обработки данных. Но по мере все большего распространения облачных технологий инфраструктура часто рассматривается как одноразовая и повторяемая конструкция. Однако этого можно достичь, только если у нас есть инструмент, с помощью которого мы можем декларативно определять простую и сложную инфраструктуру и создавать ее одним нажатием кнопки . Это может звучать как мечта, но Terraform активно пытается заполнить этот пробел!
6.5. Мониторинг
Наконец, очень важно иметь возможность наблюдать за развертыванием и измерять его по целям. Может быть множество метрик, которые мы можем собирать из систем и приложений. К ним относятся некоторые бизнес-показатели, характерные для нашего приложения.
Идея состоит в том, чтобы иметь возможность собирать, обрабатывать, хранить и анализировать эти показатели практически в режиме реального времени. В этом пространстве доступно несколько новых продуктов, как с открытым исходным кодом, так и коммерческих.
Elastic-Logstash-Kibana (ELK) — это набор из трех проектов с открытым исходным кодом — Elasticsearch, Logstash и Kibana. Elasticsearch — это масштабируемая поисковая и аналитическая система. Logstash предоставляет нам конвейер обработки данных на стороне сервера, способный использовать данные из самых разных источников. Наконец, Kibana помогает нам визуализировать эти данные. Вместе этот стек можно использовать для агрегирования данных, таких как журналы, из всех приложений и их анализа в режиме реального времени .
Prometheus — это инструмент системного мониторинга и оповещения с открытым исходным кодом, изначально разработанный SoundCloud. Он поставляется с многомерной моделью данных, гибким языком запросов и может извлекать данные временных рядов по HTTP. Grafana — еще одно решение для аналитики и мониторинга с открытым исходным кодом , которое работает с несколькими базами данных. Вместе Prometheus и Grafana могут в реальном времени обрабатывать практически любые показатели, которые способны производить наши системы .
7. Расширения DevOps (или это действительно так!)
Мы видели, что DevOp, по сути, представляет собой непрерывную работу по устранению препятствий на пути к более быстрой и итеративной доставке программного обеспечения на основе ценности. Итак, один из непосредственных выводов состоит в том, что здесь не может быть конечного состояния.
То, что люди осознали как трения между командами разработки и эксплуатации, не является единственными трениями. Основная идея — разрушение разрозненности внутри организации для расширения сотрудничества. Вскоре люди начали понимать, что между командами разработки и тестирования, а также между командами разработки и безопасности существуют аналогичные трения . Многие традиционные установки имеют специальные группы безопасности и производительности.
Полный потенциал DevOps невозможно реализовать до тех пор, пока мы не разрушим почти все границы между командами и не поможем им сотрудничать более эффективно. По своей сути это означает объединение команд, занимающихся тестированием, безопасностью и производительностью .
Путаница в основном в его номенклатуре. DevOps дает нам понять, что в основном речь идет о командах разработки и эксплуатации. Следовательно, со временем появились новые термины, охватывающие другие команды. Но по большому счету просто DevOps реализуется эффективнее!
7.1. DevTestOps
Краеугольным камнем DevOps является поставка высококачественного программного обеспечения небольшими порциями и чаще. Здесь есть много аспектов акцента на качестве. В некотором смысле мы часто предполагаем, что применяемые нами методы DevOps помогут нам достичь этого. Верно также и то, что многие из практик, которые мы обсуждали ранее, сосредоточены на постоянном обеспечении высокого качества.
Но функциональное тестирование программного обеспечения имеет гораздо более широкую сферу применения. Довольно часто мы склонны проводить тестирование более высокого порядка, такое как сквозное тестирование, ближе к концу поставки программного обеспечения. Что еще более важно, за это часто отвечает отдельная команда, которая вступает в процесс на поздних этапах. Именно здесь начинаются отклонения от принципов DevOps.
Что нам лучше сделать, так это интегрировать тестирование программного обеспечения на всех уровнях с самого начала . Уже на этапе планирования тестирование программного обеспечения следует рассматривать как неотъемлемую часть поставки. Более того, одна и та же команда должна нести ответственность за разработку и тестирование программного обеспечения. Именно так широко известна практика DevTestOps. Это часто также называют непрерывным тестированием и сдвигом влево.
7.2. DevSecOps
Безопасность является неотъемлемой частью любой разработки программного обеспечения и имеет свою долю сложности. Часто это означает, что у нас есть отдельная команда специалистов по безопасности, с которой мы взаимодействуем, когда готовы выпустить продукт. Уязвимости, которые они выявляют на этом этапе, могут быть дорогостоящими для устранения. Это опять же не очень хорошо согласуется с принципами DevOps.
К этому времени у нас уже должно быть решение, которое нужно применить, а именно, мы должны привлечь внимание к вопросам безопасности и персоналу в самом начале игры . Мы должны мотивировать команды думать о безопасности на каждом этапе. Безопасность, без сомнения, является очень специализированной областью, и, следовательно, нам может понадобиться привлечь специалиста в команду. Но идея здесь состоит в том, чтобы рассмотреть некоторые из лучших практик с самого начала.
По мере продвижения вперед появляется несколько доступных инструментов, которые могут автоматизировать сканирование на наличие большого количества уязвимостей . Мы также можем включить это в наши циклы непрерывной интеграции, чтобы получить быструю обратную связь! Теперь мы не можем интегрировать все в непрерывную интеграцию, поскольку мы должны сделать ее легкой, но всегда могут быть другие периодические проверки, работающие отдельно.
8. Заключение
В этой статье мы рассмотрели основы принципов, практик и инструментов DevOps, доступных для использования. Мы поняли контекст, в котором DevOps актуален, и причины, по которым он может быть нам полезен. Мы также кратко обсудили, с чего начать внедрение DevOps.
Кроме того, мы коснулись некоторых популярных практик и инструментов, которые мы можем использовать в этом путешествии. Мы также разобрались с некоторыми другими популярными терминами, связанными с DevOps, такими как DevTestOps и DevSecOps.
Наконец, мы должны понимать, что DevOps — это не конечное состояние, а скорее путешествие, которое может никогда не закончиться! Но самое интересное здесь — это само путешествие. При этом мы никогда не должны упускать из виду наши цели и должны сосредоточиться на ключевых принципах. Довольно легко поддаться блеску популярного инструмента или термина в отрасли. Но мы всегда должны помнить, что все полезно только в том случае, если помогает нам более эффективно донести ценность до нашей аудитории.