Инженерные метрики GitHub vs GitLab: что можно сравнивать?
Создайте общую модель доставки для всех поставщиков, не делая вид, что их концепции проверки, планирования и идентификации идентичны.
Нормализовать общий жизненный цикл доставки
Запросы на извлечение GitHub и запросы на слияние GitLab имеют общее полезное ядро: репозиторий, автор, состояние, время создания, время слияния, целевая ветка, метки, правопреемники, запрошенные рецензенты, коммиты и URL-адрес поставщика. Нормализованная модель может поддерживать открытую работу, время слияния, пропускную способность, устаревшие изменения, участие участников и активность репозитория между обоими поставщиками. Сохраняйте идентификатор поставщика и записи поставщика в каждой строке, чтобы пользователи могли открыть источник и чтобы повторные синхронизации обновляли правильную запись, а не создавали дубликаты.
Сохранять различия, а не сглаживать их
Поставщики различаются правилами утверждения, назначением рецензентов, черновым поведением, API-интерфейсами событий, иерархией проектов, метками, этапами, итерациями и способом отображения удостоверений в группах или организациях. Поле, которое отсутствует, не является автоматически нулевым. Нормализуйте то, что имеет эквивалентное значение, и сохраните метаданные, специфичные для поставщика, для остальных. В интерфейсе, где это возможно, следует использовать язык, нейтральный к поставщику (например, запросы на внесение изменений или запросы на включение и слияние), при этом показывая исходную терминологию и ссылку, когда пользователь просматривает запись.
Считайте показатели проверки чувствительными к охвату.
Изменение могло быть вызвано запросом рецензентов без завершенного события проверки, комментариями от ботов, утверждениями, которые позже отклоняются, или событиями обсуждения, которые не четко отображаются в API. Определите первую проверку как значимую проверку человеком после того, как изменение будет готово, затем запишите использованные доказательства и тип события. Постоянно исключайте известных ботов. Опубликуйте, сколько изменений имеет измеримые данные проверки. Сравнение медианных значений поставщиков без сопоставимого освещения событий может привести к точному, но ложному выводу.
Сознательно составьте карту концепций планирования
Итерации GitLab часто относятся к группам каденции и представляют собой датированное окно доставки. Вехи представляют собой отдельную концепцию и могут описывать релизы или более широкие цели. Вехи GitHub могут предоставить окно планирования, в то время как поведение, подобное спринту, может находиться в проектах или метках. Не переименовывайте каждую веху как итерацию и не делайте вывод о команде по дате. Сохраните тип поставщика, название, даты, родительскую частоту или проект, а также исходный URL-адрес. Предлагайте отдельные фильтры, если концепции поддерживают разные вопросы управления.
Сравнивайте решения, а не количество функций поставщиков
Отчеты между поставщиками наиболее полезны, когда они отвечают на общий вопрос: где увеличивается время ожидания проверки? Какие рабочие направления перемещаются? Где сконцентрирована собственность? Перед сравнением примените тот же временной интервал, область репозитория, политику ботов и сопоставление идентификаторов. Покажите покрытие каждого провайдера и дайте пользователям возможность подробно изучить источник. Цель не в том, чтобы объявить одну платформу быстрее; это значит дать организации с несколькими поставщиками единую последовательную точку зрения, соблюдая при этом семантику, которая делает доказательства заслуживающими доверия.
Четко посмотрите на свою систему доставки.
Исследуйте производственное рабочее пространство Troodo и узнайте, как доказательства доставки становятся целенаправленным управленческим заданием.
Изучите живую демонстрацию