Integrating Flutter Projects into Beetle: Branch Types, Release Workflow, and Component Management

ZhiZhuan's client app adopts a mixed Flutter‑native development model where each app corresponds to a single module project and multiple plugin projects; the module aggregates plugins to produce artifacts usable by the native side.

During app releases, many projects with complex dependency relationships are involved, and previous documentation‑based guidelines proved insufficient for enforcing consistent processes.

To unify component development, manage dependencies, and streamline releases, the Flutter projects were brought under Beetle, which now governs the relationship between the app and its Flutter components.

Beetle Branch Types

master – the always‑up‑to‑date main branch (no direct commits allowed).

feature – for daily feature development.

bugfix – for fixing defects.

release – for product releases and iterations; other branches are merged into it before QA testing.

hotfix – for post‑release urgent fixes that can be deployed immediately.

sub_feature – a child branch created from the release panel, deployable to sandbox but not to production.

The release‑branch workflow is illustrated in the following diagram:

Flutter Project Development Flow

Because a Flutter build produces a component rather than a full app, the release version is considered production‑ready and can be merged into master directly. The release‑branch flow is shown below:

Create a release‑type branch (linked to a requirement).

Provide an entry point for pulling sub‑branches within the release branch.

Require checks (e.g., static code analysis) before a sub‑branch can be merged.

Only the release branch can be packaged and deployed; after successful packaging it may be merged into master.

Submitting a release for deployment locks the branch, preventing further compilation, packaging, or merging of other branches.

Once the release meets the launch criteria, it is deployed and the release code is merged back to master, with sub‑branches marked as released.

Flutter Component Management

When creating a new app‑version branch, related module and plugin branches are generated together to avoid missing branches.

Bidirectional management and binding of app ↔ module ↔ plugin branches make the required components for a release clearly visible (see component‑dependency diagram).

When a specific app side goes live, its associated module and plugin branches are automatically released, preventing missed merges.

Summary and Outlook

Beetle’s business model and technical capabilities enable rapid integration of Flutter projects, bringing component‑branch development into the app release cycle and shortening delivery time while improving release quality. Future work includes adding CI checks for Flutter quality, implementing component release history queries, and strengthening app‑component linkage through enhanced packaging notifications.