Выпуск версии программного продукта с использованием cvs, subversion, etc

[pachanga]

Выпуск версии программного продукта с использованием cvs, subversion, etc

Данный сабж остро возник на нашей фирме после достаточно длительной и упорной разработки. Теории по нему предостаточно, однако хотелось бы услышать от знающих людей советы(или линки на эти советы) о том, как это все бывает на практике.

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

Естественно, разработка ведется полным ходом, и хотя мы стараемся применять test-driven разработку(по мере сил и времени) бывают случаи, что баги всплывают совершенно в неожиданных местах на продукционных сайтах.
Поэтому было решено выпустить версию 1.0 "движка"(пользуемся мы subversion, т.е сделать branch от основного trunk).

Все вроде звучит логично, однако, получается, что также необходимо и сделать по отдельной ветке для каждого проекта, который стабилен на версии "движка" 1.0, и отдельную ветку для проекта на текущей версии движка(trunk).

Когда список проектов переваливает за 20 - становится несколько не по себе.

Проблема еще и в том, что "движок" также использует библиотеку, отвечающую за самые базовые операции, для которой, в свою очередь, необходима отдельная ветка....
Ну а в свете того, что сейчас активно точится версия "движка" 2.0 и вообще становится очень грустно именно с точки зрения технической поддержки.

Крайне буду благодарен за конструктивные советы и идеи, как выжить в этом хаосе

 

[tony2001]

вообще, вопрос задан в какой-то замороченной форме.
проблема в том, что у вас есть продукт, который вы используете в других продуктах и все они находятся в CVS ?

тогда не совсем понимаю:
есть сайт ААА, который использует CMS ZZZ.
проект ААА не включает в себя CMS, только project specific файлы.
в соотв-ю директорию делаем чекаут CMS ZZZ и в дальнейшем cvs будет забирать проект из своего репозитория, а CMS - из своего.
таким образом, у нас не получится ситуация:
-stable-ветка проекта ААА с CMS из ветки dev
-stable-ветка проекта ААА с CMS из ветки stable
-dev-ветка проекта ААА с CMS из ветки dev
-dev-ветка проекта ААА с CMS из ветки stable

а будут отдельные проекты ААА и CMS ZZZ, которые, правда, должны быть в обоих случаях совместимы между собой.
о том вообще речь?

 

[pachanga]

да именно об этом и речь:

1) только проект AAA не использует project specific ZZZ, а использует ее полностью и иногда расширяет дополнительной функциональностью

2) наверное имелось включить некоторую версию cms полностью в проект - так сделать можно, но как это поддерживать, если более 20 проектов?

 

[tony2001]

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

2) в смысле? при изменении версии ядра апдейтишь его с CVS (или откуда-то еще) и дальше используешь. или я не так понял?

 

[Crazy]

Правильно ли я понял, что проблема в том, что имеется значительное количество веток, которые приходится параллельно поддерживать?

 

[tony2001]

Crazy:
проблема в том, что в каждый проект - отдельная ветка, которую он хочет как-то синхронизировать с основной.
плюс есть еще разные ветви у самих проектов.

 

[Crazy]

Мне всегда казалось, что бранчи делают с двумя целями:

1. Срочно выпустить версию и забыть про этот бред навсегда.
2. Внести временные изменения, чтобы потом слить с основной линией.

У меня сложилось впечатление, что в данном случае автор треда порождает бранчи, но джойнить их забывает. Нет?

 

[tony2001]

не совсем =)
вот мое представление о проблеме:
у него есть продукт ААА, который включен в другий продукты.
этот продукт ААА имеет ветви.
продукты, в которых он используется, тоже имеют ветви.
вероятно, эти ветки когда-то джойнятся, но трабл в том, что в разных ветках продуктов находятся разные версии продукта ААА.
бардак, короче говоря.

 

[Crazy]

Автор оригинала: tony2001
эти ветки когда-то джойнятся, но трабл в том, что в разных ветках продуктов находятся разные версии продукта ААА.
бардак, короче говоря.

