Непрерывная интеграция NodeJS проекта с использованием TeamCity

Автор: Сергей Кулага

Один из наших проектов построен на NodeJS c использованием фреймворка Sails.js, базы данных MongoDB, системы обмена сообщений RabbitMQ, и поискового движка ElasticSearch, используются юнит тесты на основе Mocha. Приступили к разработке, вроде и работает, и можно собрать приложение на тестовый сервер и запустить тесты, но все это надо делать вручную и очень утомительно.

Было решено использовать для автоматизации TeamCity. Был использован сервер на Ubuntu, установка компонентов ничем не примечательна, можно только упомянуть, что NodeJS запускается через Forever. Forever нужен для того, чтобы запускать приложение в виде демона, forever проверяет его доступность и перезапускает в случае остановки приложения.

Подготовка на сервере

У нас приложение состоит из двух больших частей: WebSite и WorkHorse, последний используется для выполнения задач по расписанию и обработки задач из очереди (например отсылка писем, индексация, и другое). Эти две части могут масштабироваться независимо друг от друга. Для простоты мы предположим, что у нас только WebSite и один WorkHorse.

Предположим, что приложение работает из-под директории /home/user/node/app/dev.

Для начала создадим два скрипта для запуска и остановки приложения через Forever

start.sh (запуск приложения)

export NODE_ENV=vm-node-dev now=$(date +"%Y_%m_%d--%H-%M-%S") if [ $(forever list | grep dev-website | grep -v grep | wc -l) -eq 0 ] then cd /home/user/node/app/dev/WebSite forever start --uid "dev-website" -l "logs/dev-website-$now.log" app.js fi if [ $(forever list | grep dev-workhorse | grep -v grep | wc -l) -eq 0 ] then cd /home/user/node/app/dev/WorkHorse forever start --uid "dev-workhorse" -l "logs/dev-workhorse-$now.log" app.js fi

Поясение по скрипту запуска

export NODE_ENV=vm-node-dev - задание имя конфигурации, этот параметр используется концигураций как sails.js так и билиотекой config.js if [ $(forever list | grep dev-website | grep -v grep | wc -l) -eq 0 ] проверка запущено ли приложение, forever start --uid "dev-website" -l "logs/dev-website-$now.log" app.js запуск app.js с именем “dev-website” и логгирование в определенную панку (по умолчанию запись консольного вывода из nodejs происходит в файл с автогенерируемым именем, например, 6n71.log, что не очень удобно, поэтому запись логов перенаправлена в dev-website-$now.log). Логи содержат всю информацию, которую приложение выводит на консоль.

stop.sh (Остановка)

if [ $(forever list | grep dev-website | grep -v grep | wc -l) -ne 0 ] then forever stop dev-website fi if [ $(forever list | grep dev-workhorse | grep -v grep | wc -l) -ne 0 ] then forever stop dev-workhorse fi

Установим права для запуска

chmod 700 dev-start.sh chmod 700 dev-stop.sh

Установим автозапуск через crontab

Для установки автозапуска можно добавить start.sh в crontab, например так @reboot /home/user/node/app/start.sh

Резюмируя этот раздел, мы добавили в автозагрузку запуск node.js веб-систем и их автоматический перезапуск в случае падения.

Настройка TeamCity

TeamCity - это билд контроллер, который крутится на отдельном сервере. В нашем случае на корпоративном Windows сервере. Напомню, что сама веб-система находится на другом Linux сервере.

Для копирования данных на Ubuntu сервер и запуска команд по SSH из TeamCity необходимо установить Deployer plugin.

Каждый билд всегда полностью берет версию из source control. Для этого был установлен флаг Clean build на вкладке Version Control Settings. Затем уже скачиваются пакеты nmp и bower. Таким образом, мы всегда имеем чистую последнюю версию. Получение последней версии и скачивание занимает 20-30 секунд, благо, интернет не медленный и размер проекта пока не большой. При желании можно не очищать что, но хотелось иметь всегда чистую версию.

Для тестов используется фреймворк mocha. Для того чтобы TeamCity отображал результаты тестов, используется пакет mocha-teamcity-reporter.

Итак, мы создали два билда:

1. Сборка и запуск автоматических тестов

Этот билд автоматически запускается после каждого checkin-а и прогоняет все тесты. Собирается быстро и используется в основном для контроля прогона тестов.

Список шагов в билде после того как с гита скачана последняя версия сорс кода:

2. Разветывание на тестовом окружении

Список шагов в втором билде:

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

Выводы:

1. Внедрять Continuous Integration следует на самых ранних этапах разработки, можно сразу после создания структуры проекта. Это позволит существенно сократить время на развертывание билдов для тестового и в дальнейшем проще перенести для продакшен окружения.
2. Для проекта на Node.js написание тестов как юнит, так и интеграционных - это “must have” практика, так как нет компиляции проекта и сложно выявлять опечатки.
3. В зависимости от задач можно использовать и другие подходы и инструменты, главное, чтобы все работало без ручного труда, было просто и устраивало команду.
4. Хотя TeamCity на моей практике больше применяется с проектами на .NET или JAVA, мы с успехом используем уже знакомый инструмент и для других языков.

Место солидарности беларусского ИТ-комьюнити

Далучайся!