Найкраща практика з розгалуженням вихідного коду та життєвого циклу додатків

Ми невеликий магазин ISV, і ми щомісяця постачаємо нову версію своєї продукції. Ми використовуємо Subversion як наш сховище коду, а Visual Studio 2010 як наш IDE. Мені відомо, що багато людей виступають за Меркурій та інші системи управління розподіленими джерелами, але на даний момент я не бачу, як ми могли б отримати з них користь, але я можу помилитися.

Наша основна проблема - як зберігати гілки та основний стовбур синхронізовано.

Ось як ми робимо справи сьогодні:

1. Випустити нову версію (автоматично створити тег у Subversion)
2. Продовжуйте роботу над головним магістраллем, який вийде в наступному місяці

І цикл повторюється щомісяця і працює чудово. Проблема виникає, коли потрібно випустити терміновий сервіс. Ми не можемо звільнити його з основного магістралі (2), оскільки він перебуває у важкому стані, і він недостатньо стійкий, щоб його терміново відпустити.

У такому випадку ми робимо наступне:

1. Створіть гілку з тегу, який ми створили на кроці (1)
2. Виправлення помилок
3. Тестуйте та відпустіть
4. Поверніть зміну назад до основного магістралі (якщо застосовується)

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

• в основний магістраль було внесено багато змін
• об'єднання складних файлів (наприклад, файлів XML Visual Studio тощо) працює не дуже добре
• інший розробник / команда внесла зміни, які ви не розумієте, і ви не можете просто об'єднати їх

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

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

Основне, що потрібно переконатись, - це те, що база коду має чітке розділення проблем . Залежності між різними компонентами потрібно ізолювати та зменшувати. Це має вирішити більшість ваших проблем. Також допоможе дотримання таких практик, як принцип єдиної відповідальності.

Якщо потрібна велика архітектурна зміна, вона має відбутися у власній галузі, а потім об'єднатись у головну, колись повністю перевірена та «стабільна» (в межах розуму). Це може бути болючим і складним, але воно також має бути рідкісним. Якщо у вас є хороші методи тестування, ризик зводиться до мінімуму.

Це також може допомогти перейти на розподілену систему контролю версій. Це повинно дати вам стійкий стовбур із різними ознаками, об'єднаними в різні гілки, коли вони будуть готові. У вас все ще буде зливатися біль, якщо код занадто взаємозалежний, але ви будете мати більше контролю.

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

Я схильний дивитись на це майже навпаки:

• Магістраль завжди має бути готовим до виробництва кодом (після першого первинного випуску, тобто).
• Повинна бути гілка типу розвитку, яка паралельно стовбуру, де відбувається ваша щомісячна розробка. Щомісяця, коли настає час випуску, він об'єднується в багажник, перевіряється, а потім випускається.
• Виправлення можна легко зробити у вашому багажнику та зареєструватися та завжди успішно розгорнутись. Потім зробіть виправлення з виправлення та застосуйте його до своєї галузі розробки.

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

Останнім часом я виступаю за філософію "гілки та злиття" як останнього результату. Я думаю, що прикрою правдою є те, що робота з кодом зливається з гілок - це не технічна проблема, але це пізнавально складне завдання: я думаю, що людський мозок просто не відслідковує достатньо деталей, щоб зробити його легким. Більше того, я ще не бачив розгалуження та об'єднання насправді працюють на практиці. Після того, як код буде розгалуженим, досвід підказує мені, що злити його знову непросто.

Дисциплінований підхід до головної роботи працює добре.

Розгалуження SVN не розроблене так, щоб бути гнучким. Я б сказав, що ваша перша проблема полягає у SVN; перехід від цього відкриє нові варіанти.