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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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