Automated Continuous Integration Framework for Xianyu iOS Multi‑Bundle Projects

Background

Agile development at Xianyu uses a two‑week sprint with many parallel tasks. Manual integration and testing cause high communication cost and error probability.

To improve efficiency, a continuous integration solution based on SpringBoot and Vue was built to link requirements, code and tests automatically.

1. Data Model

1.1 Lane Model

Describes the Git flow used: develop branch, feature branches, release branch, etc.

In Xianyu iOS project there are 8 sub‑modules plus a main project, each with its own Git repository.

1.2 Linking Requirements and Code

Requirements are managed in Aone; the requirement ID is added to Git commit messages. Two ways: branch naming convention or explicit ID in commit message.

Example commit:

fix ##12345

1.3 Linking Requirements and Integration Items

Each requirement is associated with a “Mojianlun” (build platform) project. The database stores requirement‑code‑build mappings.

2. Automatic Integration Framework

2.1 Platform Architecture

The platform is built with SpringBoot (backend) and Vue (frontend) using RESTful APIs. It integrates Gitlab, Mojianlun, Aone and Jenkins as data sources.

Data layer, business layer, API layer and UI layer are separated.

2.2 Event‑Driven

Gitlab webhook events (push, merge request) are listened to. Example webhook controller:

@RequestMapping(value = "webhook", method = RequestMethod.POST)
public void webhooks(@RequestBody String payload) {
    logger.info(payload);
    GitlabHookEvent event = JSON.parseObject(payload, GitlabHookEvent.class);
    eventService.dispatchGitlabEvent(event);
}

2.3 Continuous Packaging

Build tasks are created per module. Before building, the system checks whether a module needs rebuilding based on the last successful build time.

private void triggerMTLBuildInterval(FMPackageTask task, MTLProduct product, int mtlProjectId) {
    // analyze modules, decide rebuild, cancel running builds, start new builds...
}

3. Integration Testing

After a build finishes, CI tests are triggered. The change scope is calculated from commits to determine affected pages and authors.

public FMCITriggerParam getChangeScope(int projectId, String branch, ArrayList<GitlabCommit> commits) {
    // obtain repo, platform, authors, changed files, pages, trigger types, assemble FMCITriggerParam
    return change;
}

4. Result Statistics

Weekly statistics show the number of integrations per branch (develop vs feature) and trigger type (scheduled, push).

5. Pitfalls

5.1 Axios Network Requests

Cross‑origin issues solved by proxy configuration; 302 redirects are converted to 200 responses on the server and handled in Axios interceptors.

axios.interceptors.response.use(response => {
    if (response.status === 200 && response.data.hasError) {
        window.location = "<redirect URL>";
    }
    return response;
}, error => Promise.reject(error));

5.2 Integration Rate Limiting

Two queues (running and waiting) are used to limit concurrent builds and deduplicate tasks.

6. Conclusion

The described CI pipeline links requirement → code → build, enabling metrics such as commit count, build count and bug count per requirement, and supports further optimization of the mobile development process.