Inner Source и микросервисы Как получить больше плюсов, чем минусов?

IT-архитектор в http://byndyusoft.com Byndyusoft – это консалтинг с разработкой в гибридных командах с заказчиком. В прошлом: • Тренер в ScrumTrek • Вожатый на AgileCamp • IT-директор • .NET/Java/Javascript программист Александр Бындю Эксперт в Agile и Lean · IT-архитектор

Нас включают в компанию заказчика для разработки продуктов и внедрения продуктовых практик и технических новинок, например, микросервисов и Inner Source.

Как протолкнуть свою задачу в соседнюю команду? Совещания, убеждения, доказательства и, в итоге, ожидание в очереди до покраснения приоритета.

Inner Source Реализация подхода Open Source в границах компании

1. Исходники всех проектов доступны для всех сотрудников Inner Source

2. Любой может стать контрибьютером с помощью pull request’а Inner Source

3. Core Team принимает изменения извне и следит за целостностью Inner Source

1. Управление приоритетами в бэклоге 2. Выяснение требований по новой фиче 3. Согласование плана работ между командами 4. Разработка фичи 5. Сбор обратной связи “а то ли мы сделали?” Работа по задаче без Inner Source Владелец продукта Команда Критичный ресурс

1. Анализ pull request от внешней команды 2. Добавление кода pull request в свой код ★ Нет спора за приоритеты ★ Нет обсуждения требований ★ Нет программирования ★ Нет сдачи фичи заказчику Владелец продукта Команда Работа по задаче через Inner Source

Поиск нужного репозитория описание репозитория, архитектура, инструмент коллоборации Запуск проекта локально контейнеры, IaC, инструменты разработки Куда внести изменения? документация, внутреннее качество, низкий тех. долг, тесты, инструменты разработки, архитектура, понятный и определенный API Сделать pull request и релиз инструмент коллаборации, continuous delivery, управление релизами Проверить нет ли поломок тесты, внутреннее качество, низкий тех. долг Секрет успеха Inner Source – 5 шагов без барьеров

Если у вас микросервисная архитектура, то часть барьеров к Inner Source уже устранены

В микросервисах: ● Continuous Delivery ● Тотальная автоматизация Контрибьютору не надо читать сложные инструкции, всё работает само под капотом

● IaC ● Контейнеры Контрибьютор может быстро развернуть сервис на своем компьютере В микросервисах:

● Мониторинг ● Трассировка запросов ● Логирование Core Team не страшно принимать pull request’ы В микросервисах:

● Чистый API ● Компилируемые контракты (proto) ● Swagger Чтобы было понять как и где API поменять и на кого это повлияет В микросервисах:

● Паттерны проектирования кода и взаимодействия сервисов: CircuitBreaker, TolerantReader, GracefulDegradation... Чтобы было легче разобраться, какой сервис за что отвечает и не бояться поломать всё вокруг В микросервисах:

Поиск нужного репозитория описание репозитория, архитектура, инструмент коллоборации Запуск проекта локально контейнеры, IaC, инструменты разработки Куда внести изменения? документация, внутреннее качество, низкий тех. долг, тесты, инструменты разработки, архитектура, понятный и определенный API Сделать pull request и релиз инструмент коллаборации, continuous delivery, управление релизами Проверить нет ли поломок тесты, внутреннее качество, низкий тех. долг

Поиск нужного репозитория описание репозитория, архитектура, инструмент коллоборации Запуск проекта локально контейнеры, IaC, инструменты разработки Куда внести изменения? документация, внутреннее качество, низкий тех. долг, тесты, инструменты разработки, архитектура, понятный и определенный API Сделать pull request и релиз инструмент коллаборации, continuous delivery, управление релизами Проверить нет ли поломок тесты, внутреннее качество, низкий тех. долг

Основные сложности в Inner Source – организационные и культурные

