подход "ветка по необходимости": т.е. все мелкие фичи, багфиксы и прочая мелкота идут сразу в транк (предварительно протестированные на машине девелопера), а на крупные фичи будем отделять ветки, а потом мержить с транком. Делоиться на продакшен будет транк.
Но "всплыл" тестовый сервер на котором заказчику показываются сделанные нами изменения, одобряются (или нет ), тестируются, ... Который как-то выпал из моего внимания.
Возник вопрос: какой код на него деплоить?
Понятно, что не транк, так как код который неодобрен в транк попасть не должен. Теги и бранчи тоже, так как эта "ветка" никогда не закончится, а будет идти рядом с транком на всем протяжении разработки.
Деплоить конкретный бранч тоже не дело, так как разработчиков несколько и каждый хочет показать свои изменения.
Напрашивается решение создать в структуре репозитория паралельно с branches, tags и trunk "каталог" testing (to_test, for_testing, ... не придумал еще нормального названия).
Использовать его будем так:
-- решил показать свои изменения заказчику
-- смержил свой бранч с testing, задеплоил
-- заказчик одобрил
-- смержил свой бранч с транком
-- взялся за следующий таск
В итоге незаапрувленные ветви отдельных разработчиком могут "находится" в одном месте чтобы далее попасть на тестовый сервер; в trunk же эти ветки не попадают.
Все бы хорошо, но смущает меня в этом вот что: я никогда о таком не слышал Т.е. мои размышления смахивают на изобретение костыля. Когда существуют одобренные и проверенные годами практики работы.
Что скажите, господа форумчане?
Какой подход лучше использовать мне для "хранения" кода для тестового сервер?
Кратко: мы разрабатываем вэб-приложение, которое существует в единственном экземпляре на продакшин сервере, релизы каждый конец месяца, между релизами могут идти хотфикс-деплои.
Re: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Aikin, Вы писали:
A>Теги и бранчи тоже, так как эта "ветка" никогда не закончится, а будет идти рядом с транком на всем протяжении разработки.
Это вполне нормальное решение, называется "vendor branch". Для работы с ними, правда, желательно иметь нормальный merge tracking. В SVN1.5 он как раз появился.
Sapienti sat!
Re: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Aikin, Вы писали:
A>Но "всплыл" тестовый сервер на котором заказчику показываются сделанные нами изменения, одобряются (или нет ), тестируются, ... Который как-то выпал из моего внимания. A>Возник вопрос: какой код на него деплоить? A>Понятно, что не транк, так как код который неодобрен в транк попасть не должен.
Это снова я
Вот смотри. Заказчик уже юзает какую-то задеплоенную версию. Задеплоена она у тебя с транка. Тебе надо показать какой-то функционал, который будет одновременно иметь все фичи, которые заказчик уже видит + что-то новое, не обязательно стабильное.
Задача сводится к тому, чтобы показать транк + какую-то дельту поверх него. Соответственно, для деплоймента отращивается отдельный бранч от транка, туда мержатся все изменения с фичей — и всё это деплоится на сервер. Бранч можно отращивать каждый раз новый, чтобы иметь возможность при необходимости "переключать" тестовый сервер с одной демонстрации на другую.
Твой варинт не подходит тем, чтоу тебя на тестовом бранче находится код, который в общем случае не будет up-to-date с кодом на транке, т.е. заказчик может не видеть каких-то фич, задеплоенных на рабочий сервер. Отращивание изменений для тестового сервера каждый раз от транка решит эту проблему.
Тут правда, другой вопрос возникает — причем как с твоим вариантом, так и с моим — как бы так сделать, чтобы несколько девелоперов не попытались задеплоить несколько решений на один сервер одновременно. Но это уже вопрос не к организации работы — для этого лучше выделить отдельную роль на проекте, он и будет по запросу мержить изменения, отслеживать тестирование и деплоить на сервер. Ну или, по крайней мере, будет отслеживать очередь деплоймента разных "тестовых" бранчей для аказчика от каждого девелопера.
A>>Теги и бранчи тоже, так как эта "ветка" никогда не закончится, а будет идти рядом с транком на всем протяжении разработки. C>Это вполне нормальное решение, называется "vendor branch".
Т.е. лучше его поместить в "svn/branches/testing"? В принципе нормально. Ведь, по сути, все равно где хранится код (все равно деплой автоматизирован). Просто хотелось решение поизящнее. C>Для работы с ними, правда, желательно иметь нормальный merge tracking. В SVN1.5 он как раз появился.
Я в своей жизни не провел еще ни одного мержа Вчера только занялся освоением этой науки Сегодня, думаю, будет первый мерж
Но за совет спасибо.
Re[2]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
A>Это снова я
A>Задача сводится к тому, чтобы показать транк + какую-то дельту поверх него. Соответственно, для деплоймента отращивается отдельный бранч от транка, туда мержатся все изменения с фичей — и всё это деплоится на сервер. Бранч можно отращивать каждый раз новый, чтобы иметь возможность при необходимости "переключать" тестовый сервер с одной демонстрации на другую.
Мне очень хочется (я даже настаиваю на том), чтобы на тестовый сервер шел код из одной конкретной ветки. Это нужно для автоматического деплоя.
A>Твой варинт не подходит тем, чтоу тебя на тестовом бранче находится код, который в общем случае не будет up-to-date с кодом на транке, т.е. заказчик может не видеть каких-то фич, задеплоенных на рабочий сервер. Отращивание изменений для тестового сервера каждый раз от транка решит эту проблему.
Да, здесь может быть засада.
Думаю это будет решаться тем, что периодически testing будет чиститься и полностью обновлятся с транка.
A>Тут правда, другой вопрос возникает — причем как с твоим вариантом, так и с моим — как бы так сделать, чтобы несколько девелоперов не попытались задеплоить несколько решений на один сервер одновременно.
Мне кажется, средства версирования должны сами решать эту проблему. Постановкой в очередь, например.
A>Но это уже вопрос не к организации работы — для этого лучше выделить отдельную роль на проекте, он и будет по запросу мержить изменения, отслеживать тестирование и деплоить на сервер. Ну или, по крайней мере, будет отслеживать очередь деплоймента разных "тестовых" бранчей для аказчика от каждого девелопера.
Не нужно это для команды из 3-х человек, работающих в одной комнате
Re: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Aikin, Вы писали:
A>Понятно, что не транк, так как код который неодобрен в транк попасть не должен. A>Теги и бранчи тоже, так как эта "ветка" никогда не закончится, а будет идти рядом с транком на всем протяжении разработки.
Обычно в таких случаях делают бранч. Ничего страшного, что он никогда не закончится.
Re[3]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Aikin, Вы писали:
C>>Это вполне нормальное решение, называется "vendor branch". A>Т.е. лучше его поместить в "svn/branches/testing"? В принципе нормально. Ведь, по сути, все равно где хранится код (все равно деплой автоматизирован). Просто хотелось решение поизящнее.
Да, это вполне нормальное решение.
C>>Для работы с ними, правда, желательно иметь нормальный merge tracking. В SVN1.5 он как раз появился. A>Я в своей жизни не провел еще ни одного мержа
Тогда вас ожидает очень много интересного и увлекательного
Sapienti sat!
Re[4]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
C>>>Для работы с ними, правда, желательно иметь нормальный merge tracking. В SVN1.5 он как раз появился. A>>Я в своей жизни не провел еще ни одного мержа C>Тогда вас ожидает очень много интересного и увлекательного
Сегодня был первый (на svn 1.4). Полет нормальный
Cyberax, еще раз спасибо
Re[2]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Aikin, Вы писали:
A>Открываю для себя использование веток и тэгов в SVN.
Чем изучать правильные способности неправильных VCS, лучше уж сразу перейти на правильную VCS (т. е. распределенную). Там с ветками получше.
В распределенной VCS на каждый чих создается ветка. Сделал checkout — вот у тебя своя локальная ветка. В нее можно локально делать commit, создавать из нее другие локальные ветки. У рабочего сервера будет своя ветка, и у тестового своя. Причем ветка рабочего сервера не обязана совпадать с основной (trunk). Например, добавили в систему какую-то полезную, но некритичную способность, которая пока не требуется на сервере. Протестировали и добавили в основную ветку, а в серверную не стали: ни к чему трогать работающую систему. А вот всевозможные заплатки должны попадать на сервер как можно быстрее. Ветка тестового сервера тоже может быть локальной и ниоткуда не видимой: захотели протестировать работу способностей X и Y вместе, взяли и сделали merge обеих в тестовую ветку и попробовали.
P. S. A>
подход "ветка по необходимости": т.е. все мелкие фичи, багфиксы и прочая мелкота идут сразу в транк (предварительно протестированные на машине девелопера), а на крупные фичи будем отделять ветки, а потом мержить с транком. Деплоиться на продакшен будет транк.
русский язык уже отменили? :-)
До последнего не верил в пирамиду Лебедева.
Re[5]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
RO>Чем изучать правильные способности неправильных VCS, лучше уж сразу перейти на правильную VCS (т. е. распределенную). Там с ветками получше.
Ага, а заодно поменять компанию и проект, которые потребовали ветки, и страну поменять чем приспосабливаться жить в ней, и вообще...
RO>В распределенной VCS на каждый чих создается ветка. Сделал checkout — вот у тебя своя локальная ветка. В нее можно локально делать commit, создавать из нее другие локальные ветки. У рабочего сервера будет своя ветка, и у тестового своя. Причем ветка рабочего сервера не обязана совпадать с основной (trunk). Например, добавили в систему какую-то полезную, но некритичную способность, которая пока не требуется на сервере. Протестировали и добавили в основную ветку, а в серверную не стали: ни к чему трогать работающую систему. RO>А вот всевозможные заплатки должны попадать на сервер как можно быстрее. Ветка тестового сервера тоже может быть локальной и ниоткуда не видимой: захотели протестировать работу способностей X и Y вместе, взяли и сделали merge обеих в тестовую ветку и попробовали.
Все таки, я считаю, что нужно учиться постепенно шаг за шагом, а не рывками отказываясь от старого в пользу новой "панацеи".
RO>P. S. A>>
подход "ветка по необходимости": т.е. все мелкие фичи, багфиксы и прочая мелкота идут сразу в транк (предварительно протестированные на машине девелопера), а на крупные фичи будем отделять ветки, а потом мержить с транком. Деплоиться на продакшен будет транк.
RO>русский язык уже отменили?
Нет:
подход "ветка по необходимости": т.е. все мелкие изменения функциональности, исправления багов и прочая мелкота идут сразу в основную ветвь(не совсем мне нравиться этот перевод) (предварительно протестированные на машине разработчика), а на крупные изменения функциональности будем отделять ветки, а потом сливать с основной. Развертываться на рабочий сервер(этот тоже) будет основная ветвь.
С другой стороны, эти слова просачиваются в лексику нашей специальности (программиста) и с этим ничего не поделаешь. Чаще они точнее отражают смысл чем русский аналог.
Например приемлевого аналога для продакшин сервера (кстати слово тоже заимствованное) я с ходу не нашел. Если назовешь транк стволом -- тебя могут не понять...
Вобщем непонимаю вашего замечания.
СУВ, Aikin
Re[6]: CVS/SVN: Рядом с trunk "стволик" testing. Чем грозит?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Чем изучать правильные способности неправильных VCS, лучше уж сразу перейти на правильную VCS (т. е. распределенную). Там с ветками получше.
Какую именно правильную систему ты бы рекомендовал?
Здравствуйте, Aikin, Вы писали:
A>Ziaw, я так понял, в 1.5 алгоритмы отслеживания изменений в коде заметно "повзрослели"? Ну тогда это действительно хороший повод перейти на 1.5
Отслеживания изменения в коде? Не очень понял вопрос.
Я говорил о том, что в 1.5 наконец-то отпала необходимость записывать историю уже сведенных ревизий, которая в 1.4 сильно напрягала.
Z>Отслеживания изменения в коде? Не очень понял вопрос.
Diff процесс Z>Я говорил о том, что в 1.5 наконец-то отпала необходимость записывать историю уже сведенных ревизий, которая в 1.4 сильно напрягала. Z>пример здесь
Супер! Вот то действительно колбаса!!!!!!!!!!!!!
Спасибо большое. А то я только вчера узнал про "трудности мержа" и немного загрустил. А тут все трудности (о которых я знаю) решены на корню. Класс.
Здравствуйте, nikov, Вы писали:
RO>>Чем изучать правильные способности неправильных VCS, лучше уж сразу перейти на правильную VCS (т. е. распределенную). Там с ветками получше. N>Какую именно правильную систему ты бы рекомендовал?
Я пока всем рекомендую Mercurial — он нормально работает на всём, что только можно придумать, и для него есть удобная TortoiseHg.
Здравствуйте, Cyberax, Вы писали:
N>>Какую именно правильную систему ты бы рекомендовал? C>Я пока всем рекомендую Mercurial — он нормально работает на всём, что только можно придумать, и для него есть удобная TortoiseHg.
Я использую Bazaar. Тоже работает хорошо. Вполне быстро. А черепашки, с моей точки зрения, совершенно бессмысленны.
), тестируются, ... Который как-то выпал из моего внимания.
Т.е. мои размышления смахивают на изобретение костыля. Когда существуют одобренные и проверенные годами практики работы.
Сегодня, думаю, будет первый мерж 