Это соответствует тому, как я понял проблему. Особенно -- в части "когда-то". Т.е. не на регулярной основе, а когда придется.

 

[HEm]

по крайней мере хорошо документировать все изменения

 

[tony2001]

>Т.е. не на регулярной основе, а когда придется.
я забыл добавить "наверное".
автор-то молчит.

 

[Romantik]

Вопрос в тему:
Я когда сделал ядро, появились ветки, где у клиента другие расчеты и алгоритмы
Но ядро продолжаю совершенствовать и с ростом клиентов получается жуть!
Я просто под каждую категорию клиента (их формулы и логика) храню в базе, подключая в конфиге соотв. а ядро дальше улучшаю спокойно.

Такой подход нормальный?

 

[Crazy]

To tony2001: IMHO, при регулярном джойне (по окончании активной фазы очередного проекта) такая ситуация вообще не должна возникать.

 

[Crazy]

Автор оригинала: Romantik
Но ядро продолжаю совершенствовать и с ростом клиентов получается жуть!

Мне кажется разумным такой подход: если клиент получил ядро версии X, то эта версия поддерживается ограниченное время, после чего клиент либо переходит на ядро актуальной версии, либо лишается поддержки.

 

[Romantik]

Crazy ну это понятно, а к примеру ошибка в ядре?
Я воообщем спарашиваю за такой подход.
Нормально?
Ничего мне в будущем жуткого не грозит? =)

 

[pachanga]

Немного опаздываю с ответом, дело обстоит так:

1)есть версия ядра ZZZ, которая НЕ ИЗМЕНЯТСЯ определенным проектом AAA, но ZZZ может быть расширена("обрастает довесками") в пределах архитектуры для частного случая AAA

2)можно поместить текущую стабильную версию ZZZ в AAA, и там она будет существовать СОВЕРШЕННО ОТДЕЛЬНО от текущей разработки, однако, когда проектов получается много, получается очень неудобно поддерживать проект AAA вместе со своей собственной, скажем, ZZZ_1. (Исправление найденного бага придется дублировать для каждого проекта и проч.)

3)как могут помочь branches: допустим, мы уверены в текущей версии ZZZ, назовем ее 1.0 и отделим от trunk(просто в subversion используется несколько иной и более гибкий подход к созданию branches: "Subversion doesn't distinguish between filesystem space and “branch” space; branches and tags are ordinary directories within the filesystem. This is probably the single biggest mental hurdle a CVS user will need to climb").

Также выделим и ветку проекта AAA как 1.0 - только потому что он у нас был протестирован с ZZZ 1.0 и, вроде, работает. На этом моменте мы счастливо прекращаем работу с AAA 1.0 и ZZZ 1.0 и работаем только с trunk версиями обоих продуктов.

Допустим, один из работников задумал чумовой рефакторинг ZZZ, тогда он делает еще одну ветку ZZZ, пусть 1.2 и также ветку AAA 1.2. Вот когда работник натестировался вдоволь, он может слить 1.2 версии ZZZ и AAA с trunk, но 1.2 остается в репозитории и мы опять же 1.2 не трогаем больше вообще.

Если была найдена ошибка где-то в 1.0, мы должны локализовать ее только в trunk ветках.

Сами понимаете, это лишь мои предположения о том, как это примерно будет выглядеть, но как-то все это неоптимально что ли....

 

[Crazy]

Автор оригинала: pacha
2)можно поместить текущую стабильную версию ZZZ в AAA, и там она будет существовать СОВЕРШЕННО ОТДЕЛЬНО от текущей разработки

А зачем?

Мне казалось, что достаточно иметь ZZZ отдельным cvs-модулем и сделать релиз для данной стабильной версии. В документации на AAA указываем, какой именно релиз требуется для работы.

Что я упустил?

 

[pachanga]

Все правильно, именно поэтому способ 2) ни куда не годится...

 

[pachanga]

Неужели на этом и порешим?...