$30 off During Our Annual Pro Sale. View Details »

Управление разработкой в блокчейн-компании

Управление разработкой в блокчейн-компании

Денис Васин (Waves Enterprise, CTO) @ Moscow Python №78

"Аспекты управления командой разработки одной из лидирующих блокчейн-платформ в России".

Видео: https://moscowpython.ru/meetup/78/dev-management-in-blockchain/

MoscowPython: http://moscowpython.ru
Курсы Learn Python: http://learn.python.ru
Moscow Python Podcast: http://podcast.python.ru

Moscow Python Meetup

July 14, 2022
Tweet

More Decks by Moscow Python Meetup

Other Decks in Programming

Transcript

  1. 2 Особенности платформы Высокая пропускная способность Использование протокола Waves NG

    и оптимизация сетевых протоколов позволяет достичь промышленной пропускной способности Ролевая модель и контроль доступа Майнинг блоков и операции различных типов в сети выполняются авторизованными участниками Конфиденциальность данных Возможность обмена конфиденциальной информацией между авторизованными участниками сети Гибкость настройки Возможность выбора криптографических алгоритмов и алгоритма консенсуса (LPoS, PoA, CFT), гибкая настройка сети Корпоративный клиент All-in-one: Blockchain Explorer, Smart contracts toolkit, Token wallet, Permission manager, Node Configuration, Monitoring dashboards Смарт-контракты Контейнеризированные тьюринг-полные смарт-контракты Архитектура sidechain Перемещение активов и информации между проектами на Waves Enterprise и другими платформами Дополнительные функции Атомарные транзакции Архивирование блокчейна
  2. 3 • Алгоритмы консенсуса, не требующие создание высокопроизводительных кластеров и

    большого расхода электроэнергии. • Возможность построения публичных, закрытых и гибридных блокчейн-сетей. • Платформа позволяет создавать высоконагруженные, катастрофоустойчивые промышленные решения. • Смарт-контракты любой сложности на различных языках программирования 1. Гибкость и производительность Преимущества Waves Enterprise • Управление доступом, ролями и правами пользователей и узлов блокчейн-сети. • Конфиденциальный обмен данными между авторизованными участниками. • Шифрование данных с применением ГОСТ-алгоритмов 2. Безопасность и конфиденциальность • Коробочное решение, готовое к развертыванию в корпоративной инфраструктуре. • Богатый встроенный инструментарий для развертывания, интеграции, отладки и мониторинга. • Подробная документация на русском языке. • Российский вендор обеспечивает развитие и техническое сопровождение платформы, оказывает консультационную и техническую поддержку на всех этапах создания информационных систем. 3. Промышленное решение • Полностью российская разработка, проходит регистрацию в реестре отечественного ПО Минкомсвязи. • Реализованы отечественные криптографические алгоритмы, соответствующие требованиям регуляторов и обеспечивающие юридическую значимость. • В процессе сертификации в ФСБ России. 4. Соответствие требованиям регуляторов
  3. 5 Ø Есть разработка продукта (блокчейн платформы). Это серьезный монолит,

    по сложности сравнимый с распределенной БД Ø Есть разработка прикладных проектов (для заказчиков). Это классические микросервисы, но с деплоем он-премис. Ø Есть разработка продуктов на базе собственной основой сети. Классические микросервисы и быстрые итерации. Что значит блокчейн компания? Проблематика: Ø Структурировать организацию так, чтобы она отражала продуктовую и проектную линейку Ø Выработать различные подходы к процессу разработки в каждом из типов команд Решение: Ø Команды могут следовать наиболее эффективному для них процессу Плюсы решения: Ø Необходимо понять наиболее подходящий процесс для каждого типа команд Минусы решения:
  4. 6 Ø Продукт монолитный, с большим количеством сложных фичей Ø

    Разработка ведется не в “ширину” а в ”глубина” Ø Классический подход “груминг”, “планирование” не работает (фичи требуют глубокого анализа и погружения в криптографию и консенсус) Ø Команда большая > 20 человек Разработка ядра Проблематика: Ø Делим большую команду на 3 (Discovery, Feature 1, Feature 2) Ø Discovery работает по канбану и наполняет беклог детализированными фичами Ø Feature команды работают как воркеры в очереди разгребая беклог Решение: Ø Делаем команды стандартного размера, снижаем время митингов Ø Команды работают в комфортном для решения своих задач режиме Плюсы решения: Ø Дополнительные “синк” митинги на все команды Ø Участники фича команд перестают владеть всем кодом проекта Ø Нужна ротация разработчиков между фича командами Минусы решения:
  5. 8 Ø Есть публичная сеть в которой нужно обеспечить доверие

    Ø Наличие интеграционных компонентов (SDK), которые должны быть понятны конечному пользователю Ø Две поставки платформы – OpenSource и Corporate Ø Все CI/CD процессы завязаны на внутренний GitLab Open Source Проблематика: Ø Используем git subtree для подключения OpenSource к Corporate Ø Используем зеркалирование (внутренняя разработка) GitLab -> GitHub. Ø SDK разрабатывается GitHub - first Решение: Ø Минимум переделки инфраструктуры Ø Можно выполнять большие сложные кластеризованные тесты Ø Рефакторинг кода (модульная структур) Плюсы решения: Ø Гоняем тесты только для Corporate версии Ø Процесс разработки OpenSource не вполне прозрачен Минусы решения:
  6. 9 Ø После “известных событий” заказчики стали существенно дотошнее относится

    к ИБ Ø Необходимо настроить сквозной процесс контроля, понятный РП Ø Нужны метрики позволяющие оценить безопасность кодовой базы DevSecOps Проблематика: Ø Используем инструмент SonarQube для контроля качества кода Ø Используем инструмент Trivy для контроля докер образов Ø Визуализируем динамику и отчетность для РП с помощью Starboard Решение: Ø Формальный контроль качества кода с точки зрения ИБ формализован Ø Минимизация конфликтов с заказчиками Плюсы решения: Ø Необходимо развернуть достаточного много ПО и обучить РП работать с ним Ø Starboard изрядно захламляет k8s кластер Минусы решения:
  7. 11 Ø Некоторые доработки блокчейна влияют на механизм консенсуса (новый

    транзакции, фиксы багов и.т.л) Ø На промышленных сетях > 100 узлов в разных компаниях, единовременно обновляться нельзя Releases Проблематика: Ø Создаем в платформе механизм софт-форка Ø Софт-форк – это feature flag который включается через механизм консенсуса (голосование) Ø Визуализируем динамику и отчетность для РП с помощью Starboard Решение: Ø В раунде майнинга нода голосует за известные ей софт форки Ø Через интервал времени T происходи подсчет голосов Ø Если есть консенсус – фича активируется, если нет – ждем еще Т Как это работет: Ø Необходимо обучать специалистов заказчика работе с конфигурацией софт-форков Ø Невозможно мгновенно выкатить обновление даже если оно содержит критические правки Минусы решения:
  8. 12 Ø Python QA Automation Engineer (Senior) Ø Автоматизация тестов

    блокчейн платформы в разных сценариях (консенсус, крипта) Ø Кластеризация тестов Ø Тестирование с эмуляцией проблем в сети Ø Участие в развитии платформы You are welcome! In search of: