aavezel
@aavezel
Веб девелопер

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

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


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

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



Поэтому хочется поспрашивать хабранарод, как у них решено данная проблема?
  • Вопрос задан
  • 3500 просмотров
Пригласить эксперта
Ответы на вопрос 7
Shedal
@Shedal
Непонятно, зачем разработчики имеют доступ к svn продакшн-сервера. Кстати, зачем на нем вообще нужен svn? Не достаточно ли иметь там только последнюю сборку приложения?
А так, да, если у ввс есть сколько веток разработки, ведите основную в trunk, остальные в branch'ах, при необходимости делайте merge.
Ответ написан
mark_ablov
@mark_ablov
git + бранчи.
Ответ написан
uscr
@uscr
Git.
Есть ветка develop, есть master.
Каждый разработчик заводит отдельную ветку под каждую новую фичу. Таким образом можно пилить одновременно неограниченное количество фич, и они не пересекутся.
У каждого разработчика есть минимум одна виртуалка (xen server) для тестов.
После допиливания фичи, ветка этой фичи сливается с develop.

Есть тестовый сервер, на который сливается ветка develop для финальных тестов.

Если на тестовом сервере всё хорошо, develop сливается с master.

Итак. В develop всегда есть условно рабочий «свежак». В master только оттестированый код, готовый к релизу.
Ответ написан
в транке лежит продакшн версия + багфиксы, все фичи делаются в бранчах, после успешного тестирования на дев-сервере бранч мержится с транком и заливается на продакшн-сервер.
Ответ написан
clops
@clops
Rocket Scientist
У нас модель такая:

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

Например, сейчас у нас активно две ветки: 1106 (сейчас на боевом сервере), 1107 (будущий релиз) и trunk (оттуда фичи самое раннее будут в продакшене в августе).
Ответ написан
@xSus
У нас была такая практика:
1) несколько бренчей. в мейне всегда лежит последняя утвержденная версия. т.е. то что можно выкладывать на боевой сервер.
2) разработка новой фичи идет в отдельной ветке, на которуе ежедневно мержится мейн. код с ветки попадает в мейн после утверждения и тестирования.
3) перед выкладкой на боевой сервер создавалась ветка, в которую вносились только фиксы. после каждого фикса ветка мержилась на мейн.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы