У веб-проекті, що постійно розробляється (не продукт), в даний час ми маємо таку стратегію розгалуження, грунтуючись на потоці git :
- розробити галузь: остання робоча версія
- головна гілка: версія для випуску / версія
- особливості галузей: особливості розвитку
- гілки виправлення: термінові виправлення у випущеній версії
Майстер читається тільки, оновлюється за допомогою запитів на витяг з гілок розробки або виправлення . Кожне оновлення призводить до того, що кандидат на випуск будується та розгортається до системи постановки. Кандидати на випуск передаються у виробництво після затвердження вручну.
Гілки функцій створюються на основі нерозвинених або з останнього комітету, об'єднаного в головний. Побудований запит із розгалуженої функції, який розробляється, розгортається до безкоштовної тестової системи, де виконуються інтеграційні тести та тести прийняття (автоматичні та інструкції). Після успішного тестування та перегляду, PR об'єднується, так що він стане частиною наступного випуску (тобто злиття від розробки до головного).
Моя мета
Я хотів би спростити це та позбутися галузі розвитку. Гілка, що розвивається, має здебільшого історичні причини, і оскільки це завжди успішно перевірена версія, я вважаю, що зайвим залишати її відокремленою від головного. Видалення його також спростить процес випуску, оскільки додаткового злиття більше немає.
У мене є такі обмеження:
- випуски заплановані і не повинні бути повністю автоматизованими
- хоча гілки функцій, як правило, недовговічні, деякі залишаються незруйнованими протягом декількох тижнів (наприклад, перепроектування), але їх також потрібно протестувати (наразі як відкриті запити на виведення)
- іноді одна функція повинна бути випущена поза звичайним випуском, фактично перетворюючи її на виправлення. За допомогою поточної стратегії я можу відновити гілку функції та об'єднати її безпосередньо в головну
- трапляється також, що нам потрібно стримувати функції після того, як тести прийняття із зовнішніми системами на етапі постановки не вдалися
Де я не впевнений у переході:
- На даний момент я будую запити на тестування та об'єдную комісії для випусків. Чи можу я це об'єднати?
- як поводитися з виправленнями, коли майстер випереджає останню версію. Чи слід створювати та розгортати випуски безпосередньо з гілок виправлення?
- чи є розумний спосіб поводжуватися з функціями, які слід виключити з випуску після їх об'єднання? Чи справді окрема галузь розвитку є перевагою для цих випадків? Більшу частину часу я закінчую поверненням та ревертуванням в будь-якому разі.
