У Стенфорді працює екземпляр бази коду OpenEdX, яку активно розробляє команда інженерів. Ми підтримуємо власну вилку в github.com/Stanford-Online/edx-platform і ми намагаємося підтримувати наш форк близько до edX master, щомісяця зливаючись із головного репозиторію edx-платформи edX (github.com/edx/edx-platform). Ми надаємо перевагу надсиланню коду через запити на витягування (PR) до головного репозиторію edX, але інколи це неможливо, оскільки ми періодично створюємо спеціальні функції для Стенфордського університету. Через ітерацію ми запровадили чітко визначений процес випуску, який включає робочі процеси як для об’єднання з основного репозиторію edX, так і для збереження нашого власного окремого майстер відділення. Оскільки ми працюємо на веб-сайті з великою кількістю користувачів, ми вважаємо, що стабільність випусків має першорядне значення. Це означає, що ми дуже стараємось уникати поганого коду звільнити гілка, і процес випуску полегшує це.
Оскільки ми надсилаємо PR як edX, так і собі, нам потрібен доступ до репозиторіїв edX із наших середовищ розробки, тому більшість розробників у Стенфорді запускають середовища git із принаймні двома пультами дистанційного керування (або інколи більше з персональними пультами дистанційного керування та колеги): походження, Стенфордське сховище кодів; і вгору за течією, репозиторій коду edX, з якого ми можемо перевірити головну гілку, щоб зробити PR для edX. Ми також використовуємо це вгору за течією віддалений, щоб об’єднати зміни коду з edX під час нашого процесу випуску.
Ось тут я побачив потребу в схемі, яка пояснює процес випуску. Я візуальна людина, і я розумію речі, щоб щось намалювати. Ось моя діаграма, яка допоможе описати наш робочий процес розробки та випуску:
Це особливо корисно, оскільки наші розробники по черзі несуть відповідальність за випуски в нашій змінній системі «Release Master». Діаграма забезпечує узгодженість циклу випусків між випусками та мінімізує помилки.
Ось план випуску з використанням діаграми як керівництва:
1. Спочатку ми створюємо rc відгалуження від нашої головної гілки, взявши будь-яку розробку, яка була об’єднана майстер з моменту останнього випуску.
1а. Якщо ми хочемо об’єднати вгору за течією звільнити відділення в rc відділення, ми робимо це тут.
На даний момент у нас є кандидат на випуск, який ми можемо протестувати, і, як тільки ми будемо впевнені, що він нічого не зламає, тоді встановити на наші виробничі машини.
2. Тепер об'єднуємо гілку rc у відділення звільнити (це має бути проста швидка перемотка вперед; якщо ні, у попередньому випуску була проблема!).
3. Тепер звільнити гілка (та об’єднана вгору за течією код) можна об’єднати назад у майстер гілки, щоб синхронізувати обидві гілки одна з одною.
Зауважте, що гілки функцій створюються з майстер і знову об’єднано, щоб випустити в регулярний цикл випуску. Виправлення, з іншого боку, розгалужуються звільнити, знову об’єднано в звільнити, негайно передано у виробництво, а потім знову об’єднано з майстер підтримувати синхронність. Також зауважте, що звільнити зміни і вгору за течією злиття не входять майстер якщо вони не вважаються безпечними після тестування, яке ізолює майстер від жуків також.
І це все! Ми використовуємо цю модель розгалуження для кожного розгалуженого репозиторію, який ми підтримуємо, що зберігає все послідовним і передбачуваним.
