Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Inner Source и микросервисы: как получить больш...

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

InnerSourcing и микросервисы дополняют друг друга и одновременно повышают порог вхождения новичков в эту тему. Я расскажу с точки зрения IT-архитектора и организатора процесса разработки:
1. В чем конкретно можно выиграть при использовании InnerSourcing.
2. Какие инструменты и паттерны нужны для достижения успеха, и что будет, если их не использовать.
3. С какими проблемами сталкиваются компании, где мы настраивали связку InnerSourcing+микросервисы, даже если делали всё максимально хорошо.

Статья на эту тему и видео запись доклада на ArchDays https://blog.byndyu.ru/2019/12/inner-source.html

Александр Бындю

November 22, 2019
Tweet

More Decks by Александр Бындю

Other Decks in Technology

Transcript

  1. IT-архитектор в http://byndyusoft.com Byndyusoft – это консалтинг с разработкой в

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

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

    и, в итоге, ожидание в очереди до покраснения приоритета.
  4. 1. Управление приоритетами в бэклоге 2. Выяснение требований по новой

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

    pull request в свой код ★ Нет спора за приоритеты ★ Нет обсуждения требований ★ Нет программирования ★ Нет сдачи фичи заказчику Владелец продукта Команда Работа по задаче через Inner Source
  6. Поиск нужного репозитория описание репозитория, архитектура, инструмент коллоборации Запуск проекта

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

    надо читать сложные инструкции, всё работает само под капотом
  8. • Мониторинг • Трассировка запросов • Логирование Core Team не

    страшно принимать pull request’ы В микросервисах:
  9. • Чистый API • Компилируемые контракты (proto) • Swagger Чтобы

    было понять как и где API поменять и на кого это повлияет В микросервисах:
  10. • Паттерны проектирования кода и взаимодействия сервисов: CircuitBreaker, TolerantReader, GracefulDegradation...

    Чтобы было легче разобраться, какой сервис за что отвечает и не бояться поломать всё вокруг В микросервисах:
  11. Поиск нужного репозитория описание репозитория, архитектура, инструмент коллоборации Запуск проекта

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

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

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

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

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

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

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

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

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

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

    OSS (Inner Source) Подходит для крупных компаний с большим количеством продуктов и/или распределенными командами.
  22. Чеклист запуска Inner Source ❏ Работающая микросервисная архитектура ❏ Система

    работы с пулреквестами, например, github ❏ Эталонный репозиторий ❏ Открытые досок с задачами ❏ Мотивация сотрудников не противоречит Inner Source Kick off, обучение, рейтинги контрибьюторов ❏ Измеряем успех
  23. Прогноз популярности Inner Source 1. Внедрение Inner Source облегчается DevOps-инструментами,

    которые постоянно улучшаются, и упрощением работы с микросервисами. 2. Если у конкурентов получилось внедрить Inner Source, то они окажутся впереди, поэтому неизбежно эту практику будут применять всё чаще.
  24. Полезные ссылки 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/