Ми починаємо стикатися з проблемою, коли ми збільшуємось, коли функції перетворюють її на поетапне тестування, але до того моменту, коли все перевірено та затверджено, нові функції вже ставлять на тест.

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

Деякі особливості:

• GIT на BitBucket
• Дженкінс для сценарію розгортання в Azure

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

Здається, у вас тут є кілька проблем:

1. Визначення особливостей конкретного випуску

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

2. Стратегії розгалуження

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

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

Довговічні гілки функцій або гілки з одночасним випуском, мабуть, найкраща відповідь на подібні проблеми. Об’єднайте (або перезавантажте, якщо вам це зручно) останній від майстра у свої довго працюючі гілки. Будьте обережні, щоб об’єднати лише ті функції, які вже є активними, інакше ви зіткнетеся з проблемами, які у вас виникли зараз (занадто багато змішаних функцій на одній гілці).

Гілки "виправлення" або "виправлення" є невід'ємною частиною цього процесу; використовувати їх для невеликих одноразових виправлень, які мають короткий цикл QA.

З вашого опису, може бути навіть краще не підтримувати офіційну галузь «розвитку». Швидше, гілка всіх функцій від головного, і створити об'єднані гілки випуску, коли випуск буде визначений.

3. Середовища

Не порівнюйте гілки git з вашим середовищем, за винятком виробництва == master. Галузь «розвитку» слід вважати розбитим. Гілки випуску висуваються до тестових середовищ, чи це середовище якості якості, чи середовище постановки. Якщо вам потрібно, висуньте певну галузь функції до середовища.

Якщо у вас є більше однієї гілки функцій, яку потрібно випустити окремо, але тестувати одночасно ..... ¯ \ _ (ツ) _ / ¯ .... спініруйте інший сервер? Можливо, об’єднайте їх разом у гілку, що викидає ... вчинити виправлення / зміни вихідних гілок та знову об'єднатись у гілку, що викидає; остаточне затвердження та UAT на окремих відділеннях випуску.

4. Видалення не затверджених функцій із гілки

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

У будь-якому випадку, якщо ви готуєтесь до випуску та не підтвердили зміни, вам потрібно буде використовувати Git, щоб відмовитись від неприйнятих комісій із гілки випуску; найкраща ідея - це зробити перед тестуванням випуску.

Удачі.

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

Це має бути простим питанням координації між тестом та виробництвом. Якщо ви використовуєте гілки функцій у Git, просто перестаньте натискати завершені гілки функцій на тестування під час циклу тестування та відновіть, коли тестування завершено.

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

Робочі палі

Це універсальна проблема в моєму досвіді. Я адресую це:

• Сильне управління випуском функцій власником продукту
• Переконайтесь, що гілки видаляються під час їх об’єднання
• Обмежити незавершену роботу (з обмеженнями стовпців у Джирі)
• Щоквартальний огляд старих квитків, які знемагають, як помилки, так і функції
• Ретроспектива для обговорення компонентів питання
• Постійне заохочення до перегляду коду усіма
• Можливості створення пари для вирішення давніх квитків та проблем
• Щоквартальні зустрічі для перегляду та прибирання старих квитків
• Командний підхід, щоб заставити розробників, продуктів та QA / QE тісно працювати разом
• Хороша звітність та інструменти, щоб зробити нові функції продукту та відставання очевидними
• Перегляньте сеанси, щоб пройти старі гілки та видалити їх

Гілки

Для управління цим процесом вам потрібні кілька гілок:

• особливість : ці гілки народжуються від господаря. Використовуйте деякий додаток для управління проектами, щоб визначити кожну галузь функції з деяким завданням. Наприклад, якщо ви використовуєте TRAC, ви закінчитесь, якщо гілки типу:, 1234-user-crudі 1235-bug-delete-catalogт. Д. Ідентифікуйте свої зобов’язання і з номером завдання, це дуже допоможе вам, коли у вас виникнуть проблеми в злитті (ви будете).
• тест : усі гілки функцій, які виконані, будуть об'єднані в тестову гілку. Ви ніколи не об'єднуєте тестову гілку в якусь гілку функцій , тому що не хочете код з інших функцій, яких немає у виробництві (майстер). Те саме стосується releaseфілії.
• реліз : коли ви вирішуєте, які тестові функції можуть бути у виробництві, ви об'єднуєте ці гілки (знову ж таки ...) у цю галузь. Вам потрібно перевірити всі функції заново, оскільки це злиття може принести нові проблеми. Коли випуск буде протестовано і виконано, ви з’єднаєте цю гілку для створення та створення тегу на master для версії.
• головний : містять тільки виробничий код.

