Comments 30
не очень понятно зачем вообще тогда был merge? Вы в Staging и в Stable вообще комитили что нибудь в такой схеме? Были ли хот-фиксы и если да то куда они шли?
Стейджинг был для того чтобы не делать code freeze, скажем в пятницу, когда мы выкатил итерацию на тот момент пока QA ее тестирует. А в это время мы могли на Trunk ветке продолжать работу. И баги, найденные тестерами фиксились хот-фиксом на staging.
а теперь вы их фиксите в trunk и делаете повторный copy?
Ну, как правило, после фикса багов (обычно это квик-фиксы) больших сложностей с svn merge на staging не возникало… Поэтому повторный copy не делали.
Вообще мы начали подобную практику только с этой итерации, поэтому, если честно. хотелось бы побольше услышать за и против, а не просто минусов или, не дай бог, плюсов :-)
Вообще мы начали подобную практику только с этой итерации, поэтому, если честно. хотелось бы побольше услышать за и против, а не просто минусов или, не дай бог, плюсов :-)
мои комментарии это просто уточнение было) Мне кажется, вы излишне концентрируте внимание на моменте копирования из одной ветки в другую. Если нет конфиликтов из-за разного форматирования, то я не вижу особой разницы — делать ли merge либо copy. В итоге там в target ветке будет нужный mergeinfo стоять в обоих случаях. Единственный плюс за copy, который я вижу — нет надобности делать review того что получилось, а можно сразу отдавать тестерам.
а почему бы не делать сборки при помощи ant, make, rake, phing, etc. Установить continuous integration server (например xinc) и отслеживать все ваши сборки во времени, тогда будет точно известно, сборка №ххх — тестируется, сборка №ууу — продашн. Тогда в svn хоть все в одной ветке держите, задача выкладывания на сервер будет решаться более не система контроля версий
*будет решаться не системой контроля версий
Я думал о внедрении phing-а, немного читал, немного видел. Но на практике не применял. Много работы и особо нет времени попробовать разные средства. Вы у себя на проекте(ах) пользуетесь подобными инструментами?
да, использую phing + xinc, в целом — удобно, всегда можно откатиться до любого релиза.
В одном проекте использую rake как систему сборки.
В одном проекте использую rake как систему сборки.
Но на самом деле до прошлой «сборки» (состояния перед текущим релизом), я тоже могу легко вернуться. Ветка-то старая (бывшая стейблом) никуда не девается. Обратным извенением конфигов веб сервера.
Да и к более старым можно.
Но как часто в веб проекте нужно вернуться к состоянию на 5 релизов назад? Думаю практически никогда.
Да и к более старым можно.
Но как часто в веб проекте нужно вернуться к состоянию на 5 релизов назад? Думаю практически никогда.
я не спорю с Вами о возможности откатится, просто система контроля версий не совсем предназначена для этого,
конечно и у предложенного мной подхода, есть недостатки, есть необходимость писать правила для сборки, конфиги для continuous integration сервера — не очень интересная задача, но последующее использование вносит больше порядка, чем просто уповать на svn,
еще, например, при сборке у меня проходят тесты, и если тесты не прошли, пакет не создается, периодически генерируется документация, в Вашем случае это рутина, которую нужно делать руками
конечно и у предложенного мной подхода, есть недостатки, есть необходимость писать правила для сборки, конфиги для continuous integration сервера — не очень интересная задача, но последующее использование вносит больше порядка, чем просто уповать на svn,
еще, например, при сборке у меня проходят тесты, и если тесты не прошли, пакет не создается, периодически генерируется документация, в Вашем случае это рутина, которую нужно делать руками
После вашего описания и чтения манула по xinc-у, очень захотел попробовать его в деле. Спасибо за совет. И естественно плюс в карму.
на самом деле, мое глубокое ИМХО, что Continuous integration server
не имеет смысла внедрять, если проект изначально не был писан с применением TDD, и тестами должна быть покрыта core functionality полностью. Ну и соответственно, под каждый dayly build должны быть тоже прописаны тесты. Иначе смысла в этом мало.
Просто приятно, что и на php появляются взрослые решения, которые как и все в пхп приходит из Java :-(
Вы, я так понимаю, используете TDD у себя на проектах?
не имеет смысла внедрять, если проект изначально не был писан с применением TDD, и тестами должна быть покрыта core functionality полностью. Ну и соответственно, под каждый dayly build должны быть тоже прописаны тесты. Иначе смысла в этом мало.
Просто приятно, что и на php появляются взрослые решения, которые как и все в пхп приходит из Java :-(
Вы, я так понимаю, используете TDD у себя на проектах?
Иногда надо. Есть очень-очень подлые программисты, которым незадачливые админы дали права на коммит. Мысль понятна ;-)
На самом деле меня даже больше интересовали мнения по поводу мерджа в Git
Например, из слов Линуса Торвальдса: «Я знаю несколько компаний, которые внутри используют git, не подозревая об этом, потому что они все еще держат свои главные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо выполняет слияния. Так что вы можете взять дерево веток из Subversion, импортировать в git, позволить git сделать слияние, что было бы основной головной болью в Subversion, зафиксировать изменения и фактически экспортировать их назад в Subversion, и никто другой даже не узнает, что вы использовали git. Немного грустно, но я слышал о многих, работающих в компаниях в точности по этому сценарию.....»
lib.custis.ru/index.php/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks
Например, из слов Линуса Торвальдса: «Я знаю несколько компаний, которые внутри используют git, не подозревая об этом, потому что они все еще держат свои главные репозитории в Subversion, но многие разработчики затем импортируют код в git, потому что git действительно хорошо выполняет слияния. Так что вы можете взять дерево веток из Subversion, импортировать в git, позволить git сделать слияние, что было бы основной головной болью в Subversion, зафиксировать изменения и фактически экспортировать их назад в Subversion, и никто другой даже не узнает, что вы использовали git. Немного грустно, но я слышал о многих, работающих в компаниях в точности по этому сценарию.....»
lib.custis.ru/index.php/%D0%9B%D0%B8%D0%BD%D1%83%D1%81_%D0%A2%D0%BE%D1%80%D0%B2%D0%B0%D0%BB%D1%8C%D0%B4%D1%81_%D0%BE_GIT_%D0%BD%D0%B0_Google_Talks
По поводу вашего первого абзаца — не согласен.
Используем мы их вполне логично. Одна — для чего бы покодить, вторая — чтобы не делать коде фриз во время тестирования, и собственно — продакшн.
По поводу Сapistrano, мы думали, делать нечто похожее руками.
Но у нас достаточно сложная система. Каждый коммит по пост-коммит хуку разливает изменения с помощью рсинка на удаленные веб сервера.
Поэтому мне так показалось проще…
Используем мы их вполне логично. Одна — для чего бы покодить, вторая — чтобы не делать коде фриз во время тестирования, и собственно — продакшн.
По поводу Сapistrano, мы думали, делать нечто похожее руками.
Но у нас достаточно сложная система. Каждый коммит по пост-коммит хуку разливает изменения с помощью рсинка на удаленные веб сервера.
Поэтому мне так показалось проще…
эм… вы не умеете их готовить… почитайте, что ли про trunk+branches+tags…
И..? что я именно должен прочесть?
например, что не стоит заводить одну ветку «продакшен», а стоит много «тэгов» и переключаться между ними при выкладке.
Хм… ну trunk+branches+tags — всего лишь предлагаемая структура и стала стандартом де-факто, но Subversion её не навязывает и позволяет сделать любую структуру, какую надо разработчикам
По моему у вас не совсем типичное использование сув :) Ну и если вдруг что, стремительно откатиться на конкретный билд не получится.
Лучше все таки разделить разработку и деплоймент. Текущее в trunk, каждый билд — в соотв tag. А развертывание уже отдельно.
К примеру, довольно удобно собирать найтли билды из транка и развертывать их на dev, а на QA/продакшн — из последнего тэга.
Лучше все таки разделить разработку и деплоймент. Текущее в trunk, каждый билд — в соотв tag. А развертывание уже отдельно.
К примеру, довольно удобно собирать найтли билды из транка и развертывать их на dev, а на QA/продакшн — из последнего тэга.
Получится стремительно откатится на прошлый, так скажем Билд. Т.к. после смены веток, стейбд перестал быть продакшеном. Но он сохраняется как ветка. Если нужно будет резко вернуться на прошлый билд. То я снова помяняю настройки веб сервера и оченб быстро откачусь на состояние до прошлой итерации. С эти проблем нет.
На конкретный, т.е. 5 итераций назад — при жедании тоже можно будет откатиться. Ведь это СВН :-)
Но честно-говоря не представляю зачем это может нам понадобиться.
>Лучше все таки разделить разработку и деплоймент. Текущее в trunk, каждый билд — в соотв tag.
Так собственно об этом я и написал статью. Как мы это разделили. Мы и не смешиваем разработку и деплоймент.
>каждый билд — в соотв tag
то, что у нас есть
На конкретный, т.е. 5 итераций назад — при жедании тоже можно будет откатиться. Ведь это СВН :-)
Но честно-говоря не представляю зачем это может нам понадобиться.
>Лучше все таки разделить разработку и деплоймент. Текущее в trunk, каждый билд — в соотв tag.
Так собственно об этом я и написал статью. Как мы это разделили. Мы и не смешиваем разработку и деплоймент.
>каждый билд — в соотв tag
то, что у нас есть
Sign up to leave a comment.
История о том как SVN copy победил SVN merge