Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: XXXVIII Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 26 января 2016 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Костарев Д.С. CONTINUOUS INTEGRATION И DEPLOYMENT SERVER В РАЗВЁРТЫВАНИИ ПРИЛОЖЕНИЯ // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. XXXVIII междунар. студ. науч.-практ. конф. № 1(37). URL: http://sibac.info/archive/technic/1(37).pdf (дата обращения: 04.05.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
Диплом лауреата
отправлен участнику

CONTINUOUS INTEGRATION И DEPLOYMENT SERVER В РАЗВЁРТЫВАНИИ ПРИЛОЖЕНИЯ

Костарев Дмитрий Станиславович

студент 4 курса, ФГАОУ ВПО Уральский Федеральный Университет

имени первого Президента России Б.Н. Ельцина

г. Екатеринбург, РФ

E-mail: albemuth1221@gmail.com

Спиричева Наталья Рахматулловна

научный руководитель, ст. преп., ФГАОУ ВПО Уральский Федеральный Университет имени первого Президента России Б.Н. Ельцина,

г. Екатеринбург, РФ

 

Введение

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

В связи с этим, достаточно значимой частью цикла разработки и поддержки программного обеспечения является доставка новых версий пользователю. В случае с любыми сервисами, поставляющимися в режиме онлайн, процесс установки обновления часто называется «деплой» (англ. “deployment” – развёртывание) и включает в себя перенос исполняемых файлов на сервера, подстановку настроек, соответствующих целевому окружению, миграцию баз данных и прочие мероприятия.

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

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

Проблемы при развёртывании ПО

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

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

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

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

Методики развёртывания ПО

Согласно результатам опроса [1], наиболее распространённые варианты деплоя – это ручное перемещение исполняемых файлов, рабочая копия хранилища системы контроля версий, перемещение файлов из системы контроля версий при помощи скрипта. Распределение голосов приведено на рисунке 1.

 

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

Непрерывная интеграция

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

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

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

Сервер развёртывания

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

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

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

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

Оптимальная схема развёртывания приложения

С учётом вышеописанного, предлагаем схему деплоя с использованием системы CI и deployment server. Данная схема решает проблемы, рассмотренные в начале статьи, и тем самым повышает производительность команды разработчиков, уменьшает время реагирования на неполадки сервиса. Схема представлена на рисунке 2.

Рисунок 2. Схема автоматизированной установки обновлений

 

Предлагаемый порядок установки приложения состоит из четырёх этапов. Сначала разработчик отправляет код продукта в систему контроля версий. Затем, он активирует сборку и прогон тестов в системе CI. После успешного завершения тестирования, система CI собирает установочный пакет и отправляет его для установки Deploy-сервером. Пакет устанавливается в тестовое окружение, где может пройти дальнейшее тестирование перед выпуском его в рабочем окружении.

Вывод

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

 

Список литературы:

1.     Habrahabr - Опрос. Как вы делаете деплой на production сервер(а)? [Электронный ресурс]. Режим доступа: http://habrahabr.ru/post/211733/

2.     Troyhunt.com – “You’re deploying it wrong!”. [Электронный ресурс]. Режим доступа: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html

3.     TeamCity documentation [Электронный ресурс]. Режим доступа: https://confluence.jetbrains.com/display/TCD9/TeamCity+Documentation

Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
Диплом лауреата
отправлен участнику

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.