Логотип компании Goodbit
Евгений

Евгений

Руководитель DevOps Отдела

Внедрение DevOps

С чего начать и как добиться успеха?

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

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

Типичная ситуация, предшествующая DevOps

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

Внутренняя, аутсорсинговая или частично аутсорсинговая разработка программного обеспечения

Традиционно существует три основных варианта организации разработки программного обеспечения:

  • Программное обеспечение разрабатывается собственной командой компании с большим количеством финансовых и человеческих ресурсов, выделенных для процесса разработки.
  • Разработка программного обеспечения передается на аутсорсинг третьему лицу, в случае нехватки ИТ-ресурсов для разработки.
  • Разработка программного обеспечения осуществляется собственными силами, но, например, обеспечение качества (QA) делегируется стороннему поставщику услуг QA из-за пробела в компетенциях QA в компании.

Строгое разделение обязанностей между отделами, занимающимися разработкой

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

Обязанности департаментов строго разделены, а сотрудничество между ними слабое. Администраторы безопасности представляют собой еще один независимый отдел, который часто воспринимается как «препятствие» в цикле разработки программного обеспечения, поскольку их усилия по выявлению слабых мест безопасности в приложении (и усилия разработчиков по их дальнейшему исправлению) приводят к затягиванию проекта.

Недостаточный охват тестами

Разработчики пишут модульные тесты для индивидуальной проверки функционирования каждой самой маленькой тестируемой части программного обеспечения на ранней стадии разработки.

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

Высокая вероятность ошибок после выпуска

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

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

  • Конфигурации тестовых и производственных сред.
  • Создавайте версии, развернутые в рабочей и тестовой среде.

Отсутствие доверия пользователей к качеству программного обеспечения

Из-за серьезных пост-релизных ошибок бизнес-пользователи не уверены в качестве программного обеспечения и вынуждены проводить тщательное ручное приемочное тестирование.

И поскольку потенциальные пользователи заняты своими основными обязанностями, их обратная связь приходит со значительными задержками.

Недели для обновлений и исправлений

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

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

Трудоемкое развертывание инфраструктуры

Системные администраторы тратят дни или даже недели на подготовку новой инфраструктуры разработки, тестирования и производства для нового проекта.

Неправильные конфигурации часто происходят из-за ручного характера подготовки инфраструктуры. Модификации и тюнинг занимают еще больше времени.

Чего ожидать от DevOps

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

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

Постоянная коммуникация между командами, занимающимися разработкой программного обеспечения

Системные администраторы тратят дни или даже недели на подготовку новой инфраструктуры разработки, тестирования и производства для нового проекта.

Неправильные конфигурации часто происходят из-за ручного характера подготовки инфраструктуры. Модификации и тюнинг занимают еще больше времени.

Меньшее количество сбоев программного обеспечения, вызванных различиями в конфигурациях инфраструктуры

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

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

Быстрое предоставление новой инфраструктуры

Чтобы быстро подготовить и предоставить новую инфраструктуру для разработки, тестирования и производства, инженеры DevOps применяют подход IaC.

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

Увеличенный объем автоматизации тестирования

Непрерывное тестирование является одним из ключевых компонентов подхода DevOps. Для этого тестирование автоматизируется с использованием специализированных инструментов.

Например, Selenium, Zephyr и Tricentis Tosca, которые предназначены для автоматического выполнения различных типов тестов (таких как модульное, функциональное, интеграционное тестирование) и оперативного уведомления практиков DevOps об обнаруженных ошибках.

Быстрая и надежная доставка обновлений приложений

Благодаря тесному сотрудничеству между командами, связанными с DevOps, и внедрению автоматизации выпуска приложений (ARA), программное обеспечение обновляется быстрее, чем в традиционном процессе разработки программного обеспечения.

ARA позволяет ускорить процесс развертывания новых сборок с минимальным временем простоя и меньшим количеством ошибок конфигурации, обычно возникающих при развертывании новой сборки вручную.

