Інженерні метрики GitHub проти GitLab: що можна порівняти?
Створіть спільну модель доставки між постачальниками, не вдаючи, що їхні концепції перегляду, планування та ідентифікації ідентичні.
Нормалізація загального життєвого циклу доставки
Запити на отримання GitHub і запити на злиття GitLab спільне корисне ядро: репозиторій, автор, стан, час створення, час злиття, цільова гілка, мітки, правонаступники, запитувані рецензенти, коміти та URL-адреса постачальника. Нормалізована модель може підтримувати відкриту роботу, час для злиття, пропускну здатність, застарілі зміни, участь співавторів і активність сховища в обох постачальників. Зберігайте постачальника та ідентифікатор запису постачальника в кожному рядку, щоб користувачі могли відкривати джерело, а повторювані синхронізації оновлювали правильний запис, а не створювали дублікати.
Зберігайте відмінності, а не згладжуйте їх
Постачальники відрізняються правилами затвердження, призначенням рецензента, поведінкою чернеток, API подій, ієрархією проекту, мітками, етапами, ітераціями та способом відображення ідентифікаторів у групах або організаціях. Поле, яке відсутнє, не стає автоматично нульовим. Нормалізуйте те, що має еквівалентне значення, і збережіть для решти метадані провайдера. Інтерфейс має використовувати мову, нейтральну щодо постачальника, де це можливо, наприклад зміни або запити на отримання та злиття, водночас показуючи оригінальну термінологію та посилання, коли користувач переглядає запис.
Розглядайте показники огляду як чутливі до покриття
Можливо, зміна запитувала рецензентів без завершеної події рецензування, коментарів від ботів, схвалень, які пізніше відхиляються, або подій обговорення, які неправильно відображаються між API. Визначте першу перевірку як значущу перевірку людиною після того, як зміни готові, а потім запишіть використані докази та тип події. Послідовно виключайте відомих ботів. Опублікуйте, скільки змін мають вимірювані дані огляду. Порівняння середніх показників постачальників без порівнянного охоплення подій може дати точний, але хибний висновок.
Концепції планування на карті свідомо
Ітерації GitLab часто належать до груп каденції та представляють датоване вікно доставки. Основні етапи є окремим поняттям і можуть описувати випуски або ширші цілі. Віхи GitHub можуть надати вікно планування, тоді як поведінка, подібна до спринту, може існувати в проектах або мітках. Не перейменовуйте кожну віху як ітерацію та не виводьте команду з дати. Зберігайте тип постачальника, назву, дати, батьківську частоту або проект і URL-адресу джерела. Пропонуйте окремі фільтри, якщо концепції підтримують різні питання управління.
Порівнюйте рішення, а не функції постачальника
Звітування між постачальниками є найбільш корисним, коли воно відповідає на спільне запитання: де збільшується очікування на перевірку? Які робочі потоки рухаються? Де зосереджена власність? Перед порівнянням застосуйте той самий часовий проміжок, область репозиторію, політику ботів і ідентифікацію. Покажіть покриття кожного постачальника та дозвольте користувачам детально ознайомитися з джерелом. Мета полягає не в тому, щоб оголосити одну платформу швидше; це надати організації з декількома постачальниками єдине узгоджене уявлення, дотримуючись семантики, яка робить докази надійними.
Чітко дивіться на свою систему доставки.
Дослідіть робочий простір Troodo, схожий на виробництво, і подивіться, як докази доставки перетворюються на цілеспрямоване керівництво.
Ознайомтеся з живою демонстрацією