Розробка стратегії управління версіями для SVN


9

Мимоволі намагаюся створити стратегію контролю версій для своєї компанії; в даний час ми використовуємо SVN, але для цього немає структури - в основному ми маємо лише магістраль і лише беремося до цього. Нещодавно менеджер розробки створив друге сховище, яке виступає нашим "тегом", але його потрібно вручну об'єднати з "магістраллю", оскільки це не частина одного сховища, а повністю окремий. Насправді є лише одна папка під назвою "Dev" (насправді є різні папки "Dev" у різні дати, але просто "Dev" є основною), і під цим знаходиться все інше; всі інші проекти. Він взагалі не організований за проектом, він не має поняття гілок / тегу / стовбура чи нічого. Людина, яка створила його спочатку (давно минула, звичайно), здавалося, взагалі не знають, як налаштувати SVN, і з тих пір ніхто не переймався навчитися правильно робити справи, боячись щось зламати. Ми не використовуємо будь-якого типу CI (або, на жаль, автоматизованого тестування).

По-перше, чи слід це розділити за проектом? Наприклад, у нас є два веб-сайти ASP.NET (не веб-додатки, веб-сайти), веб-служба, папка розгортання для всіх скриптів таблиці та збережених процедур, два клієнта командного рядка для зовнішніх проектів, які викликаються Веб-сайти та спільна папка, яка має загальні бізнес-об’єкти тощо. Якщо кожен з них повинен бути власним проектом із встановленням гілок / тегів / магістралей, чи він повинен бути таким:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

і чи є у всіх гілок і все є копія всієї папки Dev? Такий підхід може бути легше проковтнути, оскільки у нас часто трапляються ситуації, коли нам потрібно внести зміни до спільної бібліотеки коду та принаймні одного (зазвичай обох) веб-сайтів.

По-друге, ми робимо регулярні випуски ("підштовхує" в нашій мові) на наш сервер розробників і сервер "живий". З того, що я прочитав, найкращим способом вирішити це було б те, що вся розробка переходить у магістраль /, гілки є "тимчасовими" і використовуються для додавання нової функції, яка може вплинути на магістраль, а теги - для релізів? Отже, ми щомісяця наполягаємо, скажімо, і я працюю над абсолютно новим модулем. Я би розгалужував магістраль і використовував би цю гілку для свого коду, писав і тестував її та все, що завгодно. Коли модуль буде завершений, я б об'єднав його назад у стовбур (і, можливо, видалить гілку), і коли ми будемо готові до розгортання, ми би позначили його ("May2011" скажімо). Якщо у нас виправлено помилку після того, як вона вийде на екран, вона буде виправлена ​​в тезі May2011 і об'єднана в магістраль (так і магістраль отримує виправлення), і тоді May2011 буде знову витіснений з виправленням? Це намір тегування?


5
Поза стратегія: перейти на git.
Рейн Генріхс

Якби це був варіант, я б це зробив (або Mercurial, оскільки ми - магазин Windows). Я думаю, що я би зіткнувся з ще більшим опором, намагаючись перейти до абсолютно нової системи управління джерелом, ніж намагатися принаймні створити належне середовище, створене за допомогою SVN.
Уейн Моліна

2
Хоча я в захваті від DVCS, Subversion є хорошим інструментом. CVS або інше рішення без версії папок було б гірше.
Матвій Родатус

2
@Wayne M - Ви можете виявити, що насправді навпаки. Люди можуть бути простішими підписатись на більш розумну структуру навколишнього середовища, якщо це дозволить їм отримати всі переваги використання DVCS. Як перехід, ви можете розглянути можливість отримання peopel, щоб спробувати дешевий локальний розгалуження / доступ до репо, використовуючи gitsvn або hgsubversion. Після того, як вони підключені та використані для інструментів, цілком може виникнути бажання перейти до DVCS для первинних репортажів.
Марк Бут

Відповіді:


5

Якщо ви хочете уніфікувати процес збирання, то обов'язково покладіть гілки / теги / стовбур у корінь, як це:

