Друзья, доброго времени суток.
Честно говоря, уже устал поддерживать версии приложений на серверах и делать изменения в БД врукопашную. Использую свои скрипты установки — те же программы, за которыми тоже надо следить самому и править в разных обстоятельствах, типа добавления нового сервера или подготовки новой виртуалки тестировщикам. Захотелось посмотреть, какие есть цивилизованные решения для таких задач. Хочу поделиться первым опытом работы в среде автоматизации процесса развертывания софта – Serena Deployment Automation (SDA) — продукт бесплатен при условии использования на не более 5 серверах.
![](https://habrastorage.org/files/12e/111/1ec/12e1111ec1eb42db8df5e9b055c85eb7.jpeg)
Используя SDA, можно автоматизировать и объединить под одной «крышей» такие операции как:
1. Получение исходного кода из различных источников – файловая система, среды версионного контроля (Git, Subversion и т.д.)
2. Сборка кода через интеграцию с Jenkins, Apache Maven и т.д.
3. Моделирование сценариев доставки и установки изменений для всего приложения или его отдельных компонент. Сюда могут быть включены как простые задачи, вроде переноса файлов, так и более сложные, типа запуска скриптов обновления данных в БД, установки веб-приложений на IIS, Aphache и другие веб-сервера, запуск различных скриптов, снятие снэпшотов виртуальных машин, запуск тестов после установки и т.д.
4. Ручной и отложенный запуск развертывания, отслеживание прогресса установки, просмотр логов.
5. Последовательная или параллельная установка на несколько сред (например, на тестовую и боевую или на несколько боевых).
И так далее. Возможности достаточно обширны.
Важно, что абсолютно вся настройка происходит через общий веб-интерфейс системы.
Я начну с создания процесса развертывания небольшого ASPX-отчета. Отчет выдает информацию из базы данных на MS SQL и хостится на веб-сервере IIS. Также у нас есть SQL Update скрипт для обновления данных, который нужно выполнить после установки свежей версии.
Начнем с того, что настроим получение кода из репозитория Git’a. Для этого создадим новую компоненту, дадим ей имя, укажем ветку и путь к клиенту Git:
![](https://habrastorage.org/files/145/19e/bb6/14519ebb678e465c8fbf054ff54952b4.jpg)
В отдельном репозитории хранятся SQL скрипты. Аналогичным образом создадим для них компоненту.
Далее переходим к описанию процесса установки каждой компоненты. Процесс установки aspx-отчета представлен ниже:
![](https://habrastorage.org/files/3d1/88c/fd5/3d188cfd5c684a5e90110a9c0ed9141a.jpg)
Первый шаг загружает все артефакты (файлы) в нужную мне директорию на сервере, второй шаг перезапускает веб-сервер через команду строку.
Список доступных операций по взаимодействию с различными системами определяется используемыми плагинами. В состав SDA их входит порядка 80-ти штук. Если интересно, с полным списком можно ознакомится здесь.
Отдельный процесс описывает запуск SQL скриптов. Схема похожая – скрипты загружаются на сервер и затем запускаются (через sqlcmd):
![](https://habrastorage.org/files/d9e/6a8/a75/d9e6a8a757d5480da0ad829aa4540624.jpg)
Каким образом SDA осуществляет все эти действия на удаленном сервере? Через отдельную программу-агента, доступную для различных платформ. Т.е. агента SDA нужно установить на сервер. Иногда это невозможно. В этом случае используется так называемая «agentless» конфигурация, когда развертывание происходит без участия агентов. Типичный сценарий — подключаемся к серверу по SSH, из командной строки запускаем команды обновления исходных файлов с того же Git, копируем файлы в нужные папки, перезапускаем процессы, если надо. Это прямой ход развития событий. И везде нужно проверять, что есть место на диске, что все файлы получены, что всё нормально скопировалось куда надо и т.д. и т.п. И предусмотреть действия по откату и зачистке сервера после своих действий.
Объединяющим элементом будет конфигурационный объект, который в системе называется «Application». Создадим такой и начнём его настройку с добавления наших компонент:
![](https://habrastorage.org/files/fdf/6b7/503/fdf6b7503ea941078e29528e4a959a4b.jpg)
Далее настроим окружение (слово «окружение» здесь больше подходит, т.к. серверов может быть много), на котором будем проводить развертывание:
![](https://habrastorage.org/files/e0c/6d3/064/e0c6d3064cb2415fb78e512f60e04180.jpg)
И последнее. Создадим процесс, объединяющий процедуры установки обоих наших компонент (application process):
![](https://habrastorage.org/files/eb7/5d4/ad7/eb75d4ad7d2b410e94ece7283ece7ad4.jpg)
На этом всё, теперь запустим процесс. Можно отслеживать состояние развертывания в режиме real-time:
![](https://habrastorage.org/files/6c6/a07/4b3/6c6a074b39af46bcbb6e2bbeae94b083.jpg)
Или посмотреть результаты после завершения:
![](https://habrastorage.org/files/0d2/f92/128/0d2f9212878943eaaa1f78976ecf49ec.jpg)
Внутри каждого шага хранятся логи выполнения. Если что-то пошло не так, это сразу будет видно. Например, вот логи выполнения SQL-update скрипта:
![](https://habrastorage.org/files/940/c9f/cb7/940c9fcb7b3b4131827c634e1a93c66a.jpg)
Заключение
Пока мой пример слишком простой, чтобы что-то рекомендовать или оценивать пригодность подхода.
Что еще надо попробовать:
Посмотреть на красивые картинки, почитать описание производителя и скачать всё это добро можно здесь.
Собственно, на этом всё. Надеюсь, тема автоматизации процессов развертывания кому-то интересна. Задавайте, пожалуйста, вопросы в комментариях. Очень интересно, что вы об этом думаете.
Честно говоря, уже устал поддерживать версии приложений на серверах и делать изменения в БД врукопашную. Использую свои скрипты установки — те же программы, за которыми тоже надо следить самому и править в разных обстоятельствах, типа добавления нового сервера или подготовки новой виртуалки тестировщикам. Захотелось посмотреть, какие есть цивилизованные решения для таких задач. Хочу поделиться первым опытом работы в среде автоматизации процесса развертывания софта – Serena Deployment Automation (SDA) — продукт бесплатен при условии использования на не более 5 серверах.
![](https://habrastorage.org/files/12e/111/1ec/12e1111ec1eb42db8df5e9b055c85eb7.jpeg)
Используя SDA, можно автоматизировать и объединить под одной «крышей» такие операции как:
1. Получение исходного кода из различных источников – файловая система, среды версионного контроля (Git, Subversion и т.д.)
2. Сборка кода через интеграцию с Jenkins, Apache Maven и т.д.
3. Моделирование сценариев доставки и установки изменений для всего приложения или его отдельных компонент. Сюда могут быть включены как простые задачи, вроде переноса файлов, так и более сложные, типа запуска скриптов обновления данных в БД, установки веб-приложений на IIS, Aphache и другие веб-сервера, запуск различных скриптов, снятие снэпшотов виртуальных машин, запуск тестов после установки и т.д.
4. Ручной и отложенный запуск развертывания, отслеживание прогресса установки, просмотр логов.
5. Последовательная или параллельная установка на несколько сред (например, на тестовую и боевую или на несколько боевых).
И так далее. Возможности достаточно обширны.
Важно, что абсолютно вся настройка происходит через общий веб-интерфейс системы.
Я начну с создания процесса развертывания небольшого ASPX-отчета. Отчет выдает информацию из базы данных на MS SQL и хостится на веб-сервере IIS. Также у нас есть SQL Update скрипт для обновления данных, который нужно выполнить после установки свежей версии.
Начнем с того, что настроим получение кода из репозитория Git’a. Для этого создадим новую компоненту, дадим ей имя, укажем ветку и путь к клиенту Git:
![](https://habrastorage.org/files/145/19e/bb6/14519ebb678e465c8fbf054ff54952b4.jpg)
В отдельном репозитории хранятся SQL скрипты. Аналогичным образом создадим для них компоненту.
Далее переходим к описанию процесса установки каждой компоненты. Процесс установки aspx-отчета представлен ниже:
![](https://habrastorage.org/files/3d1/88c/fd5/3d188cfd5c684a5e90110a9c0ed9141a.jpg)
Первый шаг загружает все артефакты (файлы) в нужную мне директорию на сервере, второй шаг перезапускает веб-сервер через команду строку.
Список доступных операций по взаимодействию с различными системами определяется используемыми плагинами. В состав SDA их входит порядка 80-ти штук. Если интересно, с полным списком можно ознакомится здесь.
Отдельный процесс описывает запуск SQL скриптов. Схема похожая – скрипты загружаются на сервер и затем запускаются (через sqlcmd):
![](https://habrastorage.org/files/d9e/6a8/a75/d9e6a8a757d5480da0ad829aa4540624.jpg)
Каким образом SDA осуществляет все эти действия на удаленном сервере? Через отдельную программу-агента, доступную для различных платформ. Т.е. агента SDA нужно установить на сервер. Иногда это невозможно. В этом случае используется так называемая «agentless» конфигурация, когда развертывание происходит без участия агентов. Типичный сценарий — подключаемся к серверу по SSH, из командной строки запускаем команды обновления исходных файлов с того же Git, копируем файлы в нужные папки, перезапускаем процессы, если надо. Это прямой ход развития событий. И везде нужно проверять, что есть место на диске, что все файлы получены, что всё нормально скопировалось куда надо и т.д. и т.п. И предусмотреть действия по откату и зачистке сервера после своих действий.
Объединяющим элементом будет конфигурационный объект, который в системе называется «Application». Создадим такой и начнём его настройку с добавления наших компонент:
![](https://habrastorage.org/files/fdf/6b7/503/fdf6b7503ea941078e29528e4a959a4b.jpg)
Далее настроим окружение (слово «окружение» здесь больше подходит, т.к. серверов может быть много), на котором будем проводить развертывание:
![](https://habrastorage.org/files/e0c/6d3/064/e0c6d3064cb2415fb78e512f60e04180.jpg)
И последнее. Создадим процесс, объединяющий процедуры установки обоих наших компонент (application process):
![](https://habrastorage.org/files/eb7/5d4/ad7/eb75d4ad7d2b410e94ece7283ece7ad4.jpg)
На этом всё, теперь запустим процесс. Можно отслеживать состояние развертывания в режиме real-time:
![](https://habrastorage.org/files/6c6/a07/4b3/6c6a074b39af46bcbb6e2bbeae94b083.jpg)
Или посмотреть результаты после завершения:
![](https://habrastorage.org/files/0d2/f92/128/0d2f9212878943eaaa1f78976ecf49ec.jpg)
Внутри каждого шага хранятся логи выполнения. Если что-то пошло не так, это сразу будет видно. Например, вот логи выполнения SQL-update скрипта:
![](https://habrastorage.org/files/940/c9f/cb7/940c9fcb7b3b4131827c634e1a93c66a.jpg)
Заключение
Пока мой пример слишком простой, чтобы что-то рекомендовать или оценивать пригодность подхода.
Что еще надо попробовать:
- Насколько легко и удобно будет настроить вариант без агента, т.к. в большинстве случаев в хостингах не позволят поставить агента SDA, включая все нужные проверки после каждого действия
- Нужно посмотреть, как в наш сценарий добавить обработку ошибок, откаты (rollbacks) и восстановление предыдущей версии
- Попробовать запустить тесты после развертывания
Посмотреть на красивые картинки, почитать описание производителя и скачать всё это добро можно здесь.
Собственно, на этом всё. Надеюсь, тема автоматизации процессов развертывания кому-то интересна. Задавайте, пожалуйста, вопросы в комментариях. Очень интересно, что вы об этом думаете.