Лучшие практики, построение ствола против ствола?

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

Когда мы выполняем сборку релиза, у нас есть скрипт, который просматривает файлы проекта и заменяет ссылки на транки для конкретных пронумерованных версий компонентов (которые построены из теговой ветви).

Я думаю, что это ослабляет тестирование, которое мы проводим во время разработки, потому что проект, над которым я на самом деле работаю, использует разные dll для того, что будет использовать сборка релиза. Я хотел бы всегда разрабатывать против пронумерованных версий компонентов и обновлять их только тогда, когда есть особая необходимость.

Однако другие члены команды утверждают, что если мы не будем разрабатывать с использованием магистрали (и не будем обновлять более новые версии компонентов с каждым выпуском), у нас будет проблема, заключающаяся в том, что (а) наши продукты вряд ли когда-либо обновятся до более новой версии компонентов ( б) когда нам нужно обновить, это будет огромной задачей, потому что компонент / источник интерфейса сильно изменился.

Какими практиками вы следуете и почему?

Изменить: Извините все, я только что понял, что запутал вещи, упомянув, что есть несколько основных продуктов, разделяющих компоненты - хотя они разделяют компоненты, которые они не работают на тех же ПК Мое беспокойство связано с тем фактом, что, поскольку компоненты, вероятно, будут меняться с каждым выпуском продукта (даже при том, что не было особого требования к обновлению компонента), тестирование пропустит некоторые тонкие изменения, которые были сделаны в компоненте и не связаны с конкретная работа, выполняемая над продуктом.

15.12.2008 15:16:40
6 ОТВЕТОВ
РЕШЕНИЕ

Хм, я могу быть в меньшинстве здесь, но это сводится к управлению выпуском.

Разработка на trunkоснове набора общих компонентов означает, по определению, что компоненты являются «движущейся целью» - разработчик, использующий эти общие компоненты, не обязательно будет знать, является ли обнаруженный дефект или сбой следствием кода проекта или общие компоненты, которые приводят к потере производительности, ИМНШО.

«Совместно используемые компоненты» имеют собственный цикл выпуска. Предоставьте другим разработчикам перерыв и исправьте версию общих компонентов, которые будут использовать и использовать проекты tags, labelsили branchesопределить выпуск общего компонента. На следующей итерации проектов перейдите к последней «стабильной» или «производственной» сборке общих компонентов.

Здесь есть еще один «запах», если вы извините за выражение. Наличие «общих компонентов», чьи «источники / интерфейсы будут так сильно изменяться» между выпусками проекта, звучит так, как будто компоненты не настолько прочны или не обязательно должны использоваться совместно.

См. Также ответ на этот вопрос. Общие компоненты во всех проектах. Есть ли лучшая альтернатива, чем svn: externals?

10
23.05.2017 11:55:45
Это именно то, что я пытался сказать, но сделано с гораздо большей ясностью и красноречием, браво!
Instantsoup 15.12.2008 17:36:57
В качестве дополнения к вашему ответу. Рассмотрим ситуацию, когда важная функциональность, которая нужна вашему транку, находится только «в разработке» в совместно используемом компоненте. В этом случае вы можете обратиться к ежедневным, четко определенным снимкам общего компонента.
Stefano Borini 17.08.2009 20:34:24

У вас должны быть сильные интерфейсы, которые редко меняются, поэтому смена версий не должна быть такой сложной.

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

3
15.12.2008 15:28:18
Правда, интерфейсы могут не сильно измениться. Меня больше беспокоит незначительные изменения в поведении компонентов, которые не подобраны, потому что тестирование сфокусировано на изменениях,
hamishmcn 15.12.2008 15:40:35

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

По сути, если разработчик работает над транком, все, что ему нужно, - это беспокоиться о сборке из транка и фиксации кода в транке.

Любой разработчик, работающий над веткой, должен собрать и протестировать эту ветку (есть несколько проектов, все разветвленные / помеченные одной и той же сборкой / выпуском). Когда они фиксируют изменения в этой ветви, они также должны объединить эти индивидуальные изменения в транк.

Мы ожидаем, что все разработчики будут знакомы с SCM (SVN) и будут способны поддерживать несколько ветвей кода. Как команда, мы обрабатываем серьезные изменения в фреймворке или огромные изменения кода, чтобы минимизировать трудоемкое слияние

2
15.12.2008 15:28:26
Разве практика немедленного слияния какого-либо коммита с веткой в ​​транк не разрушает всей цели ветки?
Simon Lehmann 15.12.2008 15:42:46
Не для нас. Магистраль предназначена для исследований / разработок, направленных на новые крупные функции или технологии. Ствол летучий, ветви стабильные. Библиотеки, используемые в ветвях, статичны, как только мы их разрезаем, но мы можем радикально изменить то, как мы работаем в транке.
Instantsoup 15.12.2008 15:47:18

Две вещи здесь. Во-первых, я думаю, что вы правы; Вы хотите строить против самых последних версий разработки, а не против старых версий. Если вы еще не сделали, вы будете видеть ситуацию , в которой накопление в наличии для выпуска взрывает , и вы должны сделать всю ночь уборки до и переформатирования.

Лично я в любом случае являюсь поклонником модели "сделай коммит, освободи от ветки". Все коммиты идут в ствол, ночные сборки или сборки CI против ствола, и люди свободно создают ветки. Если у вас есть транк, который соответствует критериям приемлемости, пометьте кандидата на выпуск, НО ПРОДОЛЖАЙТЕ СДЕЛАТЬ ОБНОВЛЕНИЯ ДЛЯ СТАНКА. Если у вас длинный цикл выпуска, то у вас могут быть изменения для выпуска n + 1, добавляемого в ствол, но в идеале вы должны просто сократить цикл выпуска. Если есть изменения в ствол , которые не должно быть в выпущенной версии, и у вас есть проблема , которая требует изменений, создать филиал против меченой версии --- и убедитесь , что вы сливаете изменения обратно к стволу , как только вы актуальный релиз.

2
15.12.2008 15:31:21

Мы используем систему сборки scons, и у нас есть собственный файл в корневом каталоге, который указывает, какую версию каждой библиотеки мы будем использовать при сборке приложения.

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

1
15.12.2008 15:32:57

Вопрос о том, является ли (b) действительным аргументом, зависит от того, как часто и совместно используются ваши общие компоненты. Если они часто меняются на вашем рабочем месте, возможно, вы «вынуждены» разрабатывать новейшую версию. Является ли это само по себе проблемой - актуальный вопрос.

Однако, с вашей стороны, я не понимаю, как вы можете внедрить код в производство без его тестирования на общие компоненты, используемые в производстве. Вы делаете второй тестовый цикл против релизной сборки? Вы просто молитесь, чтобы ничего не сломалось? Честно говоря, в следующих случаях (b) можно изменить на противоположную, чтобы поддержать вашу точку зрения: если ствол достаточно отличается от самой последней ветви с тегами, то необходимо приложить усилия, чтобы обеспечить правильную работу вашего приложения с ним.

Если ваши общие компоненты помечены достаточно часто, то ваши коллеги, вероятно, правы, и легче управлять постепенными изменениями от самого последнего тега к стволу, чем управлять изменением от произвольной версии X (определенной в последней сборке) до произвольной версии Y (определяется при выборе обновления).

1
15.12.2008 15:37:34