Дивіться потік git:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Середовища

Дуже просто:

• тест : у цьому середовищі використовують тестову гілку.
• реліз : це середовище використовує фактичну гілку випуску.

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

Проблеми

Найбільша проблема в цьому процесі - злиття.

Вам потрібно переробити однакові злиття в testі release. Це буде болісно, ​​якщо в коді будуть внесені якісь хороші рефактори, як-от видалення класу, способи переміщення / перейменування тощо. Оскільки ви не можете отримати код з test(або release) гілки в галузь функції, об'єднання об'єднань можна вирішити лише в test(або release). Отже, ви в кінцевому підсумку вирішите ті самі конфлікти у двох різних галузях, ймовірно, виробляючи різний код у кожному злитті, і в майбутньому ви виявите, що тестовій групі потрібно буде перевірити функції двічі: в testі releaseгілках, оскільки кожне злиття може призвести до різних помилок.

Ще одна проблема - testгалузь. Вам потрібно буде masterчас від часу "переробляти" цю гілку (видаляти та створювати нову ), оскільки деякі старі гілки (або старі злиття, об'єднані гілки, які були видалені) можуть принести багато проблем для нового коду, багато в чому розходяться від того, що є master. У цей момент вам потрібно контролювати, які гілки ви хочете знову об'єднати в test.

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

Здається, що ви об'єднуєте зміни з вашої галузі інтеграції у вашу галузь виробництва, що IMHO не є хорошою практикою саме з причин, про які ви згадуєте. Щойно галузь виробництва для певного випуску витягується з основної галузі інтеграції, галузь інтеграції може в будь-який момент розходитися (адже вона повинна перерости в наступну версію). Об'єднання гілки інтеграції в поточну гілку випуску може внести зміни, несумісні з цим випуском.

ІМХО належним процесом буде:

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

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

• Я не впевнений, чи є у вас окремі групи Dev та QA. Якщо ви це зробите, переконайтесь, що і Dev, і QA сідають на спринтерські зустрічі з планування та оцінки. В одній з моїх попередніх компаній ми переконалися, що кількість точок історії, яким ми присвоїли історію, припадає як на розробку, так і на тестування. (Теоретично ви також можете мати дві окремі оцінки для розробок та забезпечення якості, але будь-який спосіб вам повинен включати обидва; час, необхідний для розповіді, - це час, необхідний для її реальної доставки). Навіть якщо у вас немає окремої групи якості, все ж переконайтеся, що ви включили тестування у свої оцінки.
• Наслідуючи вищезгадане вище, домовляйтесь заздалегідь про те, скільки історій ви збираєтеся включити у конкретний спринт. Кількість точок сюжету, які ви приймаєте, залежить від суми, яку ваші розробники можуть закінчити у своєму спринті та кількості предметів, які QA може перевірити у своєму спринті. (Я, звичайно, припускаю, що спринти QA відстають від спринтів Dev, але ви можете адаптувати це до свого процесу). Якщо ваші розробники можуть закінчити 200 точок історії, але ваш QA може закінчити лише 150 точок історії, очевидно, ви можете зробити лише 150 очок історії, перш ніж робота почне "накопичуватися", і ви закінчитеся з таким випадком, як описаний вами опис. (У такому випадку ви, можливо, захочете розслідувати причину блокування дороги, щоб спробувати пом'якшити її).
• Ніхто нічого не підштовхує до QA, поки все, що зараз знаходиться в QA, не буде перевірено та поставлено .
• Повна особливість - це те, що було протестовано та поставлено. Якщо його не доставлять, це не буде зроблено.
• Очевидно, ви хочете спробувати це зробити в якомусь фіксованому графіку. Однією з цілих ідей постійної інтеграції та Agile є ітерація. За визначенням, ітерація тягне за собою часті пологи. Часті інтеграції та доставки мінімізують ризик кожного з них.

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

Підсумовуючи: доставляйте до QA лише тоді, коли ви закінчите тестування та надання старих функцій.

Коли "все перевірено та затверджено", розгорніть те, що було випробувано та затверджено до виробництва. Це може бути певна фіксація, або це може бути особливий артефакт побудови, створений Дженкінсом.

Не має значення, що пізніші зобов'язання в тій самій гілці ще не перевірені.