Android module library automatic publishing system based on Jenkins

Abstract

The invention discloses a Jenkins-based Android module library automatic release system, which comprises a module library code management unit, a version control unit, a Maven release unit and a process management unit, and is characterized in that the module library code management unit, the version control unit and the Maven release unit are sequentially connected from front to back and are all connected with the process management unit; the module library code management unit is used for pulling and loading a code of a specified module from a Git warehouse and analyzing a dependency relationship; the version control unit is used for reading version configuration information before packaging, checking whether a version exists or not, and managing automatic marking and rollback of a version number through a Git label; the Maven publishing unit is used for compiling the module into an AAR file and publishing the AAR file to a Maven warehouse; according to the method, automation of the Android module library publishing process is efficiently and accurately realized through the module library code management unit, the version control unit, the Maven publishing unit and the process management unit.

Description

Technical Field

[0001] The present invention relates to the technical field of Android development, and in particular to an Android module library automatic publishing system based on Jenkins. Background Art

[0002] During Android application development, as the project scale expands, the development team typically modularizes functions to improve code reusability and maintainability. These functional modules are usually maintained as modules, packaged and distributed in AAR format. However, existing Android module release solutions have the following problems: 1. Development and debugging lib projects need to be manually imported into app projects, which is cumbersome and error-prone, affecting the efficiency of multiple people assisting in development; 2. Developers need to manually perform multiple steps such as code pulling, version management, packaging, and release, which is error-prone and inefficient; 3. Due to the lack of a unified version management mechanism, version conflicts or version number confusion are prone to occur; in addition, the lack of a unified release status feedback mechanism makes it difficult for team members to keep abreast of the progress and results of module releases. Summary of the Invention

[0003] The present invention aims to provide an automated Android module library publishing system based on Jenkins. This system efficiently and accurately automates the Android module library publishing process through a module library code management unit, a version control unit, a Maven publishing unit, and a process management unit, significantly improving the work efficiency of the development team and reducing the risk of human error.

[0004] The technical solution of the present invention is: an Android module library automatic publishing system based on Jenkins, comprising a module library code management unit, a version control unit, a Maven publishing unit and a process management unit, wherein the module library code management unit, the version control unit and the Maven publishing unit are connected in sequence and are all connected to the process management unit; the module library code management unit is used to pull and load the code of a specified module from a Git warehouse and parse the dependency relationship; the version control unit is used to read version configuration information and verify whether the version already exists before packaging, and manage the automatic marking and rollback of the version number through Git tags; the Maven publishing unit is used to compile the module into an AAR file and publish the file to the Maven warehouse; and the process management unit controls the publishing process of the module library code management unit, the version control unit and the Maven publishing unit through scripts.

[0005] In the above-mentioned Jenkins-based Android module library automatic publishing system, the module library code management unit includes two parts: a Gradle plug-in and a configuration file;

[0006] The Gradle plug-in includes a Settings sub-plug-in and a Project sub-plug-in. The Settings sub-plug-in injects the path of the target module by modifying the setting.gradle file of the host project to achieve module pull loading. The Project sub-plug-in is used to switch between remote dependencies and local dependencies during the build process through the dependencySubstitution method.

[0007] The configuration files include module_map.json and module_map.properties. Module_map.json defines the mapping relationship between remote dependencies and local dependencies. Module_map.properties stores the version number and unique representation of the module for reading during the build.

[0008] In the aforementioned Jenkins-based Android module library automated publishing system, the Settings sub-plugin uses Jenkins dynamic configuration parameters to implement module pull and loading.

[0009] In the aforementioned Jenkins-based Android module library automated release system, the version control unit verifies the module version number by reading the MODULE_VERSION field from the target module's maven.properties file to obtain the version number, and verifies whether the current version exists based on the Git tag;

[0010] The automatic marking of the version control unit is to generate a Git tag with the module ID and module version number after the release is completed, and push it to the Git repository; the rollback of the version control unit is to delete the invalid Git tag generated locally when the build fails, and synchronously delete the remote Git tag.

[0011] In the aforementioned Jenkins-based Android module library automated publishing system, the Maven publishing unit includes a Maven publishing script integrated into the host project. The Maven publishing script is used to read the module version number and configure the Maven warehouse address and authentication information to achieve automatic uploading of AAR files.

[0012] In the aforementioned Jenkins-based Android module library automated release system, the process management unit controls the release process through Pipeline logic definition, and the specific process includes Preparation stage, Verify stage and Publish stage in sequence; the Preparation stage pulls the scaffolding project code and clones the Git repository of the target module according to the parameters; the Verify stage performs version verification through the version control unit, and generates a pre-release tag after verification; the Publish stage calls the module library code management unit to build and upload AAR, and triggers version rollback if it fails.

[0013] The aforementioned Jenkins-based Android module library automated publishing system also includes a DingTalk robot connected to the Maven publishing unit and the process management unit, which is used to push notification messages containing build logs and version information when the publishing succeeds or fails.

[0014] The aforementioned Jenkins-based Android module library automated publishing system also includes a scaffolding project connected to the module library code management unit and the Maven publishing unit, which is used to provide a unified build environment, dynamically integrate the target module into the host project, and configure the Gradle version and Android SDK dependencies.

[0015] Jenkins Pipeline is a powerful, open-source tool that allows you to create and publish code in a unified way, without any dependencies between modules. It is a very powerful tool that allows you to create and publish code in a unified way, without any dependencies between modules. It is a very powerful tool that allows you to create and publish code in a unified way, without any dependencies between modules. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a system structure diagram of the present invention;

[0017] Figure 2 This is a logical flow chart of the process management unit of the present invention;

[0018] Figure 3 This is the main engineering structure diagram after the transformation of the present invention. DETAILED DESCRIPTION

[0019] The present invention will be further described below with reference to the accompanying drawings and examples, but they are not intended to limit the present invention.

[0020] Example: An automated publishing system for Android module libraries based on Jenkins, as shown in the attached Figure 1 As shown, it includes a module library code management unit, a version control unit, a Maven publishing unit and a process management unit. The module library code management unit, the version control unit and the Maven publishing unit are connected in sequence and are all connected to the process management unit; the module library code management unit is used to pull and load the code of the specified module from the Git warehouse and parse the dependency relationship; the version control unit is used to read the version configuration information and verify whether the version already exists before packaging, and manage the automatic marking and rollback of the version number through Git tags; the Maven publishing unit is used to compile the module into an AAR file and publish it to the Maven warehouse; the process management unit controls the publishing process of the module library code management unit, the version control unit and the Maven publishing unit through scripts.

[0021] The module library code management unit includes a Gradle plug-in and a configuration file. The Gradle plug-in is a QDepend plug-in, which is used to manage the dependencies of the lib project; it includes two parts: the Settings sub-plug-in (QDependModule) and the Project sub-plug-in (QDependBuild).

[0022] The Settings sub-plugin dynamically modifies the setting.gradle file of the host project to inject the path of the target lib module, adds dependent modules through the include statement, and adds all libs that need to be built as Jenkins configuration parameters to the file, thereby realizing the dynamic dependency function. The host project automatically identifies the local module path and dynamically determines the lib project that needs to be built; the Project plug-in is responsible for handling dependency relationships, and its core code uses the dependencySubstitution method to dynamically switch module and project dependencies, solving the problems of multi-project nesting and transitive dependencies.

[0023] The configuration files include module_map.json and module_map.properties. Module_map.json defines the mapping relationship between remote dependencies and local dependencies (local lib modules). Figure 2As shown in the figure, the lib project is streamlined and adjusted. The redundant code in the Android Studio default template is removed, and only the lib code is retained. The maven.properties file is added to manage the version number. This file provides the MODULE_VERSION field, which supports manual version changes or incremental version updates through scripts. During the build process, the data in the MODULE_VERSION field is read and passed as the version number parameter to the Maven release script, thus achieving unified version management. The module_map.properties file is used to store the module version number and unique representation, which is read during the build.

[0024] The version control unit verifies the module version number by reading the MODULE_VERSION field from the maven.properties file of the target module, and verifies whether the current version exists based on the Git tag; the version control unit automatically marks the module after the release is completed, and pushes it to the Git repository; the version control unit rolls back the module by deleting the invalid Git tag generated locally when the build fails, and synchronously deleting the remote Git tag.

[0025] The Maven publishing unit includes a Maven publishing script integrated into the host project. The Maven script uniformly configures the Maven warehouse address and warehouse key, and dynamically adds the script to the lib through the build.gradle file of the host project to realize the packaging and publishing functions of the module; the Maven script defines functions such as version reading, judging whether it is an official package, and obtaining the Maven remote warehouse URL, and completes the configuration of the publishing task through the afterEvaluate block; in addition, the Maven script also supports judging whether to publish the official package based on the MODULE_VERSION field to ensure the standardization of version management.

