Команда, обслуживающая инфраструктуру .NET, инвестирует в согласованность, чтобы ускорить внедрение связанных с открытым кодом инноваций

Посмотрите, как общий инструментарий в единой общей системе непрерывной интеграции для всех репозиториев GitHub значительно повышает продуктивность разработчиков.

Задача: оптимизация совместной работы для участников проектов с открытым кодом

Как независимая организация, созданная для ускорения внедрения инноваций с помощью открытой разработки и совместной работы, .NET Foundation поддерживает большой и сложный набор проектов с открытым кодом, включая .NET Core. Команда Microsoft .NET Engineering Services участвует в проекте и отвечает за большую часть инфраструктуры, которая позволяет участникам со всего мира работать вместе.

Из-за десятков различных git-репозиториев на GitHub, широкого набора инструментов и нескольких различных систем непрерывной интеграции (CI), используемых в проекте, происходила путаница, мешавшая производительности. Большие масштабы проекта тоже способствовали сложности. Например, только репозиторий Roslyn (компилятор C#) выполняет более 600 000 автоматизированных тестов за одну итерацию запроса на вытягивание. Из-за того, что в неделю выполняется более 50 запросов на вытягивание, при этом каждый предполагает множество итераций, количество тестов непрерывной интеграции измеряется миллиардами. В случае CoreFx (библиотек) эта цифра больше. Так как команда .NET Engineering Services планировала выпуск .NET Core 3.0, она решила внести значительные изменения и добиться большей согласованности, чтобы дать участникам возможность реализовать весь потенциал проекта.

"A distributed repo structure and tooling makes it a lot harder for developers to move from one repo to another … And if it's this hard on Microsoft developers, how can we expect most individual contributors to figure it out?"

Мэтт Митчелл, главный инженер программного обеспечения .NET Engineering Services

Повышение продуктивности благодаря общему инструментарию и единой системе непрерывной интеграции

Чтобы разработчикам было легче перемещаться между различными частями стека программного обеспечения, команда .NET Engineering Services старалась обеспечить для всех репозиториев общую структуру каталогов, один набор команд и единую логику сборки и тестирования. Команде удалось преодолеть и другие барьеры на пути к продуктивности, переместив существующие рабочие процессы из различных систем непрерывной интеграции в единую систему Azure Pipelines. Так как эта система полностью управляемая, команда больше не несет ответственности за управление инфраструктурой сервера непрерывной интеграции. Сейчас команда практикует метод "конфигурация как код" с использованием файлов YAML, которые хранятся в GitHub, а конвейеры YAML применяются повсеместно. Ранее для некоторых репозиториев непрерывная интеграция была последовательной, и это иногда заставляло разработчиков ждать два или три часа между итерациями кода. Теперь все конвейеры непрерывной интеграции выполняются параллельно, обеспечивая более быстрые итерации.

"Now that we longer need to worry about the operational aspects of CI, we're free to focus on further improvements that will be felt by all—including Microsoft developers and individual contributors alike."

Мэтт Митчелл, главный инженер программного обеспечения .NET Engineering Services

Чем лучше совместная работа, тем лучше продукт

Сегодня разработчикам намного проще переходить от одного репозитория к другому, выявлять первопричину ошибки, предлагать исправления и тестировать их. И для всего этого практически не нужны специализированные знания, которые требовались раньше. Упрощенная совместная работа с открытым кодом в GitHub позволяет разработчикам быстрее внедрять инновации, поскольку над написанием, тестированием, сборкой и доставкой программного обеспечения высокого качества они работают вместе. Так как команда .NET Engineering Services может вносить изменения в инфраструктуру по всему стеку, она может совершенствовать инструментарий, который разработчики могут использовать во всех репозиториях гораздо быстрее и эффективнее.

Давайте рассмотрим ближе путь команд и принятие решений.

Прочесть статью полностью