Меню
Что нового?

Организация разработки веб приложения с svn

Wade

Новичок
Организация разработки веб приложения с svn

Доброго времени.
Приходится разрабатывать приложения одому. Раньше справлялся с разработкой один. Сейчас понял, что держать все в голове не возможно, поэтому решил немного проапгрейдиться.
Поставил Redmine для баг трекинга, SVN как систему контроля версий(все это на сервере).
Начал пользоваться - понравилось. Но вот возник вопрос как разрабатывают приложения на других предприятиях.

Сейчас у меня схема такая: в IDE (Zend Studio) есть проект, тут я его правлю, потом делю commit на сервер, дальше делаю checkout на сервере и смотрю что получилось. Но чувствую, что это во-первых долго, во-вторых неправильно.

Есть мысль поставить на рабочую станцию lamp и отлаживать там, и только после отладки на рабочей станции заливать в svn и там делать checkout и тестить на сервере. При таком раскладе придется следить за тем чтобы и базы данных были идентичны и еще массу вещей.

Подскажите, как Вы разрабатываете веб приложения.

ЗЫ Немного оффтоп вопрос - в zend studio можно сделать checkout на удаленном сервере? что то я ни как не могу найти такой фишки, чтобы каждый раз не апдейтить через удаленную консоль.

Спасибо
 
point

point

Новичок
За Redmine респект. Очень удобная софтинка.
Мысль поставить LAMP на рабочую машинку очень даже здравая.

А по поводу рабочего процесса.
Можно сделать ветку в СВНе, делая эксперементальные коммиты в нее. Когда будет ясно, что код ветки вполне стабильный, она сливается с master-ом.

А на сервере можно нарисовать простейший bash-скрипт, который будет делать deploy из master-a. Например, раз в час проверяя ревизию master-а.

Вот только проблемы с базой данных не получится так просто решить в автоматизированном режиме.
 
Krishna

Krishna

Продался Java
Моё ИМХО такое:
1. Разработка всегда должна идти на платформе идентичной боевой и соответственно тестовой. По-этому, никаких "рабочих" станций, если конечно на них не та же ось и те же версии софта. Любителей Денвера - повесить на отдельной рее.
2. Некоторые люди почему-то думают, что системы контроля версий сделали вместо фтп для залива файлов на сервер. Они идиоты (с). Не стоит брать пример.


Как я делаю - поднимаю самбу и работаю с сервером разработки как с локальным диском. При этом у каждого разраба отдельный домен со своей рабочей копией. В свн коммитится только рабочий код (если используются юнит тесты, то только оттестированный). Дальше уже, при желании его можно выливать в автоматическом режиме на тестовый сервер. У свн есть триггеры - скрипты которые срабатывают после определенных действий. На них можно повесить любые команды.

http://svnbook.red-bean.com/nightly/ru/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Ещё раз - репозитарий в идеале должен хранить исключительо рабочий код. Ведь одна их его задач - возможность отследить прогресс развития проекта в обратном направлении, найти критические "перевалы и разветвления", и, главное, оперативно откатить к предыдущей работающей версии. Разгрести их в куче нерабочего хлама будет непросто.

Это речь шла о разработке "в одно рыло". А если работает группа, то вообще лить туда непроверенный мусор (а именно так и происходит, если мы сначала коммитим, а потом пытаемся запустить) вообще означает мешать остальным - ведь они будут сливать к себе нерабочий код.

Иногда можно делать осознанные исключения, но именно исключения.
 

Wade

Новичок
Спасибо за советы. Можно пару примеров как реально делают на веб-студиях и в компаниях? получается все говорят про технологии, а на деле notepad->ftp->apache))
 
MuXaJIbI41981

MuXaJIbI41981

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

Dovg

Продвинутый новичок
у нас делается примерно так:

1. разработка
Приходим к тому, что trunk стабилен, т.е. способен уехать на прод сразу после тестирования.
Если есть вероятность что-то поломать, то разработчик создает бранч вида dovgNewFeatureName туда постоянно коммитится, после готовности мержит в транк и отдает на тестирование.

2. выкладка: создаем tag из trunk обычным svn copy
На проде, если проект новый, то svn co https://path.to.rep/project/tag
если новая версия существующего проекта, то svn switch https://path.to.rep/project/newTag

3. выкладка на тестовый:
тестовый смотрит в транк, т.е. делаем просто svn up

