Множество версии на Rails приложение

[thebravoman]

Здравейте,

Eх, че е хубаво да пишеш на български език. Ще се радвам ако някой
може да съдейства.

Имам rails приложение и искам върху една машина да работят две версии
на това приложение върху две различни бази
Едното приложение е test_production и работи срещу база
test_production на някакъв порт - 4444 примерно.
Другото е реалното приложение production и работи върху база
production на порт 80.
И двете са през Nginx и passenger.

Въпросът ми е как е най-добре да си организирам версиите на
приложението.
1. Как да маркирам дадено приложение, че е с определена версия - знам,
че може да стане през git тагове или през допълнителни приставки, но
затова търся мнение.
2. Как да сменям версиите и test_production да отива в production.
Примерно в даден момент production версията да е 1.0. test_production
също е 1.0. След това test_production се развива и става 1.0.1 и в
един момент production да стане 1.0.1

Въобще, каква е практиката в такива случаи в rails?

[Boril Boyanov]

Аз лично бих се доверил на Git да върши тази работа.
Но, ако ти се наложи, имаш cp :)

> --
> Това писмо идва от пощенския списък „Ruby on Rails: България“.
> За да се отпишете: ruby-on-rails-bul...@googlegroups.com
> Останалите екстри: http://groups.google.com/group/ruby-on-rails-bulgaria?hl=bg

[Krasimir Angelov]

Здравей,

Ако правилно разбирам въпроса, всъшност искаш стандартен сетъп с production и staging среда, само че и 2те ще са на една и съща машина.

При положение че ползваш capistrano за деплоймънт, то с capistrano-multistage ще можеш да си конфигурираш настройките които се различават в 2те среди (път към проекта, порт и т.н.).

По въпроса с версиите не мога да ти дам съвет, тъй като никога не съм ползвал този подход. Предполагам с git тагове ще можеш да постигнеш каквото ти трябва.

К.

[Valentin Mihov]

Мисля че capistrano multistage е това което ти трябва. То ще ти
позволи да зададеш таг/къмит и бранч на всяка една от stage-овете и да
си ги деплойваш в една команда.

Самият multistage се прави много лесно и нямаш нужда от някакви
добавки за capistrano. Просто използвай параметър с името на stage-а и
после require-вай файл със съответното име.

--Вальо

[Stefan Kanev]

+1 за capistrano multistage.

Ако са на една и съща машина, ще имаш нужда от два различни environment-а (ние имаме production и staging). Така можеш да имаш две различни бази без проблем.

Не съм сигурен как ще ги пуснеш на различни портове. Това зависи от nginx-а - вероятно можеш да го накараш да слуша на два различни порта и да препраща към две различни passanger приложения. Аз бих си го спестил и бих просто направил два различни домейна.

Колкото до кода, ние го правим като имаме два различни бранча - staging и production. Когато искаме да качим нещата от staging в production, просто правим fast-forward и cap deploy. Можеш да си играеш да тагваш версии, но обикновено няма смисъл, ако деплойваш често.

[Kiril Mitov]

Благодаря за насоките. 

Два бранча staging и production без версии за момента ще ми свърши работа.

При fast-forward и cap deploy обаче минаваш през checkout & build, нали? Случвало ли се е да е неуспешен deploy-а на production и по-скоро как го избягвате?

2012/3/27 Stefan Kanev <stefan...@gmail.com>

--
+359 878 93 30 94
Училище по роботика "Robopartans"
www.robopartans.com
robopartans-facebook

"Education is a self organizing system, where learning is an emerging phenomenon...."

[Stefan Kanev]

При нас работим по следния начин:

Никой не push-ва в origin/staging. Вместо това, последната стъпка от jenkins build-а е да пушне в origin/staging, стига билда да е успешен. Така в staging има само успешни билдове. При това, не трябва да правим нищо за целта.

Имаме задаче за деплой, която първо fast-forward-ва origin/production до origin/staging и след това пуска cap.

По този начин, неуспешни билдове не се занасят до production.