Меньше ошибок после выпуска

С внедрением непрерывного тестирования и выравниванием тестовых и производственных сред команда QA тратит гораздо меньше времени на QA и тестовые мероприятия и пропускает меньше ошибок.

Повышение доверия пользователей

В рамках подхода DevOps скорость автоматизации тестирования увеличивается, а количество ошибок после выпуска снижается.

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

Чего не стоит ожидать от DevOps

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

  • Автоматизация не равна DevOps. Ключевыми компонентами DevOps являются ИТ-специалисты, занимающиеся построением новой культуры DevOps, а также процессы, организованные в рамках этого подхода. Автоматизация является ключевым инструментом для создания и тестирования программного обеспечения, который помогает увеличить скорость выпуска, избегая при этом человеческих ошибок.
  • Внедрение средств DevOps недостаточно для реализации подхода DevOps. Необходимо также принять новые методы. Существует широкий спектр инструментов, необходимых для повышения эффективности реализации DevOps, таких как Ansible, Selenium, Docker, Kubernetes, Octopus и другие. Однако, помимо изучения того, как использовать и настраивать эти инструменты, все участники проекта DevOps должны принять непрерывное тестирование, а также методы непрерывной интеграции и непрерывной доставки (CI / CD) для ускорения доставки программного обеспечения и повышения его качества.
  • Нет необходимости перестраивать организационную структуру, чтобы перейти на DevOps. Для реализации подхода DevOps не требуется отдельного отдела. Обучите существующие команды разработки, тестирования, поддержки, эксплуатации и другие команды, участвующие в разработке программного обеспечения, чтобы они могли правильно настроить инструменты для управления инфраструктурой, мониторинга производительности приложений и т. Д., А также применять новые практики, такие как CI / CD.

План внедрения DevOps

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

Организация инициативы DevOps

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

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

Построение стратегии DevOps

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

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

Контейнеризация

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

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

Интеграция автоматизации инфраструктуры с инструментами CI/CD

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

Такие инструменты автоматизации инфраструктуры, как Kubernetes, Ansible, Chef или Puppet, интегрированы с инструментами CI/CD, такими как Jenkins, Bamboo или GoCD, для более эффективного управления конфигурацией и развертывания программного обеспечения. Например, Kubernetes —для больших инфраструктур — или Ansible — для небольших — позволяет управлять контейнерами для обеспечения отказоустойчивости, мониторинга их работоспособности и скользящих обновлений программного обеспечения, а Jenkins используется для создания, тестирования и развертывания новых сборок в Kubernetes.

Увеличение объема автоматизации тестирования и согласование контроля качества с разработкой

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

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

Обеспечение общего мониторинга производительности приложений

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

Проблемы могут быть выявлены во время мониторинга сервера приложений, мониторинга пользовательского опыта и т.д. Мониторинг производительности приложений позволяет обнаруживать, приоритизировать и изолировать дефекты приложений до того, как конечные пользователи их найдут, а также быстро находить коренные причины ошибок с помощью специального программного обеспечения для мониторинга приложений, такого как Zabbix, Nagios или Prometheus, настроенного для мониторинга конкретного приложения.

Подведение итогов: Переключаться или не переключаться

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

Наиболее ощутимая выгода, которую принесет DevOps, — это более быстрая поставка программного обеспечения без ущерба для качества. Чтобы достичь этого преимущества, вам потребуется трансформировать как процесс разработки программного обеспечения, так и структуру ИТ-инфраструктуры. DevOps помогает сделать вашу ИТ-инфраструктуру надежной — благодаря тесному сотрудничеству между командами, связанными с DevOps, и согласованию между средами разработки, тестирования и производства — и гибкой — благодаря внедрению таких методов DevOps, как CI/CD, IaC, автоматизация тестирования, полный мониторинг приложений и другие.