[0026] The process management unit uses the Groovy scripting language to write the Pipeline logic definition to control the release process, as shown in the attached Figure 3As shown, the specific process includes the Preparation stage, the Verify stage and the Publish stage in sequence; the Preparation stage pulls the scaffolding project code through Git, realizes code merging through Git Webhook to automatically trigger the Pipeline, and clones the Git repository of the target module according to the parameters; the Verify stage performs version verification through the version control unit, reads the version configuration information and verifies whether the version already exists through the uniqueness of the tag in Git to avoid invalid compilation and repeated release. After successful verification, a new tag is created for subsequent backtracking and version verification; the Publish stage calls the module library code management unit to build and upload AAR, and triggers version rollback if it fails.

[0027] It also includes a DingTalk robot connected to the Maven release unit and process management unit. The DingTalk robot sends notifications through the DingTalk plug-in, providing detailed build logs and error information, making it convenient for the development team to update to the latest version in a timely manner. The DingTalk robot sends different message content when the release succeeds or fails, improving the transparency of team collaboration.

[0028] It also includes a scaffolding project connected to the module library code management unit and the Maven release unit to provide a unified build environment, dynamically integrate the target module into the host project, and uniformly configure the Gradle version and Android SDK dependencies. By calling the scaffolding project, the Jenkins Pipeline logic process can automatically complete the entire process from code pulling to release.

[0029] Through the pipeline logic (Preparation, Verification, and Publish phases) of the process management unit, traditional manual operations (code pulling, version verification, and packaging and publishing) are transformed into automated processes, reducing manual intervention. For example:

[0030] The Preparation phase automatically triggers the build through GitWebhook, eliminating the need for manual click execution.

[0031] During the Publish phase, the Gradle script is called to automatically compile and upload the AAR file, reducing the time required to publish a single module from 30 minutes to less than 5 minutes.

[0032] Effectiveness data: After testing, when a team of 10 people collaborated to release 10 modules, overall efficiency increased by more than 80%, avoiding duplication of work.

[0033] The module library code management unit dynamically injects module paths and switches dependency modes through the Gradle plug-in (Settings sub-plug-in + Project sub-plug-in), replacing the traditional manual modification of setting.gradle and build.gradle. For example:

[0034] The Settings sub-plugin dynamically modifies the includeBuild configuration of setting.gradle through Jenkins parameters and automatically identifies the local module path;

[0035] The Project sub-plugin uses dependencySubstitution to implement one-click switching between remote dependencies and local modules, eliminating the need to manually annotate Maven dependencies during the debugging phase.

[0036] Effect: The time developers spend configuring module dependencies is reduced from 20 minutes to 0 minutes each time, completely resolving the problem of multi-project nesting conflicts.

[0037] The version control unit reads MODULE_VERSION from maven.properties and checks whether the version already exists based on the Git tag; for example:

[0038] When releasing drinkwater_common v1.0.0, first execute gittag -l to check whether the tag exists. If it exists, the release is terminated and an error is reported.

[0039] Avoid Maven repository overlay issues caused by duplicate version numbers and ensure that each released version is unique and traceable.

[0040] Effect: The version conflict rate has been reduced from 20% in traditional solutions to 0%, improving the standardization of version management.

[0041] After the version control unit is successfully released, it automatically generates a Git tag with the module ID and version number (such as drinkwater_common_v1.0.0) and pushes it to the remote repository to make version changes traceable;

[0042] Automatically delete local and remote invalid tags when a build fails to avoid dirty data remaining. For example:

[0043] Effect: The time required for version rollback operations is shortened from 15 minutes to automatic triggering, reducing manual troubleshooting costs.

[0044] Maven release units automatically read the maven.properties version number and configure warehouse authentication information through scripts to avoid manual filling errors. For example:

[0045] The release script dynamically obtains the version number from the MODULE_VERSION field to eliminate the problem of "version number and tag inconsistency" caused by manual input;

[0046] The repository address and username / password are managed through Jenkins credentials, and sensitive information is not exposed in the code.

[0047] Results: Release failure rate due to configuration errors dropped from 15% to less than 1%.

[0048] When publishing succeeds / failures, the DingTalk robot automatically pushes notifications containing version information and build log links.

