Pull to refresh

Semaphore App. Ruby on Rails. Continuous Integration/Delivery

Reading time 4 min
Views 8.1K

Предисловие


Побегав по Хабру, я на удивление не нашел ни одной статьи про полноценный team workflow с использованием различных магических причуд в духе Continuous Integration & Continuous delivery, различные интеграции Github — HipChat(Slack) — CI — Staging and Production via Continuous Delivery, и прочего, хотя я может просто искать не умею.



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

Итак, под катом — разбор CI сервиса SemaphoreApp, немножко про интеграцию с другими сервисами и прочие радости, которые упрощают нам жизнь.

Суть


Знаете, я уж не буду подробно разъяснять, что такое CI, зачем он нужен, и прочие общие вещи, ибо их уже многие господа объяснили до меня, причем хорошо_понятно_наглядно, скажем, тут: «Введение в Continuous Integration».

А теперь, к главному — подключим наше Rails app к Semaphore.

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

Sign up

Заходим на semaphoreci.com, и классный дядька похвастается нам, как классно он деплоит на продакшен.



У нас есть выбор между GitHub и Bitbucket. По сути, Semaphore поддерживает кучу продуктов Atlassian — Bitbucket, Hipchat, Jira.

Неплохо так.



Далее просто выбрать проект и ветку, которую вы хотите билдить.



Нам предложат сделать первоначальные настройки проекта. Из предложенных языков — Ruby, Clojure, JS, PHP, Go, и мифический язык «Other».

Есть вариации с используемой БД.



И — все. У вас есть свой CI, 5.times { puts 'hooraaay!' }



По сути — самое простое, просто потыкать кнопочки. Сложность всей интеграции с другими сервисами будет зависеть от вашего умения нажимать CTRL+C и CTRL+V. Ну, и читать по-английски. Уровень уверенного пользователя ПК, бухгалтера-переводчика.

А, к слову — интеграция с GitHub и Bitbucket уже случилась. Если ваш билд не прошел — merge pull-request сделать еще можно. И получить по ушам от тимлида, за обваленный билд.



Кстати, если у вас конфликтуют ветки, то после билда, даже прошедшего — Semaphore не даст вам смержить ваш конфликтующий PR, пока вы не сделаете git rebase -i your_integration_branch, и не пофиксите все конфликты.

Ну, а если у вас зеленый свет, и, как в правильной команде вам сделали ревью вашего pull-request'a, и поставили OK — можете нажимать заветную кнопку, и похвастаться на стендапе следующего дня.



Communication

Итак, перейдем к следующей части нашей системы — к оповещениям о успешних/неуспешных билдах, и просто о внутрикомандной коммуникации.

Вариаций масса, я предложил просто HipChat или Slack. Почему — оба бесплатны, Slack приятнее выглядит, но ограниченные интеграции(всего 5), их малость поменьше, чем у HipChat'a. HipChat — unlimited integrations, а в целом — тот же Slack, только выглядит скучновато. Не для модных стартапов.

Небольшой пример со всеми интеграциями, что я проделал в одной комнатке Хипчата.



Собственно, тут все логи того, что произошло с проектом. И это далеко не все, что туда можно заинтегрировать. Ошибки с Airbrake, NewRelic alerts, и много много еще.

Теперь можем и посмотреть, что же может Semaphore. Список настроек в студию.



Настройки билда, configs, ENV vars, информация о репозитории, можно задать приоритетные ветки для билдов, запускать билды по расписанию (не придумал, зачем), deployment (о котором чуть позже), вкладка Notifications, которая парой копипастов настраивает вам оповещения на email/hipchat room/slack room/еще_куда_нибудь, и так далее.

Для Hipchat'a вам надо лишь знать room name, или room ID, и token, которые легко генерируются в настройках HipChat'a. Стоит вбить — и notification service готов. Easy.

Ну, и конечно есть webhooks, если вам нужно настроить оповещения куда-то еще.

Continuous Deployment

Но, пожалуй, стоит завершить мой рассказ на ноте Continuous Deployment with Heroku.

То фиолетовое сообщение в картинке с интеграциями в HipChat и было оповещение от Heroku о успешном деплое. Хотя, руками ничего и не делал, просто смержил мой pull-request, который прошел ревью. За меня все сделал Semaphore, и я могу вообразить себя тем успешным дядькой, который предлагал нам использовать этот сервис.

Скажем, у нас есть уже Rails приложение, и есть Heroku server, и наш workflow — делать ветку, писать фичу, писать тесты, прогнать тесты в ветке, запушить в integration ветку, прогнать все integration тесты. Если успешно — git push heroku.

По правде говоря, запушить на стейджинг с Continuous Delivery у меня заняло бы меньше времени, чем описать workflow.

Начнем с интеграции — настройки, вкладка Deployment, Add Server. Нам предлагают выбор.



Я решил на heroku, ваш выбор — за вами. Затем нам предлагают выбрать тип deployment: automatic или manual. Первый деплоит каждый_успешный_билд, что значит, если билд не успешный — он никуда не попадет, а второй способ предоставляет вам чемоданчик с красной кнопочкой, по нажатию которой билд будет отправляться на ваш сервер. Мы ленивые, к тому же наш сервер пусть считается за стейджинг, а для стейджинга пойдет и автодеплой. Для продакшена лучше уж по кнопочке.

Затем нам предложат выбрать ветку для деплоя и ввести Heroku API key. А дальше оно все само умеет.

Еще можете поставить аддон для heroku — Deploy Hooks, в котором есть HipChat hook, который будет вас извещать об успешных, или неуспешных деплоях. Хотя неуспешных деплоев не будет, если билд не пройдет, повторюсь — деплоя не будет.

Надеюсь, кому-нибудь это пригодится.
Tags:
Hubs:
+11
Comments 5
Comments Comments 5

Articles