Мимоволі намагаюся створити стратегію контролю версій для своєї компанії; в даний час ми використовуємо SVN, але для цього немає структури - в основному ми маємо лише магістраль і лише беремося до цього. Нещодавно менеджер розробки створив друге сховище, яке виступає нашим "тегом", але його потрібно вручну об'єднати з "магістраллю", оскільки це не частина одного сховища, а повністю окремий. Насправді є лише одна папка під назвою "Dev" (насправді є різні папки "Dev" у різні дати, але просто "Dev" є основною), і під цим знаходиться все інше; всі інші проекти. Він взагалі не організований за проектом, він не має поняття гілок / тегу / стовбура чи нічого. Людина, яка створила його спочатку (давно минула, звичайно), здавалося, взагалі не знають, як налаштувати SVN, і з тих пір ніхто не переймався навчитися правильно робити справи, боячись щось зламати. Ми не використовуємо будь-якого типу CI (або, на жаль, автоматизованого тестування).
По-перше, чи слід це розділити за проектом? Наприклад, у нас є два веб-сайти ASP.NET (не веб-додатки, веб-сайти), веб-служба, папка розгортання для всіх скриптів таблиці та збережених процедур, два клієнта командного рядка для зовнішніх проектів, які викликаються Веб-сайти та спільна папка, яка має загальні бізнес-об’єкти тощо. Якщо кожен з них повинен бути власним проектом із встановленням гілок / тегів / магістралей, чи він повинен бути таким:
dev/
branches/
tags/
trunk/
Site1/
Site2/
WebService/
SharedCode/
і чи є у всіх гілок і все є копія всієї папки Dev? Такий підхід може бути легше проковтнути, оскільки у нас часто трапляються ситуації, коли нам потрібно внести зміни до спільної бібліотеки коду та принаймні одного (зазвичай обох) веб-сайтів.
По-друге, ми робимо регулярні випуски ("підштовхує" в нашій мові) на наш сервер розробників і сервер "живий". З того, що я прочитав, найкращим способом вирішити це було б те, що вся розробка переходить у магістраль /, гілки є "тимчасовими" і використовуються для додавання нової функції, яка може вплинути на магістраль, а теги - для релізів? Отже, ми щомісяця наполягаємо, скажімо, і я працюю над абсолютно новим модулем. Я би розгалужував магістраль і використовував би цю гілку для свого коду, писав і тестував її та все, що завгодно. Коли модуль буде завершений, я б об'єднав його назад у стовбур (і, можливо, видалить гілку), і коли ми будемо готові до розгортання, ми би позначили його ("May2011" скажімо). Якщо у нас виправлено помилку після того, як вона вийде на екран, вона буде виправлена в тезі May2011 і об'єднана в магістраль (так і магістраль отримує виправлення), і тоді May2011 буде знову витіснений з виправленням? Це намір тегування?