[0049] Results: The delay for team members to obtain release status was shortened from 30 minutes of manual query to real-time push notifications, and collaboration efficiency increased by 60%.

[0050] In Pipeline, use archiveArtifacts to preserve key files such as maven.properties, and include log links in DingTalk notifications to facilitate problem review.

[0051] Effect: Version tracing time is shortened from 1 hour to 5 minutes, and troubleshooting efficiency is significantly improved.

[0052] In summary, the various units of the present invention realize full-process automation through close collaboration. The module library code management unit uses the Gradle plug-in to dynamically inject module paths and switch dependency modes, and combines configuration files to accurately map remote and local dependencies, completely solving the problems of multi-project nesting conflicts and manual configuration. The version control unit realizes automatic verification, marking and rollback of version numbers based on Git tags, ensuring version uniqueness and traceability, and avoiding version confusion from the root. The Maven publishing unit automatically reads version information and configures warehouse authentication through integrated scripts to achieve seamless connection from compilation to upload of AAR files, eliminating configuration errors caused by manual operations. The process management unit uses Pipeline logic to connect the Preparation, Verify, and Publish tasks in series, and combines the GitWebhook trigger mechanism and abnormal rollback strategy to build an end-to-end unmanned publishing link. In addition, the DingTalk robot pushes notification messages containing logs and version information in real time, significantly improving team collaboration efficiency. The scaffolding project effectively solves the compatibility issues between modules by unifying the Gradle version, AndroidSDK dependency and build environment.

Claims

1. An automated publishing system for Android module libraries based on Jenkins, characterized by: It includes a module library code management unit, a version control unit, a Maven publishing unit and a process management unit. The module library code management unit, the version control unit and the Maven publishing unit are connected in sequence and are all connected to the process management unit. The module library code management unit is used to pull and load the code of the specified module from the Git warehouse and parse the dependency relationship. The version control unit is used to read the version configuration information and verify whether the version exists before packaging, and manage the automatic marking and rollback of the version number through Git tags. The Maven publishing unit is used to compile the module into an AAR file and publish it to the Maven warehouse. The process management unit controls the publishing process of the module library code management unit, the version control unit and the Maven publishing unit through scripts.

2. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: The module library code management unit includes two parts: Gradle plug-in and configuration file; The Gradle plug-in includes a Settings sub-plug-in and a Project sub-plug-in. The Settings sub-plug-in injects the path of the target module by modifying the setting.gradle file of the host project to achieve module pull loading. The Project sub-plug-in is used to switch between remote dependencies and local dependencies during the build process through the dependencySubstitution method. The configuration files include module_map.json and module_map.properties. Module_map.json defines the mapping relationship between remote dependencies and local dependencies. Module_map.properties stores the version number and unique representation of the module for reading during the build.

3. The Jenkins-based Android module library automated publishing system according to claim 2, characterized in that: The Settings sub-plugin uses Jenkins dynamic configuration parameters to pull and load modules.

4. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: The verification module version number of the version control unit reads the MODULE_VERSION field from the maven.properties file of the target module to obtain the version number, and verifies whether the current version exists based on the Git tag; The automatic tagging of the version control unit is to generate a Git tag with the module ID and module version number after the release is completed, and push it to the Git repository; The rollback of the version control unit is to delete the invalid Git tags generated locally when the build fails, and simultaneously delete the remote Git tags.

5. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: The Maven publishing unit includes a Maven publishing script integrated into the host project. The Maven publishing script is used to read the module version number and configure the Maven warehouse address and authentication information to achieve automatic uploading of the AAR file.

6. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: The process management unit controls the release process through the Pipeline logic definition. The specific process includes the Preparation stage, the Verify stage and the Publish stage in sequence; the Preparation stage pulls the scaffolding project code and clones the Git repository of the target module according to the parameters; the Verify stage performs version verification through the version control unit, and generates a pre-release tag after verification; the Publish stage calls the module library code management unit to build and upload AAR, and triggers version rollback if failure.

7. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: It also includes a DingTalk robot connected to the Maven release unit and process management unit, which is used to push notification messages containing build logs and version information when the release succeeds or fails.

8. The Jenkins-based Android module library automated publishing system according to claim 1, characterized in that: It also includes a scaffolding project connected to the module library code management unit and the Maven release unit to provide a unified build environment, dynamically integrate the target module into the host project, and configure the Gradle version and Android SDK dependencies.

Images