Методология devops что это

Что означает методология DevOps для тестировщиков?

Мы предлагаем познакомиться с переводом статьи Пола Джеррарда «What Does DevOps Mean for Testers?».
Пол Джеррард – технический директор компании TestOpera Limited и руководитель UK Test Management Forum, обладатель премий EuroSTAR European Testing Excellence и European Software Testing Awards (TESTA).
Перевод и публикация выполнены с разрешения автора

История вопроса

В этой статье я хочу обсудить внедрение методологии DevOps с точки зрения тестирования и тестировщика. «Движение DevOps» (лучшего названия пока нет) развивается стремительно. Скорость внедрения новшеств в этой методологии, как и многие другие перемены, которые происходят в этой отрасли, очень высокая. При этом до сих пор нет четко сформулированного названия самого движения.

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

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

Для непосвященного читателя: что такое методология DevOps?

Простыми словами: DevOps — это понятие, обозначающее группу разработки и группу эксплуатации систем, которые более тесно сотрудничают между собой. В так называемом конвейере развертывания (от исходного программного кода до эксплуатации в производственной среде) разработчики автоматизируют какие-либо действия группы эксплуатации. Группа эксплуатации имеет возможность отслеживать действия разработчиков и оказывать на них некоторое влияние. При этом цель заключается в ускорении развертывания и внедрения программного обеспечения. Объединение группы эксплуатации (Ops) и разработчиков (Dev) (фактически в виде команды, использующей методы Agile) позволяет реализовать подход, который можно назвать «эксплуатация, основанная на методах Agile» (Agile Operations).

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

Итак, DevOps — это просто инструменты?

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

Итак, DevOps — это просто разработчики (Dev) и группа эксплуатации (Ops), тесно сотрудничающие с использованием средств автоматизации?

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

Голова кругом! И что же все-таки означает DevOps? Это прогрессирующая новейшая дисциплина. Данный вопрос детально рассмотрен в статье «What Is DevOps?», которая появилась за несколько недель до написания данной статьи. Как вы уже поняли, определение понятия DevOps еще не сформулировано окончательно. Возможно, никогда и не будет.

Что это значит для тестировщиков? Это значит, что до сих пор не существует «единственно верного пути» и что ваша роль в режиме DevOps, который постоянно развивается (а каждый режим постоянно развивается), еще окончательно не установлена. Существуют два момента, которые вы можете реализовывать:

1) обращать внимание на болевые точки и прилагать усилия к тому, чтобы уменьшить степень их негативного влияния;
2) выявлять возможности, которые позволяют оптимизировать процесс DevOps.

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

Если это неприятно, делайте это чаще

Трудности или неприятные ощущения, которые мы испытываем при выполнении определенной работы, влияют на нас отрицательно. Если нам не нравится какое-либо задание, то мы стремимся отложить его. Когда же мы, наконец, принимаемся за это неприятное дело — становится еще невыносимее. Визит к стоматологу, уборка в гараже, интеграция программного обеспечения, тестирование и т. д. Опыт говорит о том, что чем реже мы выполняем такие задания, тем неприятнее их выполнение. Мартин Фаулер (Martin Fowler) предложил три причины того, почему частое (или даже непрерывное) выполнение определенных заданий уменьшает неприятные ощущения.

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

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

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

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

Тесты, автоматизация и доверие

Ведется много споров вокруг значения, например, проверок и тестирования, и вокруг того, насколько мы можем полагаться на тестировщиков, на проверки и на автоматизированные средства (The New Model and Testing v Checking).

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

1) проверки, которые могут быть автоматизированы разработчиками в составе покомпонентных проверок и процессов непрерывной интеграции;

2) проверки, которые можно автоматизировать (обычно силами системных тестировщиков) для выполнения транзакций на уровне API, линий связи или всей системы;

3) тесты, включающие проверки совместимости и позволяющие продемонстрировать совместимость с браузерами, операционными системами и платформами;

4) тесты, которые может выполнить только человек.

