Что такое развитие «внутреннего источника» и стоит ли его использовать?

Внутренний источник, часто стилизованный под InnerSource, относится к внедрению в организации процессов и методологий разработки с открытым исходным кодом. В то время как «открытый исходный код» подразумевает создание общедоступных инструментов, внутренний исходный код означает, что вы работаете над внутренними проектами, используя открытые подходы.

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

Эта модель может резко контрастировать с тем, как разрабатывается программное обеспечение в крупных организациях. В этих средах инструменты разрабатываются отдельными командами по мере необходимости. Люди работают обособленно, внося свой вклад в свои отдельные области, не обращая внимания на дублирующую работу, которая выполняется где-то еще.

Знакомство с внутренним источником

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

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

Внутренний источник — это не только код. Его можно расширить, включив в него более широкие активы и документацию, относящуюся к бизнесу, его операциям и его программному обеспечению. Цель состоит в том, чтобы предоставить людям возможность самостоятельно выбирать задачи и делиться своим опытом там, где, по их мнению, это принесет пользу организации, даже если они наняты для работы в определенной области.

Преимущества внутреннего источника

Сторонники архитектур с «внутренним исходным кодом» отмечают несколько существенных преимуществ этого подхода, в том числе сокращение потерь, ускорение времени запуска, снижение напряженности между командами и улучшение качества кода. Они объединяются для повышения производительности организации и культуры на рабочем месте.

• Сокращение отходов, улучшенное повторное использование. В крупных организациях может возникнуть ситуация, когда одинаковый код дублируется в нескольких проектах, принадлежащих разным командам. Если команды не разговаривают друг с другом, тот факт, что у вас теперь есть три похожие библиотеки кэширования, может остаться незамеченным. Публикация всего кода внутри компании предупредит других о наличии обычных инструментов, а затем поощрит совместную итерацию в единой кодовой базе. Колесо перестанет изобретаться заново, заставляя всех выполнять задачу и ускоряя сроки запуска.
• Улучшенное качество кода. Код, написанный в открытом доступе, более уязвим, поэтому ошибки, скорее всего, появятся на более ранних этапах процесса разработки. Если общая библиотека будет принята новой командой, могут возникнуть проблемы, которые раньше не замечались. Внедрение исправлений пойдет на пользу всем проектам, использующим библиотеку.
• Меньше напряженности между командами. Хотя поначалу переход к открытой модели может показаться неудобным, разработка внутреннего исходного кода предназначена для преодоления барьеров и расширения сотрудничества. Закрытая разработка может создать непростые ситуации, когда вы обнаружите, что соседняя команда создала лучшую версию библиотеки, которую вы использовали. В открытой модели это решается путем совместной работы над общей кодовой базой, которая включает возможности, необходимые для всей группы.

Внутренний источник упрощает организационную структуру, предоставляя всем разработчикам одинаковое представление о текущей работе. Принятие вкладов извне от команды, которая «владеет» проектом, обеспечивает доступ к свежему взгляду и расширенному набору решений.

Реализация рабочего процесса с внутренним исходным кодом

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

В любом переходе есть два фундаментальных аспекта: общение и инструменты. Первый относится к обучению членов команды тому, что происходит и как они смогут внести свой вклад в открытые проекты. «Установить и забыть» уровни доступа будет неэффективно, поскольку люди не будут знать о своих новых способностях и о том, когда их можно использовать.

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

Внутренний источник требует единой модели разработки, которая будет одинаково работать во всех проектах. Это означает максимальное использование возможностей Git и вашей хостинговой платформы, такой как GitHub или GitLab.

Участники должны иметь возможность отправлять изменения в запросе на вытягивание, которое сопровождающие затем проверяют и объединяют. Запросы на вытягивание должны дополняться набором тестов, которые выполняются в конвейере CI. Это дает поддерживающей команде уверенность в том, что изменение эффективно, и гарантирует, что весь код соответствует одним и тем же стандартам. Обеспечение самопроверки кодовой базы с помощью автоматических тестов и проверок помогает устранить трения.

Вам также следует подумать о том, как хранятся и отображаются вспомогательные активы, такие как документация и списки проблем. Создайте открытую командную вики для документации по API и справочных материалов по архитектуре; обеспечить централизованное отслеживание всех ошибок и запросов функций. Это позволит людям со всей организации найти нужную им информацию. Это также позволяет отдельным пользователям вносить улучшения в произвольные проекты в более спокойные периоды — любой может найти отчеты об ошибках и начать их исправлять, что приведет к улучшениям во всех нижестоящих репозиториях.

Недостатки, которые следует учитывать

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

Одним из наиболее частых опасений по поводу внутреннего источника является его влияние на безопасность и раскрытие информации. Сходство между внутренним исходным кодом и более широкой экосистемой с открытым исходным кодом простирается лишь до сих пор: код в открытой библиотеке или фреймворке не содержит ничего конфиденциального, в то время как вы можете иметь дело с тщательно охраняемыми проприетарными системами в своей роли на работе.

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

Открыть проекты, которые можно безопасно выставить, все же стоит. Вы также можете абстрагировать неконфиденциальные части частных проектов в новые общедоступные общие библиотеки. Это приближает преимущества внутреннего источника к вашим конфиденциальным активам, фактически не раскрывая их.

Еще одна проблема внутреннего источника — это передача ожиданий разработчикам. Разработчики могут с осторожностью относиться к открытым проектам, особенно если внутренний источник используется в исторически закрытой организации. Это можно решить различными способами, например, выделить время для разработчиков на проверку кода, написанного другими командами.

Также может быть полезно начать с малого, открывая только основные библиотеки, которые будут полезны многим различным командам в организации. Хорошим выбором может быть хорошо известный, но частный компонент, который имеет репутацию ненадежного или устаревшего — подумайте «опять сообщил об ошибке с ApiClient». Открытие этого компонента позволяет разработчикам вносить свои собственные исправления по мере необходимости, повышая производительность и способствуя органическому росту менталитета внутреннего источника.

Если вы все же попробуете этот метод, будьте осторожны, чтобы сначала предупредить авторов оригинального проекта — даже если это приведет к большей эффективности во всех отношениях, некоторые люди могут относиться к другим, вносящим свой вклад в код, который ранее был «их», как к оскорблению. Сообщите, почему внутренний источник внедряется в организацию, а также конкретные причины для открытия отдельных проектов.

Заключение

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

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

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