что такое труба devops
Руководство для начинающих: создаем DevOps-пайплайн
Если вы новичок в DevOps, взгляните на эту инструкцию по созданию вашего первого конвейера из пяти этапов.
DevOps стал стандартным решением для исправления медленных, разобщенных или неработоспособных процессов разработки программного обеспечения. Проблема в том что, если вы новичок в DevOps и не знаете, с чего начать, то вам может не хватать понимания этих методов. В этой статье речь пойдет об определении DevOps-конвейера, а также будет предложена инструкция по его созданию из пяти шагов. Несмотря на то, что это учебное пособие не является исчерпывающим, оно должно дать вам основу для того, чтобы начать свой путь и расширить свои познания в будущем. Но начнем с истории.
Мое путешествие по DevOps
Раньше я работал в облачной команде Citi Group, разрабатывая веб-приложение Infrastructure-as-a-Service (IaaS) для управления облачной инфраструктурой Citi, но меня всегда интересовало, как сделать процесс развития более эффективным и привнести позитивные культурные изменения в команду разработчиков. Ответ я нашел в книге, рекомендованной Грегом Лавендером (Greg Lavender), техническим директором Citi по облачной архитектуре и инфраструктуре. Книга называлась «Проект Феникс» (The Phoenix Project), и в ней объясняются принципы DevOps, при этом она читается как роман.
В таблице на обороте книги показано, как часто различные компании развертывают свои системы в среде для выпуска релизов:
Amazon: 23 000 в день
Google: 5 500 в день
Netflix: 500 в день
Facebook: Раз в день
Twitter: 3 раза в неделю
Типичная компания: Раз в 9 месяцев
Как вообще возможны частоты Amazon, Google и Netflix? Все потому, что эти компании придумали, как сделать почти идеальный DevOps-конвейер.
Мы были далеки от этого, пока не внедрили DevOps в Citi. Тогда в моей команде были разные окружения, но развертывание на сервере разработки было полностью ручным. Все разработчики имели доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. Проблема заключалась в том, что сервер выключался всякий раз, когда несколько пользователей одновременно пытались выполнить развертывание, поэтому разработчики должны были сообщать друг другу о своих намерениях, что было довольно болезненно. Кроме того, существовали проблемы с низкоуровневым тестовым покрытием кода, громоздкими процессами ручного развертывания и отсутствием возможности отслеживать развертывание кода, связанного с определенной задачей или пользовательской историей.
Я понял, что нужно что-то делать, и нашел коллегу-единомышленника. Мы решили сотрудничать в создании первоначального DevOps-конвейера – он установил виртуальную машину и сервер приложений Tomcat, пока я работал над Jenkins, интегрировал Atlassian Jira и BitBucket, а также работал над тестовым покрытием кода. Этот сайд-проект был очень успешным: мы почти полностью автоматизировали многие процессы, достигли практически 100% работоспособности нашего сервера разработки, обеспечили отслеживание и улучшили тестовое покрытие кода, а также добавили возможность связывать ветки в Git с задачами в Jira или развертыванием. Большинство инструментов, которые мы использовали для построения нашего конвейера DevOps, имели открытый исходный код.
Теперь я понимаю, насколько простым был наш DevOps-пайплайн: мы не использовали расширения вроде Jenkins files или Ansible. Однако, этот простой конвейер работал хорошо, возможно, благодаря принципу Парето (также известному как правило 80/20).
Краткое введение в DevOps и пайплайн CI/CD
Если вы спросите несколько человек: «Что такое DevOps?», то вы, вероятно, получите несколько разных ответов. DevOps, как и Agile, развивался, чтобы охватить множество различных дисциплин, но большинство людей согласятся с некоторыми вещами: DevOps — это практика разработки программного обеспечения или жизненный цикл разработки программного обеспечения (SDLC), центральным принципом которой является изменение культуры, в которой разработчики и не-разработчики существуют в среде, в которой:
Автоматизированы операции, которые ранее выполнялись вручную;
Каждый делает то, что умеет лучше всего;
Количество внедрений за определенный отрезок времени увеличивается; Увеличивается пропускная способность;
Повышается гибкость разработки.
Хотя наличие правильных программных инструментов — не единственное, что нужно для создания среды DevOps, некоторые инструменты необходимы. Ключевой инструмент – непрерывная интеграция и непрерывное развертывание (CI/CD). В этом конвейере среды имеют различные стадии (например, DEV, INT, TST, QA, UAT, STG, PROD), многие операции автоматизированы, а разработчики могут писать высококачественный код, добиваться гибкости разработки и высокой частоты развертываний.
В этой статье описывается пятиэтапный подход к созданию DevOps-конвейера, аналогичного изображенному на следующей диаграмме, с использованием инструментов с открытым исходным кодом.
Шаг 1: Методы CI/CD
Первое, что вам нужно – инструмент для CI/CD. Jenkins, инструмент с открытым исходным кодом, основанный на Java, и распространяемый по лицензии MIT, является тем средством, которое популяризировало направление DevOps и стало стандартом де-факто.
Так что же такое Jenkins? Считайте, что это некий волшебный универсальный пульт дистанционного управления, который может разговаривать с различными службами и инструментами и организовывать их. Сам по себе CI/CD инструмент, такой как Jenkins, бесполезен, но он становится более мощным по мере того, как подключается к различным инструментам и сервисам.
Jenkins – всего лишь один из многих инструментов с открытым исходным кодом для CI/CD, который вы можете использовать для построения DevOps-пайплайна.
Jenkins: Creative Commons and MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Вот как выглядят DevOps-процессы с инструментом CI/CD:
У вас есть инструмент CI/CD, работающий на вашем локалхосте, но на данный момент вы мало что можете сделать. Давайте перейдем на следующий этап путешествия в мир DevOps.
Шаг 2: Управление системами контроля исходного кода
Лучший (и, возможно, самый простой) способ проверить, что ваш инструмент CI/CD может творить магию – интегрироваться с инструментом контроля исходного кода (SCM). Зачем вам нужен контроль над исходным кодом? Предположим, вы разрабатываете приложение. Всякий раз, когда вы создаете приложение, вы программируете, и неважно, используете вы Java, Python, C++, Go, Ruby, JavaScript или какой-нибудь из газиллионов языков программирования. Код, который вы пишете называется исходным кодом. В начале, особенно когда вы работаете в одиночку, вероятно, можно поместить все в локальную директорию. Но когда проект становится больше, и вы приглашаете других людей к сотрудничеству, вам нужен способ предотвращения конфликтов при эффективном обмене модификациями. Вам также нужен способ восстановления предыдущих версий, потому что создание бекапов и копирование/вставка в них уже устаревает. Вам (и вашим товарищам по команде) нужно что-то получше.
Именно здесь средство контроля исходного кода становится практически необходимостью. Этот инструмент сохраняет ваш код в репозиториях, ведет учет версий и координирует работу участников проекта.
Хотя существует множество инструментов контроля исходного кода, Git является стандартом, и это верно. Я настоятельно рекомендую использовать Git, хотя, если угодно, есть и другие варианты с открытым исходным кодом.
Git: GPLv2 и LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Так выглядит DevOps-пайплайн с добавлением средств контроля исходного кода.
Инструмент CI/CD может автоматизировать процессы проверки, получения исходного кода и сотрудничества между членами. Неплохо? Но как сделать из этого работающее приложение, чтобы миллиарды людей могли его использовать и оценить?
Шаг 3: Создание инструмента автоматизации сборки
Отлично! Вы можете проверять код и вносить изменения в систему контроля исходного кода, а также приглашать своих друзей к сотрудничеству в разработке. Но вы еще не создали приложение. Чтобы сделать веб-приложение, его нужно скомпилировать и упаковать в развертываемый пакетный формат или запустить в виде исполняемого файла. (Обратите внимание, что интерпретируемый язык программирования, такой как JavaScript или PHP, не нуждается в компиляции).
Воспользуйтесь инструментом автоматизации сборки. Независимо от того, какой инструмент автоматизации сборки вы решите использовать, все они преследуют одну и ту же цель: собрать исходный код в какой-нибудь желаемый формат и автоматизировать задачу по очистке, компиляции, тестированию и развертыванию в определенной среде. Инструменты для сборки будут различаться в зависимости от вашего языка программирования, но вот некоторые общие варианты с открытым исходным кодом.
Название | Лицензия | Язык программирования |
---|---|---|
Maven | Apache 2.0 | Java |
Ant | Apache 2.0 | Java |
Gradle | Apache 2.0 | Java |
Bazel | Apache 2.0 | Java |
Make | GNU | N/A |
Grunt | MIT | JavaScript |
Gulp | MIT | JavaScript |
Buildr | Apache | Ruby |
Rake | MIT | Ruby |
A-A-P | GNU | Python |
SCons | MIT | Python |
BitBake | GPLv2 | Python |
Cake | MIT | C# |
ASDF | Expat (MIT) | LISP |
Cabal | BSD | Haskell |
Здорово! Вы можете поместить файлы конфигурации инструмента автоматизации сборки в систему управления исходным кодом и позволить вашему инструменту CI/CD собрать все воедино.
Все хорошо, не так ли? Но где развернуть ваше приложение?
Шаг 4: Сервер для веб-приложений
Пока что у вас есть упакованный файл, который может быть как исполняемым, так и устанавливаемым. Для того чтобы любое приложение было действительно полезным, оно должно предоставлять какую-то службу или интерфейс, но вам нужен контейнер для размещения вашего приложения.
Сервер для веб-приложений представляет собой именно такой контейнер. Сервер обеспечивает среду, в которой может быть определена логика развертываемого пакета. Также сервер предоставляет интерфейс и предлагает веб-сервисы, открывая сокеты для внешнего мира. Вам нужен HTTP-сервер, а также некоторая среда (например, виртуальная машина) для его установки. А пока, давайте предположим, что вы узнаете об этом дальше (хотя я расскажу о контейнерах ниже).
Существует несколько серверов для веб-приложений с открытым исходным кодом.
Название | Лицензия | Язык программирования |
---|---|---|
Tomcat | Apache 2.0 | Java |
Jetty | Apache 2.0 | Java |
WildFly | GNU Lesser Public | Java |
GlassFish | CDDL & GNU Less Public | Java |
Django | 3-Clause BSD | Python |
Tornado | Apache 2.0 | Python |
Gunicorn | MIT | Python |
Python | MIT | Python |
Rails | MIT | Ruby |
Node.js | MIT | Javascript |
Ваш DevOps-пайплайн почти готов к использованию. Хорошая работа!
Хотя на этом можно остановиться и заниматься интеграцией самостоятельно, качество кода – важная вещь для разработчика приложений, и об этом нужно беспокоиться.
Шаг 5: Покрытие тестирования кода
Реализация тестов может быть еще одним громоздким требованием, но разработчики должны ловить любые ошибки в приложении на ранней стадии и улучшать качество кода, чтобы гарантировать, что конечные пользователи будут удовлетворены. К счастью, существует множество инструментов с открытым исходным кодом для тестирования вашего кода и формирования рекомендаций по улучшению его качества. Еще лучше то, что большинство инструментов CI/CD могут подключаться к этим инструментам и автоматизировать процесс.
Тестирование кода состоит из двух частей: фреймворки для тестирования кода, которые помогают писать и запускать тесты, а также инструменты для формирования предложений, которые помогают улучшить качество кода.
Системы тестирования кода
Название | Лицензия | Язык программирования |
---|---|---|
JUnit | Eclipse Public License | Java |
EasyMock | Apache | Java |
Mockito | MIT | Java |
PowerMock | Apache 2.0 | Java |
Pytest | MIT | Python |
Hypothesis | Mozilla | Python |
Tox | MIT | Python |
Системы рекомендаций по улучшению кода
Название | Лицензия | Язык программирования |
---|---|---|
Cobertura | GNU | Java |
CodeCover | Eclipse Public (EPL) | Java |
Coverage.py | Apache 2.0 | Python |
Emma | Common Public License | Java |
JaCoCo | Eclipse Public License | Java |
Hypothesis | Mozilla | Python |
Tox | MIT | Python |
Jasmine | MIT | JavaScript |
Karma | MIT | JavaScript |
Mocha | MIT | JavaScript |
Jest | MIT | JavaScript |
Обратите внимание, что большинство инструментов и фреймворков, упомянутых выше, написаны для Java, Python и JavaScript, поскольку C++ и C# являются проприетарными языками программирования (хотя GCC и имеет открытый исходный код).
Теперь, когда вы реализовали инструменты покрытия кода тестами, ваш DevOps-пайплайн должен быть похож на диаграмму, показанную в начале этого руководства.
Дополнительные шаги
Как я уже говорил, вы можете размещать свой сервер на виртуальной машине или сервере, но контейнеры являются популярным решением.
Что такое контейнеры? Краткое объяснение заключается в том, что виртуальная машина нуждается в огромном объеме памяти операционной системы, превышающем размер приложения, в то время как контейнеру нужно всего лишь несколько библиотек и конфигураций для запуска приложения. Очевидно, что у виртуальной машины все еще существуют важные области применения, но контейнер – это легкое решение для хостинга приложения, в том числе сервера приложений.
Хотя существуют и другие варианты контейнеров, наиболее популярными являются Docker и Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Промежуточные средства автоматизации
Наш DevOps-пайплайн в основном ориентирован на совместное создание и развертывание приложений, но существует множество других вещей, которые можно сделать с помощью DevOps-инструментов. Одной из них является использование инструментов Infrastructure as Code (IaC), которые также известны как средства промежуточной автоматизации. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного программного обеспечения. Так, например, инструмент автоматизации может извлекать приложения вроде сервера веб-приложений, базы данных и инструмента мониторинга, с правильными конфигурациями и развертывать их на сервере приложений.
Вот несколько инструментов промежуточной автоматизации с открытым исходным кодом:
Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache или GPL
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:
Гайд по DevOps для начинающих
В чем важность DevOps, что он означает для ИТ-специалистов, описание методов, фреймворков и инструментов.
Многое произошло с тех пор, как термин DevOps закрепился в IT-мире. С учетом того, что большая часть экосистемы имеет открытый исходный код, важно пересмотреть, почему это началось и что это значит для карьеры в IT.
Что такое DevOps
Хотя нет единого определения, я считаю, что DevOps — это технологическая структура, которая обеспечивает взаимодействие между командами разработчиков и операционными командами для более быстрого развертывания кода в производственных средах с возможностью повторения действий и автоматизации. Остаток статьи мы потратим на распаковку этого утверждения.
Слово «DevOps» является объединением слов «разработка» (development) и «операции» (operations). DevOps помогает увеличить скорость доставки приложений и услуг. Это позволяет организациям эффективно обслуживать своих клиентов и становиться более конкурентоспособными на рынке. Проще говоря, DevOps — это согласованность между разработкой и ИТ-операциями с более эффективным взаимодействием и сотрудничеством.
DevOps предполагает такую культуру, при которой сотрудничество между командами разработчиков, операторами и бизнес-командами считается критически важным аспектом. Речь идет не только об инструментах, поскольку DevOps в организации постоянно приносит пользу и клиентам. Инструменты являются одним из его столпов, наряду с людьми и процессами. DevOps увеличивает возможности организаций по предоставлению высококачественных решений в кратчайшие сроки. Также DevOps автоматизирует все процессы, от сборки до развертывания, приложения или продукта.
Дискуссия о DevOps сосредоточена на взаимоотношениях между разработчиками, людьми, которые пишут программное обеспечение для жизни, и операторами, ответственными за поддержку этого программного обеспечения.
Вызовы для команды разработчиков
Разработчики, как правило, с энтузиазмом и желанием внедряют новые подходы и технологии для решения проблем организаций. Однако они также сталкиваются с определенными проблемами:
Проблемы, с которыми сталкивается операционная группа
Операционные группы исторически ориентированы на стабильность и надежность ИТ-сервисов. Именно поэтому операционные команды занимаются поиском стабильности с помощью внесения изменений в ресурсы, технологии или подходы. К их задачам относятся:
Как DevOps решает проблемы разработки и операций
Вместо того, чтобы выкатывать большое количество функций приложения одновременно, компании пытаются выяснить, смогут ли они развернуть небольшое количество функций для своих клиентов с помощью серии итераций релизов. Такой подход имеет ряд преимуществ, таких как лучшее качество программного обеспечения, более быстрая обратная связь с клиентами и т.д. Это, в свою очередь, обеспечивает высокую степень удовлетворенности клиентов. Для достижения этих целей от компаний требуется:
DevOps пытается решить различные проблемы, возникающие в результате применения методологий прошлого, в том числе:
Противостояние DevOps, Agile и традиционного IT
DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.
Agile — это набор принципов, ценностей и методов производства программного обеспечения. Так, например, если у вас есть идея, которую вы хотите преобразовать в программное обеспечение, вы можете использовать принципы и ценности Agile. Но это программное обеспечение может работать только в среде разработки или тестирования. Вам нужен простой и безопасный способ быстро и с высокой повторяемостью переносить программное обеспечение в производственную среду, а путь лежит через инструменты и методы DevOps. Гибкая методология разработки программного обеспечения сосредоточена на процессах разработки, а DevOps отвечает за разработку и развертывание — самым безопасным и надежным способом.
Сравнение традиционной водопадной модели с DevOps – хороший способом понять преимущества, которые дает DevOps. В следующем примере предполагается, что приложение будет запущено через четыре недели, разработка завершена на 85%, приложение будет запущено, и процесс закупки серверов для отправки кода только что был начат.
Традиционные процессы | Процессы в DevOps |
---|---|
После размещения заказа на новые серверы команда разработчиков работает над тестированием. Оперативная группа работает над обширной документацией, необходимой на предприятиях для развертывания инфраструктуры. | После размещения заказа на новые серверы, команды разработчиков и операторов совместно работают над процессами и документооборотом для установки новых серверов. Это позволяет лучше понять требования к инфраструктуре. |
Искажена информация о восстановлении после отказа, избыточности, расположении центров обработки данных и требованиях к хранилищам, так как отсутствуют входные данные от команды разработчиков, которая обладает глубокими знаниями в области применения. | Подробная информация о преодолении отказа, избыточности, аварийном восстановлении, расположении центров данных и требованиях к хранилищам известна и корректна благодаря вкладу команды разработчиков. |
Оперативная группа не имеет представления о прогрессе команды разработчиков. Также она разрабатывает план мониторинга на основе собственных представлений. | Оперативная группа полностью осведомлена о прогрессе, достигнутом командой разработчиков. Она также взаимодействует с командой разработчиков, и они совместно разрабатывают план мониторинга, который удовлетворяет IT и потребности бизнеса. Они также используют инструменты мониторинга производительности приложений (APM). |
Нагрузочный тест, проводимый перед запуском приложения, приводит к сбою приложения, что задерживает его запуск. | Нагрузочный тест, проводимый перед запуском приложения, приводит к снижению производительности. Команда разработчиков быстро устраняет узкие места, и приложение запускается вовремя. |
Жизненный цикл DevOps
DevOps подразумевает принятие определенных общепринятых практик.
Непрерывное планирование
Непрерывное планирование опирается на принципы бережливости, для того чтобы начать с малого, определив ресурсы и результаты, необходимые для проверки ценности бизнеса или видения, постоянной адаптации, измерения прогресса, изучения потребностей клиентов, изменения направления по мере необходимости с учетом маневренности, а также для обновления бизнес-плана.
Совместное развитие
Процесс совместной разработки позволяет бизнесу, командам разработчиков и командам тестировщиков, распределенным по разным часовым поясам, непрерывно поставлять качественное программное обеспечение. Сюда входит многоплатформенная разработка, поддержка программирования на разных языках, создание пользовательских историй, разработка идей и управление жизненным циклом. Совместная разработка включает в себя процесс и практику непрерывной интеграции, что способствует частой интеграции кода и автоматической сборке. При частом внедрении кода в приложение, проблемы интеграции выявляются на ранних этапах жизненного цикла (когда их легче исправить), а общие усилия по интеграции сокращаются благодаря непрерывной обратной связи, поскольку проект демонстрирует непрерывный и наглядный прогресс.
Непрерывное тестирование
Непрерывное тестирование снижает стоимость тестирования, помогая командам разработчиков балансировать между скоростью и качеством. Оно также устраняет узкие места в тестировании благодаря виртуализации услуг и упрощает создание виртуализированных тестовых сред, которые можно легко совместно использовать, развертывать и обновлять по мере изменения систем. Эти возможности сокращают расходы на инициализацию и поддержку тестовых сред, а также сокращают время цикла тестирования, позволяя проводить интеграционное тестирование на ранних стадиях жизненного цикла.
Непрерывные выпуск и развертывание
Эти методики привносят за собой одну из основных практик: непрерывные выпуск и развертывание. Это обеспечивают непрерывный конвейер, который автоматизирует ключевые процессы. Он сокращает количество ручных операций, время ожидания ресурсов и объем переделок, позволяя осуществлять развертывание по нажатию кнопки, что обеспечивает большее количество релизов, снижение количества ошибок и полную прозрачность.
Автоматизация играет ключевую роль в обеспечении стабильного и надежного выпуска программного обеспечения. Одна из важнейших задач заключается в том, чтобы взять на вооружение ручные процессы, такие как сборка, регрессия, развертывание и создание инфраструктуры, и автоматизировать их. Для этого требуется контроль версии исходного кода; сценарии тестирования и развертывания; данные об инфраструктуре и конфигурации приложений; а также библиотеки и пакеты, от которых зависит приложение. Еще одним важным фактором является возможность запрашивать состояние всех сред.
Непрерывный мониторинг
Непрерывный мониторинг обеспечивает формирование отчетов корпоративного уровня, которые помогают командам разработчиков понять доступность и производительность приложений в производственном окружении еще до того, как они будут развернуты в производство. Ранняя обратная связь, обеспечиваемая непрерывным мониторингом, имеет решающее значение для снижения стоимости ошибок и управления проектами в правильном направлении. Эта практика часто включает в себя инструменты наблюдения, которые, как правило, раскрывают показатели, связанные с производительностью приложений.
Постоянная обратная связь и оптимизация
Непрерывная обратная связь и оптимизация обеспечивают визуальное представление потока клиентов и точное определения проблемных участков. Обратная связь может быть включена как на предпродажной, так и на постпроизводственной стадиях для максимизации ценности и обеспечения успешного завершения еще большего количества транзакций. Все это обеспечивает немедленную визуализацию первопричины проблем клиентов, которые влияют на их поведение и влияние на бизнес.
Преимущества DevOps
DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.
Важными преимуществами DevOps являются:
Принципы DevOps
Принятие DevOps породило несколько принципов, которые эволюционировали (и продолжают эволюционировать). Большинство поставщиков решений разработали свои собственные модификации различных методик. Все эти принципы основаны на целостном подходе к DevOps, и организации любого размера могут использовать их.
Разрабатывайте и тестируйте в среде, похожей на производственную
Суть заключается в том, чтобы позволить командам разработчиков и специалистов по контролю качества (QA) разрабатывать и тестировать системы, которые ведут себя как производственные системы, чтобы они могли видеть, как приложение ведет себя и работает задолго до того, как оно будет готово к развертыванию.
Приложение должно быть подключено к производственным системам как можно раньше в течение жизненного цикла для решения трех основных потенциальных проблем. Во-первых, это позволяет протестировать приложение в среде, близкой к реальному окружению. Во-вторых, это позволяет тестировать и проверять процессы доставки приложения заранее. В-третьих, это позволяет операционной команде проверить на ранней стадии жизненного цикла, как их среда будет вести себя, когда приложения будут развернуты, тем самым позволяя им создавать тонко настраиваемую, ориентированную на приложения среду.
Развертывание с воспроизводимыми, надежными процессами
Этот принцип позволяет командам разработчиков и операторов поддерживать гибкие процессы разработки программного обеспечения на протяжении всего жизненного цикла. Автоматизация имеет решающее значение для создания итеративных, надежных и воспроизводимых процессов. Следовательно, организация должна создать конвейер доставки, обеспечивающий непрерывное автоматизированное развертывание и тестирование. Частое развертывание также позволяет командам тестировать процессы развертывания, тем самым снижая риск сбоев развертывания во время реальных релизов.
Мониторинг и проверка качества работы
Организации хороши в мониторинге приложений на производстве, потому что у них есть инструменты, которые фиксируют показатели и ключевые показатели эффективности (KPI) в режиме реального времени. Этот принцип переносит мониторинг на ранние стадии жизненного цикла, гарантируя, что автоматизированное тестирование отслеживает функциональные и нефункциональные атрибуты приложения на ранних стадиях процесса. Всякий раз, когда приложение тестируется и развертывается, качественные показатели должны быть изучены и проанализированы. Инструменты мониторинга обеспечивают раннее оповещение о проблемах, связанных с эксплуатацией и качеством, которые могут возникнуть в процессе производства. Эти показатели должны быть собраны в формате, доступном и понятном всем заинтересованным сторонам.
Усовершенствование циклов обратной связи
Одна из целей процессов DevOps заключается в том, чтобы дать возможность организациям быстрее реагировать и вносить изменения. При поставке программного обеспечения эта цель требует, чтобы организация получала обратную связь на ранней стадии, а затем быстро училась на каждом предпринятом действии. Этот принцип требует от организаций создавать каналы коммуникации, которые позволяют заинтересованным сторонам получать доступ и взаимодействовать по принципу обратной связи. Разработка может осуществляться путем корректировки своих проектных планов или приоритетов. Производство может действовать путем улучшения производственной среды.
В заключение
DevOps — это все более популярная методология, целью которой является объединение разработчиков и операторов в единое целое. Она уникальна, отличается от традиционных IT-операций и дополняет Agile (но не является столь же гибкой).
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory: