Що відбувається, якщо функція, об'єднана в розробку, відкладається управлінням?

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

Проблема полягає в тому, що ця функціональність була об'єднана в розробку, коли вона була закінчена разом з усіма іншими функціями, на які ми очікували натиснути в прямому ефірі на наступному випуску, щоб ми не могли просто злити dev -> test -> master, як ми зазвичай робимо.

Як ми могли уникнути цього питання?

Одним із підходів є функція позначення його. Він може жити в кодовій базі, але бути відключеним за конфігурацією.

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

Як ми могли уникнути цього питання?

З точки зору процесу, з’ясуйте:

• Хто був прийнятим рішенням розпочати цю роботу?
• Чому рішення про випуск цієї функції змінилося?
  • Пропущені очікування?
  • Неправильне спілкування?
  • Неадекватна підтримка бізнесу?
  • Немає участі клієнтів?

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

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

Я думаю, ви б оголосили "відключення автоматичної реєстрації за допомогою конфігурації" просто як додаткову функцію (це просто форма Feature Toggle ), тому це повинно плавно інтегруватися у ваш робочий процес. Ви можете оцінити зусилля, якщо вам подобається, ви можете використовувати для нього гілку функцій (чи ні, якщо ви не використовуєте гілки функцій для таких питань). І ви однозначно можете використати описаний вами потік "merge dev -> test -> master".

І це насправді так, як ви впораєтеся з цим у вашій ситуації. З точки зору робочого процесу git, не повинно мати значення, чи запит на зміну надходить від управління для випуску 1.0, чи запит на зміну є новим бажанням клієнта до випуску 2.0.

Це саме те, що у мене є з gitflow та GitHub потоком, і, здається, що з веб-додатками це трапляється часто - або більше схоже на норму. Здається, ви вирішите це питання заднім числом (згадане вище) або проактивно (приклад нижче).

Я створив «гілки зв’язку» на додаток до стандартних гілок gitflow. Комплект складається з усіх функцій, готових до uat / qa. Створюється список функцій uat / qa. Вони об'єднуються у тимчасовий пакет, і цей пакет розгортається в uat / qa. Будь-яке виправлення помилок відбувається в оригінальній гілці функції, і вона повертається назад у пакет і розгортається. Це відокремлює майбутній випуск, а також дозволяє протестувати ці функції разом до того, як вони знайдуть свій шлях до галузі розвитку. Ті гілки, які затверджені, отримують запит на виведення - слідкуючи за процесом gitflow. Готові функції для тестування можна додати або вилучити з тимчасової гілки пакета та перевстановити.

• Це допомагає майстру завжди відображати стан, готовий до виробництва (може автоматизуватися за допомогою гачка)
• Розвиток завжди відображає останню доставку (і тестування) наступного кандидата на реліз

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

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