Відповіді:
Функціональні прапори - це інженерний пристрій, за допомогою якого можна уникнути довготривалих галузей та конфліктів у розробці продукту. Ось як можна використовувати контекст об'єктно-орієнтованої мови, щоб допомогти розробникам співпрацювати над конкретною функцією продукту, обробляючи нову версію. Це рішення також може використовуватися в не об'єктно-орієнтованих контекстах за умови існування поняття "інтерфейс". ( пор. система модулів OCaml.)
Для ілюстрації ми передбачаємо інструмент, який представляє звіти про дані, що зберігаються в базі даних. Код реалізує a клас DatabaseClient, який використовується для виконання запитів. Зі збільшенням набору даних стає зрозуміло, що деякі альтернативні компонування даних покращать продуктивність програми. Тому Аліса розробить нову версію DatabaseClient, яка зможе отримати дані зі структур із покращеним компонуванням, а Боб буде підтримувати історичний DatabaseClient .
Слідуючи наступним крокам, Аліса та Боб можуть співпрацювати на короткочасних гілках, мінімізуючи їхні конфлікти.
Аліса перейменує DatabaseClient в DatabaseClient_v1 і створить клас делегата, який називається DatabaseClient, який використовує об’єкт DatabaseClient_v1 і реалізує інтерфейс під назвою DatabaseClientInterface. (Якщо можливо, цей DatabaseClientInterface повинен бути артефактом коду, але мови, що набираються качками, не завжди підтримують це.)
Боб переглядає зміни, внесені Алісою в 1, і знає, що його робота з обслуговування повинна відбуватися в DatabaseClient_v1 .
Аліса вводить новий прапор конфігурації у додаток, який регулює поведінку DatabaseClient делегата та реалізує заповнювач DatabaseClient_v2 , клас, що реалізує інтерфейс DatabaseClientInterface, чиї методи викидають виняток "Не реалізовано".
Після цього Аліса та Боб можуть співпрацювати без явної синхронізації, оскільки код, записаний у відповідних ітераціях, підпорядковується DatabaseClientInterface . Це мінімізує ризик виникнення конфлікту внаслідок їх одночасної роботи.
Ітерації від Alice можуть бути дуже короткими, як, наприклад, проведення тесту, реалізація методу або навіть частково це, оскільки у виробництві код не вибирається для використання і не потребує повноцінного функціонування. Автоматизований тестовий набір повинен бути налаштований так, що DatabaseClientInterface завжди використовує DatabaseClient_v1, тоді як Аліса може легко перемикатися на DatabaseClient_v2 під час запуску тестового набору локально - або в користувальницькій установці CI. Після того, як все готово, одна фіксація може виконати зміну, оновивши значення конфігурації, що регулює делегат DatabaseClient .
Етапи досить "прості", щоб перейти до додатка для позначення функцій, вам в основному потрібно дві речі:
Основним прапором функції є ввімкнення / вимкнення, але швидко ви захочете випустити нову функцію в режимі нарощування, наприклад: 1 сервер на 5 хостингах програми має функцію "включено", щоб запустити, потім ви включаєте функцію на іншому сервері, поки всі сервери не ввімкнули її.
Це означає, що ви повинні бути обережними щодо того, щоб ваша функція була сумісною з додатком без нього (наприклад, додатковий стовпець у БД).
Каркаси існує на різних мовах , щоб не винаходити колесо, тепер зніміть підтримується один з Etsy має цікавий ріое , щоб пояснити , як це працює.
У вбудованому програмному світі часто використовуються прапори часу нарощування, у самому коді програми ( #define/ #ifdefзаяви, наприклад) та / або у файлах конфігурації інструментів побудови ( makefileнаприклад,).
Прапорці побудови можуть використовуватися аналогічним чином не тільки для функцій, але і для всіх видів рефакторингу коду, міграцій, підтримки налагодження тощо). Вони дозволяють здійснити в гілці інтеграції часткові або неперевірені зміни, не порушуючи складання або спричиняючи регресії у функціях / проектах, які вже працюють у галузі. Відмінно підходить для обробки виправлень точок поряд із великими / ризикованими / повільними змінами прогресу (які в іншому випадку вимагатимуть довгоживучої гілки) безперервної інтеграції.
Але крім перевірки вже існуючого коду філії для регресії, також можливо проводити перевірку прогресу / стабільності нового коду. Для цього потрібно встановити прапори часу нарощування.
Одним із способів перемикання прапорів було б використання в окремому конвеєрі верифікації системи CI тієї ж гілки (якщо він підтримує таку функціональність), патчфіл, що перемикає прапор - застосовуватись до окремої робочої області до початку будувати. Інший набір артефактів буде побудований у цій робочій області та підтверджений.
Крім того, довговічну гілку можливостей можна витягнути з основної гілки інтеграції, але єдиною зміною цієї гілки функції було б переключений прапор. Завдяки цій крихітній зміні гілка функцій може бути автоматично синхронізована надзвичайно швидко - практично тініючи дуже тісно основну гілку інтеграції. Окреме виконання CI у цій гілці більше не потребуватиме попереднього виправлення файлу. Неодмінно було б обіймати таку галузь функції навіть протягом тривалого періоду часу.
У головній галузі інтеграції також можливо створити нові артефакти побудови, які справді були б лише клонами існуючих артефактів побудови, але зі зміщеними прапорами. Таким чином, ні попередній патч-файл, ні функціональна гілка не знадобляться для перевірки нового коду прямо у головній гілці.