Если у сотрудников есть бонусы за фичи, то личные интересы противоречат Inner Source 1. Изменить мотивацию сотрудников Сложности и проблемы Подход к решению

Если баги нашли три месяца спустя, кто поправит? Вернем контрибьютора? 1. Договориться внутри компании об ответственности за создание PR и его апрув Сложности и проблемы Подход к решению

Слабым разработчикам закрыта возможность делать PR или они не хотят открывать свои репозитории 1. Повышать инженерный уровень 2. Интеграция с CI, чтобы на этапе предложения PR получать отказ по сборке или метрикам 3. Решать кадровые вопросы Сложности и проблемы Подход к решению

Неявные изменения, зацикленные изменения и зависимые релизы 1. Открыть доски с задами 2. Создавать задачу на доске, если делаешь PR Сложности и проблемы Подход к решению

Сотрудники должны поменять привычку жаловаться на баги и начать делать PR 1. Удобная система коллаборации, например, Github 2. Целенаправленное обучение Inner Source 3. Конкурсы лучших контрибьюторов Сложности и проблемы Подход к решению

Не много ли проблем?

Зачем Inner Source команде продукта? Вместо написания всего своими силами, можно заниматься только продуктом, а внешние запросы принимать в виде готового кода. Зачем Inner Source потребителям продукта? Вместо ожидания в очереди, можно послать pull request

Agile Небольшие кросс-функциональных команды сфокусированные на целях продукта. Выигрыш: скорость. Быстрая проверка гипотез, эффективное достижение бизнес-целей продукта. Проигрыш: масштабируемость. При большом количестве продуктов в компании рабочий день состоит из совещаний по “синхронизации”

Agile Небольшие кросс-функциональных команды сфокусированные на целях продукта. Выигрыш: скорость. Быстрая проверка гипотез, эффективное достижение бизнес-целей. Проигрыш: масштабируемость. При большом количестве продуктов рабочий день состоит из “синхронизаций” OSS (Inner Source) Совместная работа с открытыми репозиториями для всех продуктов всей компанией. Выигрыш: масштабируемость. Без совещаний каждый эффективно устраняет барьеры для достижения целей своего продукта. Проигрыш: скорость. Распределенная команда продукта не может двигаться также быстро, как выделенная команда продукта.

Agile Подходит для компаний с небольшим количеством продуктов или стартапам. OSS (Inner Source) Подходит для крупных компаний с большим количеством продуктов и/или распределенными командами.

Чеклист запуска Inner Source ❏ Работающая микросервисная архитектура ❏ Система работы с пулреквестами, например, github ❏ Эталонный репозиторий ❏ Открытые досок с задачами ❏ Мотивация сотрудников не противоречит Inner Source Kick off, обучение, рейтинги контрибьюторов ❏ Измеряем успех

https://github.com/dicortazar/mana ging-inner-source-projects/blob/ma ster/measuring/metrics.md#allow-i nnovation-in-detail

Прогноз популярности Inner Source 1. Внедрение Inner Source облегчается DevOps-инструментами, которые постоянно улучшаются, и упрощением работы с микросервисами. 2. Если у конкурентов получилось внедрить Inner Source, то они окажутся впереди, поэтому неизбежно эту практику будут применять всё чаще.

Полезные ссылки 1. Исследование по сравнению Inner Source и Open Source http://www.cs.rug.nl/paris/papers/IST11.pdf 2. Paypal подводит итоги работы в стиле Inner Source https://www.oreilly.com/programming/free/files/getting-started-with-innersource.pdf 3. Модель оценки зрелости Inner Source https://speakerdeck.com/bitergia/a-maturity-model-for-innersource 4. Collaborate through social coding https://www.ibm.com/garage/method/practices/culture/practice_social_coding/overview 5. Паттерны https://github.com/InnerSourceCommons/InnerSourcePatterns 6. Сообщество, статьи, learning path и slack https://innersourcecommons.org/

Вопросы? https://byndyu.ru https://t.me/byndyufeed