Версионность кода между тестовым/боевым сервером?

Question

[Алксандр Коротаев]

Есть крупный проект, более 1500 файлов. В соответствии с правилами разработка ведется на тестовом сервере, и при принятии определённых фитч, исправленные файлы методом копирования мигрируют на боевой сервер. На обоих серверах поднят svn, ci.


Столкнулись со следующими проблемами:

1. Некоторые товарищи правят баги на боевом сервере, т.к. на тестовом на этот код уже накручены фитчи, а потом забывают внести эти изменения на тестовом. Что выясняется при следующем копировании этих файлов с тестового на боевой.
   
2. Фитчи бывают сложными и задевают кучу изменений в различных подпроектах. Зачастую бывает так, что эти подпроекты не мержатся, что тоже вызывает кучу непонимания…
   
3. Некоторые фитчи тестируются месяцами, и в конце оказывается, что разработчики не помнят какие файлы надо сдавать на боевой, чтобы всё заработало как надо и ничего не упало.
   

Поэтому хочется поспрашивать хабранарод, как у них решено данная проблема?

Comments

[Всеволод]

Я не очень понял, как вы используете SVN.
> исправленные файлы методом копирования мигрируют на боевой сервер
И используете ли вы его вообще.

[Алксандр Коротаев]

просто на одной ветке trunc — тестовый сервер, на другой main — боевой. К каждой привязан CI со сборкой и тестами…

Answer 1

[Shedal]

Непонятно, зачем разработчики имеют доступ к svn продакшн-сервера. Кстати, зачем на нем вообще нужен svn? Не достаточно ли иметь там только последнюю сборку приложения?
А так, да, если у ввс есть сколько веток разработки, ведите основную в trunk, остальные в branch'ах, при необходимости делайте merge.

Comments

[Алксандр Коротаев]

Не достаточно. Иногда приходится откатываться… Да и фитча фитче рознь. Некоторые месяц пишутся, а некоторые за 2 дня…

[Shedal]

Непонятно. Зачем вам нужен отдельный svn на продакшн-сервере, чтобы откатиться на предыдущую версию?
Мы делаем так: когда деплоим, записываем в папку с приложением файлик version.txt, в котором содержится текущий номер ревизии SVN.
Если нужно откатиться, то забираем из истории SVN нужный номер ревизии и деплоим его.
Естественно, нужно еще и базу данных откатывать на нужную версию, чтобы она соответствовала версии приложения.

Answer 2

[mark_ablov]

git + бранчи.

Comments

[Алксандр Коротаев]

Рассматривалось такое, не можем найти хоть какие нибудь best practices, когда через ci можно было бы это всё завертеть.

[mark_ablov]

hudson не смотрели? там есть и use case.

[Алксандр Коротаев]

спасибо, счаз посмотрю…

Answer 3

[Искандер Гиниятуллин]

в транке лежит продакшн версия + багфиксы, все фичи делаются в бранчах, после успешного тестирования на дев-сервере бранч мержится с транком и заливается на продакшн-сервер.

Comments

[Алксандр Коротаев]

Вы реально работали в группе с бранчами и мержем в svn??? У нас есть примеры, когда мерж занимал неделю…

[Алксандр Коротаев]

между дев сервером и продакшином втыкаем еще один сервер, на который для сдачи/приёмки выкладываем фитчи. выкладывать тест сервер на продакшен нельзя, т.к. там всегда есть непринятые фитчи… как тогда?

[Искандер Гиниятуллин]

Реально работали и работаем.
С мержем иногда бывают проблемы, но чаще не с временем выполнения, а с конфликтами во время мержа.

Многие советуют переходить на git и т.д., но как-то SVN уже привычен и не хочется переучиваться.

[Искандер Гиниятуллин]

ХЗ как тогда в вашем случае поступать.

У нас разработчики работают на собственных машинах, имеется отдельная тестовая машина, на которую разработчики заливают свой бранч для тестирования.

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

Такого понятия как «непринятые фичи» у нас не бывает, любая фича перед реализацией сначала обсуждается. Бывают баги, но они исправляются, еще раз тестируются, и потом все заливается.

[Алксандр Коротаев]

вот конфликты и напрягают… офанаренно напрягают… иногда из за конфликта сдыхает функционал, который активно разрабатывался другим разработчиком

[Алксандр Коротаев]

т.е. у вас разработчик сливая свой бранч для тестирования на тестовый сервак затирает бранч другого разработчика? тестеры не ругаются???

[Искандер Гиниятуллин]

Да, разработчик заливая свой бранч на тестирование затирает бранч другого разработчика.

Нет, тестеры не ругаются, потому что графики сдачи фич и тестирования расписываются заранее:
например, разработчик А должен к 21 июня сдать на тестирование фичу «новая страница регистрации». 22-23 июня тестеры ее проверяют, 23 июня разработчик Б сдает на тестирование «новая региональная выдача», ее тестируют 24-27 и так дальше по конвееру.

Ну и у нас команда разработчиков и проект не слишком объемный, поэтому пока хватает такой системы

Answer 4

[Алексей Куликов]

У нас модель такая:

* Trunk де факто не стабилет
* Из Trunk раз в месяц ответвляем «релиз-год-месяц» и он через месяц попадает в продакшн
* Все баги фиксятся только в боевом релизе
* Все фичи в транке
* Тим-лид раз в день мёрджит релизы назад в транк

Например, сейчас у нас активно две ветки: 1106 (сейчас на боевом сервере), 1107 (будущий релиз) и trunk (оттуда фичи самое раннее будут в продакшене в августе).

Comments

[Алксандр Коротаев]

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

[osypchuk]

вот пусть ваш коммерческий отдел сам программирует, если им лень ждать неделю фичи, а вы найдите себе работу от которой не будет болеть голова.
используемый подход однозначно увеличивает количество багов и необходимость их фиксить на лету — прям замкнутыый круг какой-то. Если будут сопротивляться — предложите им поменять в машине на ходу колесо.

Answer 5

[xSus]

У нас была такая практика:
1) несколько бренчей. в мейне всегда лежит последняя утвержденная версия. т.е. то что можно выкладывать на боевой сервер.
2) разработка новой фичи идет в отдельной ветке, на которуе ежедневно мержится мейн. код с ветки попадает в мейн после утверждения и тестирования.
3) перед выкладкой на боевой сервер создавалась ветка, в которую вносились только фиксы. после каждого фикса ветка мержилась на мейн.

главное не перепутать направление мержей.
Если сейчас еще найду статейку — ссылку прикреплю.

Comments

[xSus]

вроде эта agile version control