Кожній гілці по хосту c допомогою capistrano

Думаю, багатьом знайоме поняття «боротьба за staging», коли всі розробники одночасно за день до релізу хочуть поділитися своїми напрацюваннями, щоб тестувальник їх перевірив як можна швидше і не довелося всю ніч правити баги, так? Кому цікаво подивитися як ми вирішуємо цю проблему для RoR-проектів за допомогою Capistrano прошу під кат.



Трохи про інструменти
Кожен новий тікет ми робимо в окремій гілці, як радить це git-flow. Як таск-менеджера/баг-трекер ми використовуємо JIRA, тому номер тікета в JIRA = назві гілки. Jenkins CI ми не використовуємо на повну потужність, поки тільки для деплоя коду на staging розробницьких версії після мержа в неї для інтеграційного тестування.

Суть проблеми
Хотілося мати можливість перевіряти кожен тікет ізольовано, і в реліз брати тільки перевірені тікети, а ті що містять баги — залишати на наступний.

Що крім Capistrano?
Розглядалися різні варіанти від шарінга робочої машини за допомогою ngrok до SaaS зразок teatro. Перший варіант виявився незручний, а другий відпав тому що не всі проекти є можливість відправити третій стороні. Тому зважаючи на те, що всі наші RoR-проекти деплоятся з допомогою capistrano, було прийнято рішення написати невелике розширення, яке буде розгортати проект з певної гілки на свій хост (наприклад, jira-123.example.com).

Процес
Якщо коротко, то процес розробки виглядає так: після виконання тікета розробник виливає його на демо-хост, після перевірки тестувальником створюється мерж реквест, після закриття якого Jenkins виливає майбутній реліз на staging.

Що робить capistrano-demo
Все те, що робить розробник при розробці виливає код, накочує міграції і запускає сторонні сервіси (sidekiq, resque і т. д.).

Даний плагін має ряд обмежень, найбільше це те, що він працює тільки для RoR-проектів, і тільки з git.

Налаштування
# За замовчуванням використовується одна БД для всіх хостів, якщо є деструктивні міграції, 
# то гем дає можливість вручну вписати ім'я БД
set :demo_db, -> { demo_default_db }

# Хост, на піддомені якого буде створювати демо-хост
set :demo_host, -> { fetch(:application) }

# Команда яку потрібно виконати при рестарті хоста.
# Приклад одне з наших проектів, де потрібно перезавантажити unicorn, nginx і sidekiq:
# invoke 'unicorn:restart'
# invoke 'sidekiq:restart'
# execute :sudo, :service, 'nginx restart'
# execute :rake, 'cache:clear'
set :demo_restart_cmd, -> { raise 'You must specify "demo_restart_cmd" proc' }

# Папка, в якій лежать шаблони конфігів, для конкретного оточення
# Приклад:
# File.expand_path("../../../../config/stages/#{fetch(:stage)}/templates", __FILE__)
set :demo_templates_dir, nil

# Хеш, для налаштування який шаблон куди покласти після компіляції, шаблони повинні бути .erb
# Приклад:
# set :demo_templates_entries, [
# {template: '/nginx.conf.erb', file: demo_path.join('config', 'nginx.conf')},
# {template: '/database.yml.erb', file: demo_path.join('config', 'database.yml')},
# {template: '/unicorn.rb.erb', file: demo_path.join('config', 'unicorn.rb')},
# {template: '/settings.local.yml.erb', file: demo_path.join('config', 'settings.local.yml')}]
set :demo_templates_entries, []

Як користуватися
Даний плагін має всього три команди:

  • demo:create — створення/оновлення демо-хоста
  • demo:restart — перезавантаження
  • demo:destroy — Зупинка процесів(налаштовується за допомогою before/after) і видалення директорії.
Щоб створити демо-хост потрібно просто з робочої директорії набрати команду cap staging demo:create і все. За замовчуванням буде запропоновано вилити поточну гілку.

Висновок
На даний момент найбільша проблема-це довга збірка ассетов, потрібно змусити його не перезбирати всі, а тільки диф. А також, чия-то міграція може зламати чужі хости, тому на staging ми тримаємо чисту базу, на такий випадок. Були спроби робити окрему БД для кожної гілки, але тоді доводилося створювати або порожню БД, або копіювати. Перший варіант поганий тим, що доводилося б забивати контент для тестування, а другий — немає універсального засобу для копіювання даних для кількох СУБД, але в майбутньому плануємо зробити адаптери для SqlLite, MySql і Postgres.

Наші напрацювання ми виклали в відкритий доступ, тому кожен може ознайомитися і скористатися, pull request'и вітаються.

PS: В коментарях готовий відповісти на ваші запитання, вислухати альтернативні варіанти рішення і конструктивну критику.
Про що б ви ще хотіли дізнатися з нашого блогу

/>
/>


<input type=«checkbox» id=«vv68293»
class=«checkbox js-field-data»
name=«variant[]»
value=«68293» />
Детальніше про процес розробки
<input type=«checkbox» id=«vv68295»
class=«checkbox js-field-data»
name=«variant[]»
value=«68295» />
Що робити, якщо на сервері немає доступу до інтернет

Проголосувало 20 осіб. Утрималося 8 чоловік.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.