branches/
tags/
trunk/
  dev/
    ...

Якщо вам не потрібен єдиний процес збирання, ви можете розмістити гілки / теги / стовбури в кожному проекті, якщо хочете. Однак може бути важко перейти до єдиної збірки після того, як розмістити їх у кожному проекті. Уніфікована збірка має такі переваги, як усунення необхідності публікувати спільні компоненти між проектами - всі вони є частиною збірки.

Особисто мені подобається єдиний процес збирання. Крім того, я не думаю, що у вас повинен бути проект "dev". Ви повинні мати проекти безпосередньо під магістраллю, а потім розгалужувати магістраль у гілку розробників. Використовуйте теги для випусків. Наприклад, я зробив би це так:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1
Уніфікована збірка має такі переваги, як усунення необхідності публікувати спільні компоненти між проектами - всі вони є частиною збірки.
Матвій Родатус

2
Якщо вам потрібно кілька об'єднаних збірок, тоді створіть каталоги під магістраллю для кожної. Але я б не назвав одного "дев" - це краще досягти з гілкою. Наприклад, у вас можуть бути дві основні організації розробників - одна, яка працює на драйверах пристроїв, і одна, яка працює на веб-сайті компанії. Ви, мабуть, хочете двох окремих об'єднаних конструкцій.
Матвій Родатус

1
  1. Що стосується структури коду в svn, то це дійсно особистий вибір.

Я б запропонував, що якщо проекти пов'язані або код спільного доступу, тоді вони хочуть спільної магістралі. Якщо вони незалежні, вони хочуть окремі стовбури або навіть окремі сховища. Якщо вам коли-небудь потрібно надати третій стороні копію svn історії для проекту, тоді набагато простіше, якщо він знаходиться в окремому сховищі.

Тож у вашому випадку це здається, що макет, який ви накреслили вище, було б розумним, оскільки у вас є спільний код, і ви хочете, щоб гілки / теги включали цей спільний код.

  1. Ваш опис використання тегів та гілок звучить надзвичайно чуйно, і я б очікував, що svn буде використаний. Це дійсно намір маркувати, як я розумію. BTW у svn тегах та гілках - це те саме, але термінологія застосовується так, як ви її застосували.

Особисто я також додав би застереження про те, що все, що робиться для ствола, повинно будуватися, повинно бути атомним і не повинно порушувати жодних одиничних тестів. Філії призначені для незавершеної незавершеної роботи. Я б очікував, що багажник буде потенційним кандидатом на реліз у будь-який момент.


Ви хочете сказати, що лише перевірений, готовий до виробництва код повинен бути в багажнику? Я думаю, що будь-який код, який робиться, повинен будувати і, ймовірно, проходити тести, а магістральний код, звичайно, повинен проходити тести. Але здається, що метою SVN є можливість слідкувати за історією розвитку, а це простіше, якщо він не розділений на кілька гілок. Можливо, має бути гілка, в яку ви зливаєте стовбур, коли стовбур знаходиться в перевіреному стані, готовому до виробництва?
Містер Джефферсон

0

Нижче наведено найкращий спосіб скласти сховище Subversion

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

Таким чином ви можете перевірити окремі проекти самостійно.

Якщо ви хочете перевірити всі 3 проекти та виконати уніфіковану збірку з деяким монолітним сценарієм / системою збірки, тоді досліджуйте за допомогою головного модуля з svn: externals, що відображає всі інші проекти в майстер trunk .

Це на перший погляд складніше, але це найбільш реальний і ідіоматичний спосіб вирішити цю проблему за допомогою Subversion.


2
Я категорично не згоден. Репозиторій робить більше, ніж просто зберігає код; він повідомляє про організаційну структуру та взаємозв'язок між компонентами; це життєво важливий, хоча і неявний, канал зв'язку. Якщо ви розбиваєте кожен проект окремо, ви створюєте штучні та непотрібні бар'єри для спілкування.
Вільям Пейн
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.