How to Standardize Mobile Release Permissions and Approval with a Unified Platform

Background

Youzan Mobile maintains several independent platforms (Weex release, mobile configuration center, app distribution, hot‑fix). Each platform requires a release workflow that includes standardized approval, and building a separate approval system for every platform would duplicate effort.

Standard Release Approval Process

The typical workflow consists of three steps:

Applicant submits a release request.

Responsible approver reviews and approves (or rejects) the request.

Applicant proceeds with the actual release if approved.

Roles are distinguished by permissions (module owner, developer, operations, tester, etc.).

Permission Model

Permission is defined by the relationship between a user and a module. The module identifier is provided by each side platform, while the user identifier is supplied by the unified authentication service (CAS). By sending moduleId and userId to the unified platform, the side platform can retrieve the user’s role and enforce the appropriate actions.

Approval Model

An approval record contains four elements: applicant, approval content, approver, and approval status. Although the content varies across platforms, it can be abstracted into two fields:

approvalId – a unique identifier for the approval record.

detailUrl – a URL that points to the full approval details on the side platform.

Both fields are supplied by the side platform when creating an approval.

Unified Management Platform Design

The unified platform centralizes permission and approval handling for all side platforms. Both the side platforms and the unified platform rely on CAS for user authentication, ensuring consistent permission resolution.

Interaction Between Side Platforms and the Unified Platform

The interaction is defined by four standard operations, each exposed as a Dubbo RPC interface.

1. Add Module

A module is the smallest configurable permission unit (e.g., a Weex module or a hot‑fix app). When a side platform registers a module, it sends the following data to the unified platform: platformId – identifier of the side platform. moduleId – unique identifier of the module. moduleName – human‑readable name for display.

The unified platform stores this information for later permission checks.

2. Get Permission

Permissions are managed centrally. Module owners can edit permission entries; other users request access. To obtain a permission set, the side platform calls the unified service with platformId, moduleId, and userId. The service returns the role (e.g., owner, developer, tester) associated with that user for the specified module.

3. Submit Release Order

Side platforms submit a release order that contains configuration‑type data. The payload differs per platform but follows a common structure:

Common fields : platform, environment, rules, description, and a detailUrl that points to the platform‑specific release detail page.

Examples:

When submitting, the side platform provides a composite identifier (platform + module + releaseId) and the detailUrl. The unified platform creates an approval record containing the identifier, status (initially “pending”), applicant, and the detailUrl.

4. Get Release Order Status

The side platform queries the unified platform for the current approval status of a given release order. Possible statuses are:

Pending – awaiting approver action.

Approved – release may proceed.

Rejected – release must be aborted or revised.

Based on the returned status, the side platform decides whether to continue with the release.

Optimization Improvements

Permission Request Entry

To reduce the time module owners spend manually adding permissions, a permission‑request entry is added both in the unified platform and exposed on each side platform. The entry accepts platform, module, and role parameters, redirects the user to the unified platform’s permission‑request page, and sends a real‑time notification (e.g., enterprise WeChat) to the module owner for quick approval.

Real‑Time Approval Notifications

When an applicant creates a release request, the approver receives an instant notification. After the approver makes a decision, the applicant is also notified immediately, eliminating manual follow‑up.

Configurable Approval Bypass

For special modules (e.g., test modules) or environments (Daily, QA, Pre, Prod), approval can be disabled via a configuration flag. This avoids unnecessary approvals during frequent testing cycles.

Summary

All permission and approval operations are centralized in the unified management platform, while module registration, release submission, and rollback remain in the respective side platforms. The platform exposes four Dubbo‑based standard interfaces:

Interface 1: Create module in the unified platform.

Interface 2: Retrieve a user’s role for a specific module.

Interface 3: Create or withdraw an approval order.

Interface 4: Query the progress/status of an approval order.

The backend UI of the unified platform provides permission‑management and approval‑management screens, enabling consistent governance across all side platforms and simplifying future extensions as new platforms or role types are added.