лично про меня:
окружение на рабочей машинке, тестовом сервере и проде почти одинаковое. (у меня есть иксы, на проде их нет :)

-~{}~ 04.06.09 18:53:

а, еще:

у нас коммитят часто, 10-20 коммитов за рабочий день - это норма.
практика показала, что это удобней, чем отправлять готовыми кусками по тысяче строк )
 

MiksIr

miksir@home:~$
Автор оригинала: Krishna
Нет, бранчи существуют не для этого.
Нажмите для раскрытия...
Ну в том числе и для этого. Если начато ломание кода и не закончено - комитим в ветку. Или сразу, если в ломании участвует кто-то еще, или через день-два, если так и не починили. В конце концов, даже в ломании есть свои стадии, которые могут потребовать отката, просмотра, осмысления и т.д.

-~{}~ 04.06.09 21:14:

Dovg, а в чем смысл выкладки по тегам, если у вас транк - стабильный.
 
nw

nw

Новичок
А вот насчёт базы как кто решает?
Если точнее: как у вас производится синхронизация боевой БД с БД тестового сервера?
 
Krishna

Krishna

Продался Java
MiksIr
"Начато ломание" - это осознанный процесс, те самые исключения, о которых я упоминал. А я был против залива непроверенного на работоспособность кода, как правила. Если бранч не является именно временно нерабочим, то тогда хоть бранч, хоть не бранч - заманаешься рабочую версию заполучить из свна.
 
Adelf

Adelf

Administrator
Команда форума
>> Если точнее: как у вас производится синхронизация
>> боевой БД с БД тестового сервера?

Думаю, что в 99% случаев - руками. 1% - скрипты обновления пишутся. Потому что синхронизировать нужно очень избирательно.
 

Gas

может по одной?
>боевой БД с БД тестового сервера
>>1% - скрипты обновления пишутся

как раз попадаю в этот 1%
 
nw

nw

Новичок
Скрипты - подразумевается внутри какого-то инструмента, или обычные perl/php etc?
UPD: т.е. писали собственный tool или может быть на базе каких нить EMS и проч?
 

Gas

может по одной?
У нас обычные php-скрипты, нет фич как у миграций ruby.
Тлеет мысль о переходе хотя бы на миграции от доктрины, но так как этот orm не используется и хитрые вещи особо не нужны, то просто неспеша обдумывается целесообразность этого.
 

MiksIr

miksir@home:~$
Автор оригинала: Krishna
MiksIr
"Начато ломание" - это осознанный процесс, те самые исключения, о которых я упоминал. А я был против залива непроверенного на работоспособность кода, как правила. Если бранч не является именно временно нерабочим, то тогда хоть бранч, хоть не бранч - заманаешься рабочую версию заполучить из свна.
Нажмите для раскрытия...
У кого исключения, у кого - процесс разрабоки. Может у кого-то разработка - это мелкие патчи на основную ветку, то у кого-то - это постоянный рефакторинг и новый функционал. Над которым обычно работают несколько человек, да и если один - совершенно не устраивает, что это будет валяться у него в локальной копии неделю, а потом патч будет нечитаем совершенно.

-~{}~ 05.06.09 16:48:

Автор оригинала: nw
А вот насчёт базы как кто решает?
Если точнее: как у вас производится синхронизация боевой БД с БД тестового сервера?
Нажмите для раскрытия...
diff схем автоматом, какие-то данные если нужно внести - руками, думаем как автоматизировать.

-~{}~ 05.06.09 16:49:

Krishna, я вот не понимаю... вы за то, что любая ветка должна быть стабильной? А в чем смысл этого? Стабильность транка - это в угоду непрерывной интеграции, а стабильность веток в угоду чему?
 
AmdY

AmdY

Пью пиво
Команда форума
http://www.devart.com/ru/dbforge/mysql/studio/
там вроде заявлено о инструментах для сравнения схем.
 

Gas

может по одной?
инструменты для сравнения схем это хорошо, но как они решают такую проблему:
делаются несколько "фич", каждая из которых вносит изменения в структуру db. Какая-то фича готова и нужно опубликовать на продакшн, включая только изменение схемы специфичное для неё.
Сравнивать руками схемы и по помяти вносить на продакшн изменения ?
 
Войдите или зарегистрируйтесь для ответа.
Сверху