Sourcegraph, универсальная платформа поиска кода, используемая такими компаниями, как Amazon, Uber, Atlassian, PayPal, Qualtrics и Cloudflare, запустила новую функцию, призванную помочь предприятиям ускорить «скорость» разработки, метрику, используемую в гибкой разработке для определения объема работы, выполняемой командой во время спринта.
Согласно Sourcegraph, с помощью пакетных изменений, который официально запускаются сегодня, компании могут автоматизировать и отслеживать крупномасштабные изменения кода во всех своих репозиториях и хранилищах кода, экономя до 80% своего времени по сравнению с существующими ручными методами.
Sourcegraph, основанный в Сан-Франциско в 2013 году, объединяет различные направления, которыми оперируют современные команды разработчиков — редакторы, репозитории, языки программирования, форматы файлов и многое другое. В конечном итоге он разработан для решения проблемы «большого кода», которая характеризуется огромным объемом и разнообразием исходного кода, систем и инструментов, которыми компании должны управлять в разных проектах. Поскольку ожидания относительно быстрых циклов разработки ПО возрастают, разработчики должны оптимизировать свою работу.
Именно здесь в игру вступает Sourcegraph, помогающий командам разработчиков находить и исправлять проблемы во всем их коде. И если разработчику нужно знать, как использовать определенную функцию или службу или где находится правильная библиотека для конкретной задачи, они обращаются к Sourcegraph.
Хотя Sourcegraph всегда позволял своим пользователям искать в любом файле репозитория любую строку кода, которую, возможно, необходимо изменить в рамках крупномасштабного рефакторинга, ранее он не предлагал никаких функций для выполнения этого — и именно пакетные изменения сейчас запускает компании. «Sourcegraph теперь позволяет компаниям автоматизировать и поддерживать крупномасштабные изменения кода от начала до конца», — сказал генеральный директор и соучредитель Куинн Слэк.
С помощью пакетных изменений Sourcegraph пытается решить проблему, которая скорее влияет на более крупные предприятия с несколькими командами и отделами разработки, хотя на самом деле это может оказаться полезным для любого проекта, в котором код используется в нескольких репозиториях. Компании часто создают шаблонный код и компоненты, которые могут повторно использоваться разными командами и проектами. Но когда дело доходит до внесения изменений в такой код, возникают проблемы — необходимо передать такие изменения всем другим командам, которые его используют. Это может быть «медленным, болезненным и иметь низкий процент завершения». «Это может привести к тому, что большая часть кода просто не будет обновляться, что приведет к техническому долгу», — говорит Слэк.
Таким образом, с помощью пакетных изменений компании могут изменять шаблонный код и применять изменения к любому репозиторию, в котором может находиться код. «Затем они могут отслеживать прогресс таких крупномасштабных изменений, когда владельцы репозиториев просматривают и принимают его», — пишет компания.
Пакетные изменения могут оказаться полезными во множестве сценариев, таких как, например, выпуск исправлений безопасности. Код для исправления ошибки может быть несложным для написания, но если проблема существует в сотнях репозиториев, развертывание обновления с последующим принятием каждого запроса на перенос в основную базу кода может оказаться ужасно трудоемким.
Крупные технологические компании, такие как Facebook и Google, разработали собственные проприетарные универсальные платформы поиска кода для внутреннего использования, и они часто включают инструменты для автоматизации изменений кода — Google создал инструмент под названием Rosie для функции «найти и заменить».
«Вместо создания этой функциональности внутри компании, что потребовало бы чрезвычайно больших затрат времени и средств, теперь компании могут использовать наши пакетные изменения», — отмечает Слэк.