В данной статье могу лишь сделать предположение, как осуществить такое разделение — каждая среда имеет свои особенности. Наиболее подходящий вопрос для данной статьи – как тестировщику «освободить себя» от поздних ручных проверок? Ранее я писал об исключении поздних ручных проверок. Это требует предусмотрительности и доверия.

Необходимо сконцентрировать внимание на следующих моментах:

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

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

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

4. Какие проверки необходимо выполнять только вручную в отличие от проверок, которые требуется оставить для регрессионного тестирования (они являются кандидатами для автоматизированного тестирования)?

Выше я упомянул о доверии. Другой вопрос заключается в том, как надежно тестировать систему, если не будет позднего ручного тестирования. Представьте себе среду, в которой все тестирование осуществляется автоматизированными средствами. Поверите ли вы, что разработчики надлежащим образом выполнят тестирование? Смещение забот о тестировании влево должно развеять ваши сомнения. Если вы как тестировщик действуете, как следопыт: для того чтобы идентифицировать и оценить риски, выбрать тесты и обеспечить, чтобы они были встроены в процессы разработки и автоматизации, то ваши опасения могут быть сведены к минимуму.

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

Практика, мониторинг и совершенствование

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

Когда проблемы встречаются в производственной среде, то задача заключается в том, чтобы использовать аналитическую информацию, полученную при выполнении мониторинга для того, чтобы не только отследить причину и устранить ее, но и для уточнения процесса тестирования (автоматизированного или ручного) и снижения вероятности возникновения подобных проблем в будущем. Роль тестирования и аналитической информации в функционировании всего конвейера определяется и обсуждается в статье «Thinking Big: Introducing Test Analytics».

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

Заключение

Недавно меня спросили: «В каком случае не следует пытаться применять методологию DevOps в организации?». Это хороший вопрос. Думаю в его основе лежит опасение, должна ли методология DevOps стать нормой и должны ли тестировщики обратить на это внимание. Мой ответ прост.
Почему бы вам не сделать так, чтобы разработчики и специалисты по эксплуатации разговаривали друг с другом? Почему бы вам не начать получать более надежные сборки и развертывания в тестовой и производственной среде? Почему бы вам не использовать лучшие технологии для более точного, эффективного и информативного конвейера? Методология DevOps является хорошим делом, однако не всегда легко достичь требуемого уровня ее использования. Не говоря уже о том, что она требует изменения культуры, а это не так просто.

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

Источник

Гайд по 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

DevOps подразумевает принятие определенных общепринятых практик.

Непрерывное планирование

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

Совместное развитие

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

Непрерывное тестирование

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

Непрерывные выпуск и развертывание

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

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

Непрерывный мониторинг

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

Постоянная обратная связь и оптимизация

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

Преимущества DevOps

DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.

Важными преимуществами DevOps являются:

Принципы DevOps

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

Разрабатывайте и тестируйте в среде, похожей на производственную

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

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

Развертывание с воспроизводимыми, надежными процессами

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

Мониторинг и проверка качества работы

Организации хороши в мониторинге приложений на производстве, потому что у них есть инструменты, которые фиксируют показатели и ключевые показатели эффективности (KPI) в режиме реального времени. Этот принцип переносит мониторинг на ранние стадии жизненного цикла, гарантируя, что автоматизированное тестирование отслеживает функциональные и нефункциональные атрибуты приложения на ранних стадиях процесса. Всякий раз, когда приложение тестируется и развертывается, качественные показатели должны быть изучены и проанализированы. Инструменты мониторинга обеспечивают раннее оповещение о проблемах, связанных с эксплуатацией и качеством, которые могут возникнуть в процессе производства. Эти показатели должны быть собраны в формате, доступном и понятном всем заинтересованным сторонам.

Усовершенствование циклов обратной связи

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

В заключение

DevOps — это все более популярная методология, целью которой является объединение разработчиков и операторов в единое целое. Она уникальна, отличается от традиционных IT-операций и дополняет Agile (но не является столь же гибкой).

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

Источник