- PVSM.RU - https://www.pvsm.ru -
Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.
Как такового, определения DevOps нет, и все понимают эту методологию по-разному. Декларируемая цель – убрать барьеры между DEVelopment и OPerations. Поэтому часто DevOps понимают как то, что operations, QA и development находятся в одной команде, сидят в одном помещении, проводят общие митинги, общаются. Само по себе сближение и неформальное общение членов команды всегда полезно и уже это может привести к улучшению результатов. Но есть и формальные практики, следование которым позволяет улучшить поставку релизов, а значит и удовлетворение бизнеса.
Здесь описаны следующие:
Приведенные ниже практики взяты из серии роликов от Microsoft DevOps-Fundamentals [8]. Очень интересные и полезные вебинары, правда, с акцентом на технологии Microsoft.
Структура статьи построена следующим образом: перечислены практики, дано их описание, приведено Бизнес-Значение практики (то, как внедрение этого подхода улучшит жизнь бизнеса) и Измеримость (как можно измерить улучшение). И Бизнес-значение, и Измеримость также взяты из презентаций «DevOps-Fundamentals».
Ну что же, приступим. Процесс разработки и поставки ПО состоит из следующих шагов:
Начинается все с планирования. Планирование релиза, разработки, тестирования, развертывания. Пропустим этот шаг, так как development и operations в этом шаге не задействованы. После того, как разработчик закончил реализацию некоторого участка кода, он сохраняет (check-in’ит) его в систему контроля версий. После этого вступает в дело первая практика:
Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Wiki [9]
Собственно, что такое Continuous Integration? Процесс происходит примерно так: разработчик, после того, как завершил свою задачу и отладился, сохраняет свои изменения в рабочюю копию (TFS, SVN, Git). Дальше в действие вступает некий робот (TFS, TeamCity, что-либо еще), отслеживающий изменение рабочей версии. Он видит, что рабочая копия изменилась и запускает сборку проекта. По результатам сборки, оповещается разработчик (и другие заинтересованные лица) о том, прошло все успешно или нет. Оповещение может быть через письмо, сообщение в трее, или отобразиться на web-странице. Таким образом, если сборка прошла с ошибкой, то разработчик сразу же узнает об этом.
Автоматизированное тестирование – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования © [10].
После того, как сборка собрана, её нужно проверить. Наиболее быстро это можно сделать с помощью автоматических тестов. Для этого используются различные инструменты: это могут быть Unit тесты, UX тесты, интеграционные тесты. Главное условие – они не должны требовать участия человека. С помощью авто-тестов мы сразу получаем информацию о том, есть ли ошибки в нашей сборке. И сразу же можем начать их исправлять, не дожидаясь результатов ручного тестирования.
Инфраструктура как код — это процесс управления и подготовки вычислительной инфраструктуры (процессы, физические сервера, виртуальные сервера и т.п.) и их конфигурации через машиннообрабатываемые файлы определений, а не физическую конфигурацию оборудования или использование конфигурационных инструментов Wiki [11].
Подход к конфигурированию приложений должен быть таким же, как и к коду. То есть конфигурационные файлы, переменные окружения, что-то еще должны храниться в централизованном хранилище или системе контроля версий, возможно, в той же самой, что и хранится код. И при конфигурировании приложения браться они должны именно оттуда. Соответственно, в случае необходимости изменить конфигурацию на сервере, ответственный сотрудник не заходит на него и меняет, например, соединение к БД, а меняет нужную переменную в хранилище, и оттуда она уже автоматически появляется на сервере.
Для переменных, специфичных для различных сред (Dev, Stage, Production) используются синонимы, подменяемые при развертывании на реальные значения. Примером такой подмены может служить технология transform [12], используемая для изменения конфигурационных файлов .NET приложений.
Непрерывная развертывание – объединение Continuous Integration (непрерывной интеграции) и Continuous Delivery (непрерывной поставки). Это следующий шаг после успешной сборки и успешного прохождения автоматических тестов (и, возможно, установки галочки «сборка готова к развертыванию» ответственным человеком). Если вы уверены в ваших тестах, их наборе и покрытии, при их успешном выполнении запускается автоматическая установка на соответствующую среду, тестовую или продуктовую. Разница между Continuous Integration, Delivery, Deployment хорошо описана тут: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/ [14]
Управление релизом заключается в том, что мы определяем формальные критерии, готова ли сборка к установке на соответствующую среду. Примером критериев, по которым сборка готова, и, если они выполняются, автоматически запускается поставка (Continuous Deployment) могут быть:
Полезная ссылка: Управление релизами в Visual Studio 2013 [15].
Управление конфигурациями (Configuration Management) — это детальная запись и обновление информации, описывающей ПО и оборудование предприятия. Такая информация обычно включает версии и апдейты, которые были применены к установленному ПО, а также местоположение и сетевые адреса оборудования. © [16]
Здесь к формальному определению добавить особо и нечего. Все должно быть записано и подсчитано.
Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству) Wiki [17]
Часто происходит так, что, например, для web приложений, когда пользователь один (разработчик или тестировщик) страница быстро открывается у и хорошо реагирует на работу с ней. Но как только изменения попадают на продуктовый сервер, и эту же страницу начинают смотреть сотни, тысячи человек одновременно, страница долго грузится и перестаёт реагировать.
Проводя нагрузочное тестирование мы и определяем наличие проблем на раннем этапе, еще до попадания проблемной сборки на продуктовый сервер. Нагрузочное тестирование реализуется генерацией большого потока запросов к серверу и анализа поведения сервера.
Мониторинг быстродействия приложения (application performance management) – это мониторинг и управление быстродействием и доступностью ПО. APM стремится выявлять и диагностировать проблемы быстродействия комплексно, для поддержания ожидаемого уровня обслуживания Wiki [18]
Нагрузочное тестирование выявляет многие проблемы еще до того, как сборка попала на продуктовые сервера и с ней начали работать клиенты. Но, к сожалению, не всегда удается предугадать как действия пользователей, так и влияние разницы в ресурсах серверов на тестовой и продуктовой средах. Поэтому необходимо мониторить состояние и работу приложения на продуктовой среде. Этому и служит мониторинг быстродействия приложения.
Надеюсь, данная статья дала вам представление, что такое DevOps и что нужно сделать для улучшения жизни developers, operations и business.
Автор: eragnim
Источник [19]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/130991
Ссылки в тексте:
[1] Continuous Integration: #continuousintegration
[2] Automated Testing: #automatedtesting
[3] Infrastructure as Code: #infrastructureascode
[4] Continuous Deployment: #continuousdeployment
[5] Configuration Management: #configurationmanagement
[6] Load Testing: #loadtesting
[7] Application Performance Monitoring: #applicationperformancemonitoring
[8] DevOps-Fundamentals: https://channel9.msdn.com/Series/DevOps-Fundamentals
[9] Wiki: https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F
[10] ©: http://www.protesting.ru/automation/
[11] Wiki: https://en.wikipedia.org/wiki/Infrastructure_as_Code
[12] transform: https://msdn.microsoft.com/en-us/library/dd465326(v=vs.110).aspx
[13] мышление: http://www.braintools.ru
[14] http://blogs.atlassian.com/2014/04/practical-continuous-deployment/: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/
[15] Управление релизами в Visual Studio 2013: https://habrahabr.ru/company/microsoft/blog/209406/
[16] ©: http://searchitoperations.techtarget.com/definition/configuration-management-CM
[17] Wiki: https://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BE%D1%87%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
[18] Wiki: https://en.wikipedia.org/wiki/Application_performance_management
[19] Источник: https://habrahabr.ru/post/303050/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.