Рабочий процесс совместной работы для тестирования и проверки общих компонентов изолированно и в нескольких приложениях.
Компонентно-ориентированная программная инженерия (CBSE) не нова. Используя CBSE, мы разбиваем сложные системы на более простые, независимые компоненты, которые легче понимать, разрабатывать и обслуживать.
Но как нам эффективно сотрудничать с этими независимыми общими компонентами? Решение можно найти за счет коллективных возможностей Bit, Git и любой системы CI, а также облачной платформы Bit, bit.cloud.
В этом сообщении в блоге описывается гибридный рабочий процесс, который эффективно сочетает в себе Bit и Git для беспрепятственной работы в качестве постоянного рабочего процесса или в качестве шага к полностью распределенному сотрудничеству с Ripple CI, системой CI для распределенных систем на основе компонентов.
См. репозиторий Github с PR здесь:
См. полный удаленный объем здесь:
Рабочий процесс: обзор
Наш рабочий процесс представляет собой хорошо скоординированную серию шагов с участием разработчиков, общего рабочего пространства Bit, отслеживаемого Git и размещенного на GitHub, и системы непрерывной интеграции на основе GitHub Actions.
Процесс начинается с того, что разработчик клонирует основной репозиторий, в котором находится рабочее пространство Bit с несколькими поддерживаемыми в нем компонентами Bit.
После создания новой ветки и изменения компонентов разработчик отправляет эти изменения на удаленный сервер.
При каждом нажатии на ветку запускается рабочий процесс GitHub Actions. Он проверяет изменения с помощью Bit.
Когда создается запрос на вытягивание (PR), привязки CI (версии) компонента изменяются в изолированной дорожке, чтобы позволить рецензентам предварительно просмотреть и даже установить измененные компоненты. Полоса доступна на bit.cloud.
После слияния PR CI привязывает компоненты к новой версии выпуска (с Bit) и экспортирует их в свои удаленные области на bit.cloud.
Обновленное рабочее пространство, включая новые версии компонентов, возвращается в репозиторий CI.
В следующих разделах мы подробно рассмотрим эти шаги и предоставим дополнительные пояснения для каждого этапа.
Роль разработчика: клонирование, создание ветвей и изменение компонентов
В этом разделе основное внимание уделяется важным действиям, которые разработчик выполняет в нашем совместном рабочем процессе, в частности, шагам, предпринимаемым при ветвлении и изменении компонентов.
Во-первых, разработчик извлекает последние изменения из удаленной основной ветки. Затем разработчик создает новую ветвь для функции, которая включает изменения в некоторые компоненты.
Создав новую ветку, разработчик изменяет компоненты в рабочей области Bit. Например, разработчик обновляет зависимости в нашем демонстрационном репозитории (см. изменения), изменяет среду разработки компонента (см. изменения) и изменяет исходные файлы компонента приложения (см. изменения). Вы можете увидеть эти изменения, отраженные в репозитории.
На протяжении всего процесса модификации разработчик использует команды Bit bit status и bit diff, чтобы отслеживать изменения. Эти команды позволяют получить представление о состоянии компонентов. Команда bit status показывает, какие компоненты были изменены напрямую, а какие будут автоматически помечены при пометке их зависимостей.
Например, если вы запустите bit diff для компонента, для которого были обновлены зависимости, Bit распознает эти изменения и пометит компонент как измененный, как вы можете видеть в выводе в нашем демонстрационном репозитории.
По мере внесения изменений файлы workspace.jsonc и .bitmap соответственно обновляются. Изменения в зависимостях отражаются в файле workspace.jsonc, а изменения конфигурации среды фиксируются в файле .bitmap. Это обеспечивает прозрачную запись состояния рабочей области в любой момент времени.
Как только разработчик доволен внесенными изменениями, эти изменения передаются в удаленный репозиторий Git в новой ветке. Это действие запускает автоматизированные процессы, управляемые Github Actions, которые мы рассмотрим в следующем разделе.
Инструменты непрерывной интеграции: выполнение проверки с помощью GitHub Actions
Инструменты CI жизненно важны в современных рабочих процессах разработки программного обеспечения, особенно при работе с различными соавторами и независимыми компонентами. В нашем рабочем процессе GitHub Actions служит выбранным инструментом CI.
Получив новую ветку, отправленную разработчиком, GitHub Actions инициирует процесс проверки. Он использует команды Bit bit status и bit build для выполнения этой проверки.
Команда bit status гарантирует отсутствие проблем с компонентами в рабочей области. Команда bit build создает компоненты в изолированной среде («капсуле»), чтобы их можно было снимать и использовать независимо друг от друга.
bit status bit build
Эти проверки гарантируют, что изменения разработчика верны и готовы к следующему этапу рабочего процесса.
Создание запроса на слияние (PR)
Разработчик создает PR в нашем демонстрационном репозитории, содержащем внесенные им изменения в компоненты. PR включает изменения в зависимостях компонентов, конфигурации и исходных файлах. Это приглашение для остальной части команды просмотреть изменения, инициировать обсуждение, предоставить обратную связь и, в конечном итоге, утвердить изменения.
После того, как PR создан, Github Actions снова играет роль. CI использует Bit для создания дорожки, соответствующей вновь созданному PR, и экспортирует измененные компоненты на эту дорожку в bit.cloud. Затем PR обновляется ссылкой на удаленную полосу.
Компоненты можно просматривать в удаленной полосе и даже устанавливать в проекты, чтобы убедиться, что они функционируют должным образом в новых контекстах.
Например, чтобы установить невыпущенную версию компонента панели приложений (предлагается как часть PR/Lane), запустите в любом проекте следующее:
npm i @showoff/personal-portfolio.navigation.appbar@0.0.0-74cde8d55330b9921e93f145d242e195e19466fa
Обратите внимание, что для установки компонента из реестра Bit необходимо настроить диспетчер пакетов на использование Bit для определенных областей NPM.
Роль рецензентов: технический руководитель и дизайнер
Процесс проверки начинается после того, как запрос на слияние открыт и компоненты экспортированы в битовую дорожку. Ключевыми лицами на этом этапе являются технический руководитель и дизайнер.
Роль технического руководителя заключается в просмотре кода и конфигураций. Они проверяют изменения зависимостей в файле workspace.json и изменения конфигурации компонента в файле .bitmap. Технический руководитель также посещает Bit Lane, чтобы изучить компонент с измененными исходными файлами и проверить различия в зависимостях и средах.
С другой стороны, дизайнер фокусируется на пользовательском интерфейсе. Они используют функцию визуального предварительного просмотра Bit Lane для проверки изменений пользовательского интерфейса, внесенных в компоненты.
И технический руководитель, и дизайнер имеют возможность установить измененные компоненты в другой проект. Это может быть особенно полезно для тестирования и проверки изменений в реальном контексте.
Выпуск новых версий компонентов
После тщательного рассмотрения PR готов к последним шагам, как только технический руководитель и дизайнер одобрят изменения. Действия GitHub возвращаются в игру, проверяя изменения. Как только они проходят проверку, GitHub Actions привязывает измененные компоненты к версии выпуска и экспортирует их в область действия в bit.cloud. Затем изменения в рабочей области (битмап) подтверждаются CI.
Подведение итогов: преимущества и потенциал этого рабочего процесса
Теперь мы познакомили вас с эффективным совместным рабочим процессом, использующим сильные стороны Git, Bit, Github и Github Actions. Этот гибридный подход позволяет разработчикам работать над независимыми компонентами изолированно, при этом организованно отслеживая все изменения.
Возможность создавать и просматривать запросы на слияние, проверять изменения в битовой дорожке и беспрепятственно экспортировать изменения в bit.cloud гарантирует, что основная ветвь всегда представляет текущее состояние проекта. Каждое изменение методично отслеживается, изменения версий автоматизированы, а зависимости и конфигурации эффективно управляются.
Этот рабочий процесс не только оптимизирует процесс разработки, но и способствует созданию прозрачной среды для совместной работы внутри команды. Он также служит ступенькой на пути к полностью распределенному рабочему процессу, предлагая постепенный путь миграции, не перегружая разработчиков.
Однако представьте, что вы делаете еще один шаг. Представьте, что вы изменили небольшой компонент, например кнопку, и все потребители этого компонента в вашей организации или даже по всему миру мгновенно получили это обновление. Это то, что предлагает полностью распределенный рабочий процесс, такой как Ripple CI.
Ripple CI позволяет мгновенно распространять обновления по проектам, избавляя от необходимости вручную обновлять каждый потребляющий проект. Это похоже на волновой эффект, который начинается с одной точки (модифицированного компонента) и распространяется на всех потребителей.
В этом сообщении блога показано, как вы можете извлечь выгоду из рабочего процесса на основе Git и Bit. Но потенциал использования Bit в полностью распределенном рабочем процессе, таком как Ripple CI, огромен. Это может переопределить способ совместной работы команд над программными проектами. Это стоит учитывать при изучении новых способов повышения эффективности и производительности вашей команды.
Как всегда, мы рекомендуем вам поэкспериментировать с описанными здесь практиками и воспользоваться преимуществами, которые это сочетание инструментов и рабочего процесса привносит в процесс разработки программного обеспечения.
И так, чего же ты ждешь? Погружайтесь и исследуйте возможности!
