Code updating method in parallel development, electronic device and product

Abstract

This disclosure provides a code update method, electronic device, and product for parallel development. The method includes: determining at least one requirement identifier based on at least one code update requirement; obtaining a first main code and its corresponding first code version number; generating at least one branch version number based on the first code version number and the at least one requirement identifier; obtaining at least one update code; determining at least one update branch version number based on the at least one branch version number; and determining at least one second main code and its corresponding at least one second code version number based on the at least one update code and the at least one update branch version number. This embodiment distinguishes different code update requirements through requirement identifiers, making update branch version numbers independent of each other and avoiding the problem of overwriting between second main codes due to code version number conflicts.

Description

Technical Field

[0001] This disclosure relates to Internet technology, and in particular to a method for updating code in parallel development, electronic devices, and products. Background Technology

[0002] In large teams or complex projects, parallel development is the norm. Multiple functional teams or developers may work on the same module simultaneously, or on multiple interdependent modules. Each developer or team, when developing new features or fixing bugs, typically needs to iteratively update the version number in the project object model file of their assigned module and deploy the components containing the new features to a shared repository during development. This allows other teams or integration environments that depend on that module to access the latest developments for integration testing and debugging. In parallel development scenarios, different teams and developers are highly likely to choose the same or semantically overlapping version numbers, leading to version number conflicts. Summary of the Invention

[0003] To address the aforementioned technical problems, this disclosure is proposed. Embodiments of this disclosure provide a code update method, electronic device, and product for parallel development.

[0004] According to one aspect of the present disclosure, a method for updating code in parallel development is provided, comprising: Based on at least one code update requirement, at least one requirement identifier is determined; each requirement identifier is used to uniquely identify the corresponding code update requirement. Obtain the first main code and its corresponding first code version number; the first code is the update object corresponding to the at least one code update requirement; The first code version number is combined with the at least one requirement identifier to generate at least one branch version number; wherein each branch version number corresponds to one requirement identifier; Obtain at least one update code, and determine at least one update branch version number based on the at least one branch version number; the at least one update code is the code obtained by the first main code according to the at least one code update requirement, and the at least one update code corresponds one-to-one with the at least one update branch version number; Based on the at least one update code and the at least one update branch version number, at least one second main code and its corresponding at least one second code version number are determined.

[0005] Optionally, combining the first code version number with the at least one requirement identifier to generate at least one branch version number includes: Based on the first code version number, a preset version number template is determined, wherein the preset position of the preset version number template includes a placeholder; Write the at least one requirement identifier into the placeholder in the preset version number template to obtain the corresponding at least one branch version number.

[0006] Optionally, obtaining at least one update code and determining at least one update branch version number based on the at least one branch version number includes: At least one code update branch is determined based on the at least one branch version number; each code update branch corresponds to one code update requirement. In each code update branch, the first main code is updated according to the corresponding code update requirements, and the branch version number is updated to obtain the updated code and its corresponding update branch version number.

[0007] Optionally, determining at least one second main code and its corresponding at least one second code version number based on the at least one updated code and the at least one updated branch version number includes: The at least one update code is used as the at least one second main code; Determine at least one output time corresponding to the at least one update branch version number; Sort the version numbers of the at least one update branch according to the at least one output time to obtain a version number sequence; The at least one second code version number is determined according to the version number sequence.

[0008] Optionally, determining the at least one second code version number according to the version number sequence includes: Based on the version number sequence, determine at least one version number increment with different values; The first code version number is incrementally processed based on at least one of the version number increments to obtain the at least one second code version number.

[0009] Optionally, it also includes: The at least one second main code is merged to obtain the third main code; The third code version number corresponding to the third main code is determined based on the largest second code version number among the at least one second code version number.

[0010] Optionally, it also includes: Store the at least one second main code and / or the third main code in the code repository, and create an index for the at least one second main code based on the at least one second code version number, and / or create an index for the third main code based on the third code version number.

[0011] Optionally, obtaining the first main code and its corresponding first code version number includes: The most recently updated code is obtained from the code repository as the first main code, and the version number corresponding to the first main code is obtained as the first code version number.

[0012] Optionally, determining at least one requirement identifier based on at least one code update requirement includes: Perform hash processing on each of the at least one code update requirement to obtain the at least one requirement identifier.

[0013] Optionally, determining at least one requirement identifier based on at least one code update requirement includes: Using the primary key auto-incrementing technique in the database, at least one requirement identifier is determined based on the at least one code update requirement.

[0014] According to another aspect of the embodiments of this disclosure, a code update apparatus for parallel development is provided, comprising: An identifier determination module is used to determine at least one requirement identifier based on at least one code update requirement; each requirement identifier is used to uniquely identify the corresponding code update requirement; The main code acquisition module is used to acquire the first main code and its corresponding first code version number; the first code is the update object corresponding to the at least one code update requirement. A branch version module is used to combine the first code version number with the at least one requirement identifier to generate at least one branch version number; wherein each branch version number corresponds to one requirement identifier; The branch code update module is used to obtain at least one update code and determine at least one update branch version number based on the at least one branch version number; the at least one update code is the code obtained by the first main code according to the at least one code update requirement, and the at least one update code corresponds one-to-one with the at least one update branch version number; The main code update module is used to determine at least one second main code and its corresponding at least one second code version number based on the at least one update code and the at least one update branch version number.

[0015] Optionally, the branch version module is specifically used to determine a preset version number template based on the first code version number, wherein the preset position of the preset version number template includes a placeholder; and to write the at least one requirement identifier into the placeholder in the preset version number template to obtain the corresponding at least one branch version number.

[0016] Optionally, the branch code update module is specifically used to determine at least one code update branch based on the at least one branch version number; each code update branch corresponds to one code update requirement; in each code update branch, the first main code is updated according to the corresponding code update requirement, and the branch version number is updated to obtain the updated code and its corresponding update branch version number.

[0017] Optionally, the main code update module is specifically used to: use the at least one update code as the at least one second main code; determine at least one output time corresponding to the at least one update branch version number; sort the at least one update branch version number according to the at least one output time to obtain a version number sequence; and determine the at least one second code version number according to the version number sequence.

[0018] Optionally, when the main code update module determines the at least one second code version number according to the version number sequence, it is used to determine at least one version number increment with different values ​​according to the version number sequence; and to perform incremental processing on the first code version number based on the at least one version number increment to obtain the at least one second code version number.

[0019] Optionally, the device further includes: The code merging module is used to perform merging processing on the at least one second main code to obtain a third main code; and to determine the third code version number corresponding to the third main code based on the largest second code version number among the at least one second code version numbers.

[0020] Optionally, the device further includes: A code storage module is used to store the at least one second main code and / or the third main code in a code repository, and to create an index for the at least one second main code based on the at least one second code version number, and / or to create an index for the third main code based on the third code version number.

[0021] Optionally, the main code acquisition module is specifically used to acquire the most recently updated code from the code repository as the first main code, and to obtain the version number corresponding to the first main code as the first code version number.

[0022] Optionally, the identifier determination module is specifically used to perform hash processing on the at least one code update requirement to obtain the at least one requirement identifier.

[0023] Optionally, the identifier determination module is specifically used to determine at least one requirement identifier based on the at least one code update requirement by utilizing the primary key auto-increment technology in the database.

[0024] According to another aspect of the present disclosure, an electronic device is provided, comprising: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, and when the computer program product is executed, to implement the code update method in parallel development as described in any of the above embodiments.

[0025] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores computer program instructions thereon, characterized in that, when the computer program instructions are executed by a processor, they implement the code update method in parallel development described in any of the above embodiments.

[0026] According to another aspect of the present disclosure, a computer program product is provided, including computer program instructions, characterized in that, when executed by a processor, the computer program instructions implement the code update method in parallel development described in any of the above embodiments.

[0027] Based on the code update method, apparatus, electronic device, medium, and product in parallel development provided in the above embodiments of this disclosure, at least one requirement identifier is determined according to at least one code update requirement; each requirement identifier is used to uniquely identify the corresponding code update requirement; a first main code and its corresponding first code version number are obtained; at least one branch version number is generated based on the first code version number and the at least one requirement identifier; at least one update code is obtained, and at least one update branch version number is determined based on the at least one branch version number; at least one second main code and its corresponding at least one second code version number are determined based on the at least one update code and the at least one update branch version number. In this embodiment, different code update requirements are distinguished by requirement identifiers, and branch version numbers for different code update requirements are generated. The first main code is updated based on at least one branch version number to obtain at least one second main code and a second code version number updated for different code update requirements. Since the second code version number is determined by the update branch version number, and the update branch version numbers are independent of each other, there is no conflict between at least one second code version number, and the problem of overwriting between second main codes due to code version number conflicts is avoided.

[0028] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0029] The accompanying drawings, which form part of this specification, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0030] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein: Figure 1 This is a flowchart illustrating a code update method in parallel development provided by an exemplary embodiment of this disclosure; Figure 2 This is a flowchart illustrating the process of determining a branch version number in an optional embodiment of this disclosure; Figure 3 This is a schematic diagram of the parallel code update process in an optional embodiment of the method provided in this disclosure; Figure 4 This is a schematic diagram of the version number update process in an optional embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of a code update apparatus in parallel development provided in an exemplary embodiment of the present disclosure; Figure 6 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0031] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0032] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0033] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0034] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0035] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0036] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship. The data referred to in this disclosure can include unstructured data such as text, images, and videos, as well as structured data.

[0037] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0038] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0039] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0040] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0041] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0042] The embodiments disclosed herein can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0043] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0044] Application Overview In modern Java-based backend service development practices, Apache Maven has become the de facto standard for build and dependency management. Apache Maven is a project management and build automation tool based on the Project Object Model (POM). Its core configuration file, pom.xml, not only defines the project structure and build process, but more importantly, it manages the third-party libraries (JAR packages) that the project depends on and their versions.

[0045] Development teams typically modularize core functionalities into independent Maven modules and deploy these modules' artifacts (usually JAR files) to a shared Maven repository (such as Nexus, Artifactory, etc.). Other projects or services reuse functionality by declaring dependencies on these artifacts and their specific versions in their own POM files. Ultimately, this functionality is often exposed to internal or external callers as APIs (such as RESTful APIs, gRPC services, etc.). This modular architecture promotes code reuse and system decoupling.

[0046] In realizing this disclosure, the inventors discovered that in a serial development model, version iteration is relatively simple: after the previous version is released, the next developer modifies the latest version and explicitly increments the version number in the POM (e.g., from 1.2.0 to 1.2.1 or 1.3.0), and then deploys the new version. This linear process effectively avoids version conflicts. However, in a large-scale parallel development environment, the above version management method faces serious challenges, with at least the following problems: 1. Risk of version number conflicts: When multiple developers or teams work in parallel on different branches (such as feature branches) of the same module (or different modules but sharing dependencies), they all need to independently modify the version number in the module's POM file to identify their development line. Due to the lack of effective coordination mechanisms or automated tools, developers are highly likely to choose the same or semantically overlapping version number (for example, two different feature branches both try to upgrade the version number from 1.2.0-SNAPSHOT to 1.3.0-SNAPSHOT).

[0047] 2. Shared Repository Overwriting and Pollution: When using SNAPSHOT versions (a common practice during development), shared repositories are typically configured to allow overwriting of SNAPSHOT artifacts with the same name. When two teams developing in parallel deploy their artifacts to the repository with the same version number (e.g., 1.3.0-SNAPSHOT), the later-deployed artifact will overwrite the earlier-deployed artifact. A SNAPSHOT version is a special version identifier used to mark project versions that are still under development and not yet stable. It is mainly used for team collaboration or continuous development phases, allowing developers to quickly obtain and test the latest iterations of the project.

[0048] 3. Release version conflicts: Even when preparing for a formal release (using a non-SNAPSHOT version, such as 1.3.0), if multiple branches independently decide to use the same release version number, the earlier released version will occupy that version number. Teams releasing later will either be forced to change the version number (potentially disrupting version planning) or forcibly overwrite it, causing release process blockages and chaos.

[0049] Exemplary methods Figure 1 This is a flowchart illustrating a code update method in parallel development provided by an exemplary embodiment of this disclosure. This embodiment can be applied to electronic devices, such as... Figure 1 As shown, it includes the following steps: Step 102: Determine at least one requirement identifier based on at least one code update requirement.

[0050] Each requirement identifier is used to uniquely identify the corresponding code update requirement.

[0051] Optionally, code update requests can be for developing new features, fixing bugs, or other needs, such as feature / REQ-1234-add-payment, bugfix / REQ-5678-npe-exception, etc. Optionally, a corresponding branch is created for each code update request. The branch name or its associated metadata (such as Git branch attributes, commit message tags, etc.) must explicitly contain or be associated with a globally unique request identifier (i.e., "request ID"). In this embodiment, code update requests are uniquely identified using the request identifier. This embodiment can obtain the corresponding request identifier based on the processed code update request, or it can determine the request identifiers for different code update requests according to a certain rule, as long as each request identifier uniquely identifies one code update request.

[0052] Step 104: Obtain the first main code and its corresponding first code version number.

[0053] The first code is the update object corresponding to at least one code update requirement.

[0054] In one embodiment, the first main code is the latest version (latest update time) of the code in the code library. The code library stores multiple versions of the main code (a new version of the main code is generated each time it is updated according to the code update requirements and stored in the code library). Each version of the code stores a corresponding code version number. After obtaining the first main code, the corresponding first code version number can be obtained. The code version number usually has a fixed format, such as 1.2.0, 2.0.0, etc.

[0055] Step 106: Combine the first code version number with at least one requirement identifier to generate at least one branch version number.

[0056] Each branch version number corresponds to a code update requirement, which is a requirement identifier that serves as the update object for the at least one code update requirement.

[0057] In this embodiment, the first code version number is combined with each of the at least one requirement identifier to determine at least one branch version number corresponding to at least one code update requirement. Each branch version number corresponds to one code update requirement. Optionally, a branch version number format is preset, and the first code version number and the requirement identifier are written according to the format to obtain the corresponding branch version number. Alternatively, the first code version number and the requirement identifier are processed (e.g., merged, superimposed, etc.) to obtain the branch version number.

[0058] Step 108: Obtain at least one updated code and determine at least one updated branch version number based on at least one branch version number.

[0059] Among them, at least one update code is the code obtained by updating the first main code according to at least one code update requirement, and at least one update code corresponds one-to-one with at least one update branch version number.

[0060] In this embodiment, code update requests are processed in parallel. The basis for each code update request is the first main code. Based on the first main code, the first main code is processed according to at least one code update request to obtain at least one updated code. The at least one updated code is independent of each other and exists in different branches. Each updated code corresponds to a unique update branch version number. Different update branch version numbers correspond to different request identifiers. Therefore, different update branch version numbers are different and there will be no conflict between them.

[0061] Step 110: Based on at least one update code and at least one update branch version number, determine at least one second main code and its corresponding at least one second code version number.

[0062] Each secondary main code corresponds to a secondary code version number.

[0063] The at least one update code provided in this embodiment is independent of each other. At least one second main code can be directly obtained based on the at least one update code, or at least one second main code can be obtained after processing the at least one update code (e.g., adding or deleting specific code). The corresponding second code version number is determined for each second main code according to the version number of at least one update branch. The at least one second code version number is independent of each other, which ensures that there will be no version number conflict between the second main codes generated in parallel by different branches. Moreover, the at least one second main code is independent of each other, avoiding the code overwriting problem that may occur when the code is updated in parallel.

[0064] The code update method in parallel development provided in the above embodiments of this disclosure determines at least one requirement identifier based on at least one code update requirement; each requirement identifier is used to uniquely identify the corresponding code update requirement; a first main code and its corresponding first code version number are obtained; at least one branch version number is generated based on the first code version number and the at least one requirement identifier; at least one updated code obtained by updating the first main code is obtained, and at least one updated branch version number is determined based on the at least one branch version number; at least one second main code and its corresponding at least one second code version number are determined based on the at least one updated code and its corresponding at least one updated branch version number. In this embodiment, different code update requirements are distinguished by requirement identifiers, and branch version numbers for different code update requirements are generated. The first main code is updated based on at least one branch version number to obtain at least one second main code and a second code version number updated for different code update requirements. Since the second code version number is determined by the updated branch version number, and the updated branch version numbers are independent of each other, there is no conflict between at least one second code version number, and the problem of overwriting between second main codes due to code version number conflicts is avoided. This embodiment, when applied to parallel development of Java backend services, resolves issues such as Maven POM version number conflicts and the resulting component overriding and build uncertainties.

[0065] In some alternative embodiments, step 102 may include: Perform hashing on at least one code update requirement to obtain at least one requirement identifier.

[0066] Hash processing is a technique that uses a specific algorithm (hash function) to map input data of arbitrary length (such as text, files, binary data, etc.) to a fixed-length output value (hash value, also known as a hash value). Common hash algorithms include MD5, the SHA series, and CRC32. Based on the characteristics of hash processing, by performing hash processing on code update requests, a unique requirement identifier corresponding to that code update request can be obtained.

[0067] In some alternative embodiments, step 102 may further include: Using the primary key auto-incrementing technique in the database, determine at least one requirement identifier based on at least one code update requirement.

[0068] The primary key auto-increment technology in the database can be the MySQL primary key auto-increment technology (commonly known as "Auto-Increment"). This technology is a database design mechanism used to automatically generate unique identifiers, primarily applied to the primary key field of a table. Its core function is that when a new record is inserted, the database system automatically assigns an incrementing unique value to the field, eliminating the need for manual specification and thus simplifying primary key management while ensuring its uniqueness. In this embodiment, under the unified management of at least one code update requirement, the primary key auto-increment technology generates unique requirement identifiers for each requirement, with each identifier identifying the code update requirement.

[0069] In some alternative embodiments, step 104 may include: Retrieve the most recently updated code from the codebase as the primary codebase, and obtain the version number corresponding to the primary codebase as the primary codebase version number.

[0070] In this embodiment, each time updated main code (e.g., second main code) is obtained, the updated main code is stored in the code repository. The code repository stores all versions of main code and sorts them according to their update time. The most recently updated code version can be directly obtained as the first main code based on the sort order, or the code with the largest version number can be obtained as the first main code, and the version number of that largest version number can be obtained as the first code version number. For example, if the code repository stores code with three version numbers: 1.2.0, 1.2.1, and 1.2.2, then the code with version number 1.2.2 will be obtained as the main code. This embodiment addresses parallel code development, where at least one code update requirement is performed on the same version of the main code. Therefore, it is sufficient to obtain the latest version of the main code currently stored.

[0071] like Figure 2 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 106 may include the following steps: Step 1061: Determine the preset version number template based on the first code version number.

[0072] The preset position of the preset version number template includes a placeholder.

[0073] Optionally, the placeholder can be a placeholder of a preset length, the length of which can be determined based on experience or specific application scenarios; for example, 16 bits, 32 bits, etc.; the preset version number template includes at least the first code version number and the placeholder, and may also include SNAPSHOT, indicating that the generated branch version number has an overriding function in the branch; in some optional examples, the preset version number template can be:<version> ${baseVersion+1}-${uniqueId}-SNAPSHOT< / version> .

[0074] Here, ${baseVersion} represents the first code version number (e.g., 1.2.0, or 2.0.0, etc.), and +1 indicates that the code has differed from the main code during the update process, and is distinguished by +1 during branch code updates. The first code version number is uniformly defined and managed in the parent POM or root POM. When a branch is created, the latest version is obtained, and the latest version based on the trunk / main branch is automatically determined and recorded in the branch metadata.

[0075] ${uniqueId} represents a placeholder that will be automatically replaced during the build process with a unique requirement identifier associated with the code update requirement (e.g., REQ-1234, or 5678defa, etc.).

[0076] Step 1062: Write at least one requirement identifier into the placeholder in the preset version number template to obtain at least one corresponding branch version number.

[0077] Optionally, by writing the requirement identifier into the placeholder, the unique branch version number corresponding to the code update requirement can be obtained. When the length of the requirement identifier matches the length of the placeholder, or when the length of the requirement identifier is less than the length of the placeholder, the requirement identifier is directly written into the placeholder. For example, if both are 16 bits, the 16-bit requirement identifier is written into the placeholder. Or, for example, if the requirement identifier is 12 bits and the placeholder is 16 bits, the requirement identifier is directly written into the placeholder to obtain the branch version number. When the length of the requirement identifier is greater than the length of the placeholder, the requirement identifier is truncated, and the requirement identifier corresponding to the length of the truncated placeholder is written into the placeholder. For example, if the requirement identifier is 20 bits and the placeholder is 16 bits, the requirement identifier is truncated, and the 16-bit requirement identifier is written into the placeholder.

[0078] In this embodiment, the format of the branch version number is determined by a preset version number template with a preset format, and placeholders are set in it to facilitate the writing of requirement identifiers corresponding to different code update requirements. Since the requirement identifier associated with each development branch is unique within the project scope, the generated branch version number (such as 1.2.0-REQ-1234-SNAPSHOT) is naturally unique in the shared repository, independent of each other, and there is no problem of mutual conflict.

[0079] like Figure 3 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 108 may include the following steps: Step 1081: Determine at least one code update branch based on at least one branch version number.

[0080] Each code update branch corresponds to one code update requirement.

[0081] Step 1082: In each code update branch, perform update processing on the first main code according to the corresponding code update requirements, and update the branch version number to obtain the updated code and its corresponding update branch version number.

[0082] In this embodiment, different branch version numbers can be used by a team or individual to develop and process the first main code for a code update requirement. A code update branch can be created for each code processing step, and different processing can be performed on the first main code in each code update branch, generating multiple related and independent update codes. This ensures that there are no conflicts or overwriting issues between multiple update codes, improving the efficiency of parallel development. Furthermore, by updating the branch version number separately in the code update branch, the problem of version number confusion in parallel development is overcome. Also, within a single code update branch, the minute version number can be updated multiple times (through setting SNAPSHOT to achieve overwrite updates) without affecting the association between the final second code version number and the first code version number.

[0083] In this embodiment, components generated from different code update branches (even those developing the same module in parallel) are completely independent and coexist in the shared repository because their branch version numbers have different requirement identifiers (${uniqueId}). Later deployed components will not overwrite previously deployed components from different requirement branches. Components are the basic units for code reuse and modular design, possessing clear functional boundaries and interfaces, and can be called by other programs or systems.

[0084] Furthermore, updating the primary codebase based on different code update branches ensures explicit and reliable downstream dependencies. When other projects or integration environments require updated code that depends on the output of a specific code update branch, they can precisely declare the unique version number of that dependent code update branch in their POM file (e.g., eg, <version> 1.2.0-REQ-1234-SNAPSHOT< / version> During the build process, the expected and consistent components are always obtained, ensuring the repeatability and reliability of the build. Furthermore, when other projects depend on the updated code output from a certain code update branch, clear traceability can be achieved. The source branch and corresponding requirements / tasks can be intuitively identified from the component version number (e.g., REQ-1234), greatly simplifying the complexity of issue tracking and debugging.

[0085] like Figure 4 As shown above, in the above Figure 1 Based on the illustrated embodiment, step 110 may include the following steps: Step 1101: Use at least one update code as at least one second main code.

[0086] The processing performed on the first main code according to the code update requirements is retained in at least one update code, thus obtaining at least one second main code updated based on the first main code.

[0087] Step 1102: Determine at least one output moment corresponding to at least one update branch version number.

[0088] In this embodiment, the processing speed for different code update requirements is different, and the time for outputting the updated code and updating the branch version number is different. Therefore, the corresponding output time is recorded at the same time as the updated branch version number is output in order to distinguish the updated branch version number in terms of time.

[0089] Step 1103: Sort at least one update branch version number according to at least one output time to obtain a version number sequence.

[0090] Optionally, based on the output time, at least one update branch version number can be sorted according to the output order to obtain an order that conforms to the conventional version number setting. In the obtained version number sequence, at least one update branch version number is unrelated to each other and ensures independence.

[0091] Step 1104: Determine at least one second code version number according to the version number sequence.

[0092] Optionally, different distinction values ​​are assigned to each update branch version number in the sequence according to the version number sequence. By superimposing different distinction values ​​on the first code, at least one second code version number that can be distinguished can be obtained.

[0093] In this embodiment, updating the branch version number ensures the independence of version numbers in each branch during the code update process. However, after the code update is completed, at least one second main code that has performed different update operations is output. If the first code version number is not processed at this time, version number confusion will occur. To address this issue, this embodiment determines the version number sequence based on the output time corresponding to the updated branch version number, and determines at least one second code version number corresponding to different second main codes based on the version number sequence. The second code version number is distinguished by the output time, avoiding the code overwriting problem caused by different second main codes corresponding to the same version number.

[0094] Optionally, step 1104 may include: Based on the version number sequence, determine at least one version number increment with different values; perform incremental processing on the first code version number based on the at least one version number increment to obtain at least one second code version number.

[0095] Optionally, at least one version number increment can be 1, 2, 3, ..., and at least one second code version number is obtained by adding at least one version number increment to the first code version number. For example, the first code version number is... <version> ${baseVersion}< / version> Through incremental processing, at least one second code version number is obtained: <version> ${baseVersion+1}< / version> , <version> ${baseVersion+2}< / version> , <version> ${baseVersion+3}< / version> …; the resulting at least one second code version number is independent of each other, enabling automated generation of updated version numbers, which can be integrated into the CI / CD process. Developers do not need to manually negotiate or remember complex version number allocation rules, thus avoiding conflicts and significantly reducing communication costs and the risk of human error. Furthermore, the second code version number generated in this embodiment is compatible with existing processes and does not affect the official release process of the trunk / main branch. When the code update branch is completed and passes testing, the code is merged back into the main branch (corresponding to the branch containing the first main code and the first code version number) through a merge operation, and a standard version upgrade (e.g., mvn release:prepare / release:perform) is performed on the main branch to generate a clean official version (a second code version number with the same format as the first code version number, such as 1.3.0); optionally, the generation of the second code version number can be determined based on the update branch version number, for example, by deleting the requirement identifier and SNAPSHOT from the update branch version number.

[0096] Related technologies primarily rely on manual communication and coordination among developers (such as through chat tools, documents, or meetings) to assign version numbers. While this approach is manageable for small teams or simple projects, it becomes highly error-prone, inefficient, and unscalable in large-scale parallel development, with numerous modules and complex branching strategies (such as Gitflow). Developers may forget to communicate, misunderstand conventions, or neglect checks, leading to actual conflicts. This embodiment solves the fragile and error-prone problem of manual version management by automatically updating the code version number in the main branch.

[0097] In some optional embodiments, the method provided in this embodiment may further include: Perform a merging process on at least one second main code to obtain a third main code; The third code version number corresponding to the third main code is determined based on the largest second code version number among at least one second code version number.

[0098] In this embodiment, each second main code is partially updated relative to the first main code according to the code update requirements. For example, in parallel development, one code update requirement updates the first segment of the first main code, and another code update requirement updates the second segment of the first main code. The resulting two second main codes have their first and second segments updated respectively. To obtain the overall updated main code, this embodiment performs a merging process on at least one second main code. Optionally, the merging operation can replace the corresponding code in one second main code with the code at the corresponding position in the second main code, based on the code position of the code update requirement. After merging the two second main codes, other second main codes are merged with the merged code until all updated code in all second main codes is merged into one main code, resulting in the third main code. After obtaining the third main code, the maximum second code version number can be incremented by one, and the resulting version number is used as the third code version number. For example, if the maximum second code version number is 1.2.3, the third code version number obtained based on this second code version number is 1.2.4.

[0099] In some optional embodiments, the method provided in this embodiment may further include: Store at least one second main code and / or a third main code in the code repository, and index at least one second main code based on at least one second code version number, and / or index the third main code based on the third code version number.

[0100] In this embodiment, to further update the code based on the second or third main code according to other code update requirements, at least one second and / or third main code obtained from the update is stored in the code repository, and at least one second code version number is stored as the index of the corresponding second main code, with the third code version number used as the index of the third main code. When at least one code update request is received, the most recently updated code can be retrieved from the code repository as the first main code (e.g., the third main code), and the code version number corresponding to the most recently updated code can be obtained as the first code version number. The code update method in parallel development provided in any of the above embodiments is then executed to obtain more main code updated according to requirements.

[0101] Any of the code update methods in parallel development provided in the embodiments of this disclosure can be executed by any suitable device with data processing capabilities, including but not limited to: terminal devices and servers. Alternatively, any of the code update methods in parallel development provided in the embodiments of this disclosure can be executed by a processor, such as by a processor executing any of the code update methods in parallel development mentioned in the embodiments of this disclosure by calling corresponding instructions stored in memory. Further details will not be elaborated below.

[0102] Exemplary device Figure 5 This is a schematic diagram of the structure of a code update apparatus in parallel development provided by an exemplary embodiment of this disclosure. Figure 5 As shown, the apparatus provided in this embodiment includes: Identifier determination module 51 is used to determine at least one requirement identifier based on at least one code update requirement.

[0103] Each requirement identifier is used to uniquely identify the corresponding code update requirement.

[0104] The main code acquisition module 52 is used to acquire the first main code and its corresponding first code version number.

[0105] The first code is the update object corresponding to at least one code update requirement.

[0106] Branch version module 53 is used to generate at least one branch version number based on the first code version number and at least one requirement identifier.

[0107] Branch code update module 54 is used to obtain at least one update code and determine at least one update branch version number based on at least one branch version number.

[0108] Among them, at least one update code is the code obtained by updating the first main code according to at least one code update requirement, and at least one update code corresponds one-to-one with at least one update branch version number.

[0109] The main code update module 55 is used to determine at least one second main code and its corresponding at least one second code version number based on at least one update code and at least one update branch version number.

[0110] The code update apparatus for parallel development provided in the above embodiments of this disclosure determines at least one requirement identifier based on at least one code update requirement; each requirement identifier is used to uniquely identify the corresponding code update requirement; a first main code and its corresponding first code version number are obtained; at least one branch version number is generated based on the first code version number and the at least one requirement identifier; at least one updated code obtained by updating the first main code is obtained, and at least one updated branch version number is determined based on the at least one branch version number; at least one second main code and its corresponding at least one second code version number are determined based on the at least one updated code and its corresponding at least one updated branch version number. In this embodiment, different code update requirements are distinguished by requirement identifiers, and branch version numbers for different code update requirements are generated. The first main code is updated based on at least one branch version number to obtain at least one second main code and a second code version number updated for different code update requirements. Since the second code version number is determined by the updated branch version number, and the updated branch version numbers are independent of each other, there is no conflict between at least one second code version number, and the problem of overwriting between second main codes due to code version number conflicts is avoided.

[0111] In some optional embodiments, the branch version module 53 is specifically used to determine a preset version number template including placeholders at preset positions based on the first code version number; and to write at least one requirement identifier into the placeholders in the preset version number template to obtain at least one branch version number.

[0112] In some optional embodiments, the branch code update module 54 is specifically used to determine at least one code update branch based on at least one branch version number; each code update branch corresponds to a code update requirement; in each code update branch, the first main code is updated according to the corresponding code update requirement, and the branch version number is updated to obtain the updated code and its corresponding update branch version number.

[0113] In some optional embodiments, the main code update module 55 is specifically used to: use at least one update code as at least one second main code; determine at least one output time corresponding to at least one update branch version number; sort the at least one update branch version number according to at least one output time to obtain a version number sequence; and determine at least one second code version number according to the version number sequence.

[0114] Optionally, when determining at least one second code version number according to the version number sequence, the main code update module 55 is used to determine at least one version number increment with different values ​​according to the version number sequence; and to perform incremental processing on the first code version number based on the at least one version number increment to obtain at least one second code version number.

[0115] In some optional embodiments, the apparatus provided in this embodiment may further include: The code merging module is used to perform merging processing on at least one second main code to obtain a third main code; and to determine the third code version number corresponding to the third main code based on the largest second code version number among at least one second code version number.

[0116] In some optional embodiments, the apparatus provided in this embodiment may further include: A code storage module is used to store at least one second main code and / or a third main code in a code repository, and to create an index for at least one second main code based on at least one second code version number, and / or to create an index for the third main code based on a third code version number.

[0117] In some optional embodiments, the main code acquisition module 52 is specifically used to acquire the most recently updated code from the code repository as the first main code, and obtain the version number corresponding to the first main code as the first code version number.

[0118] In some optional embodiments, the identifier determination module 51 is specifically used to perform hash processing on at least one code update requirement to obtain at least one requirement identifier.

[0119] In some alternative embodiments, the identifier determination module 51 is specifically used to determine at least one requirement identifier based on at least one code update requirement by utilizing the primary key auto-increment technology in the database.

[0120] Exemplary electronic devices Below, for reference Figure 6 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0121] Figure 6 A block diagram of an electronic device according to an embodiment of the present disclosure is shown.

[0122] like Figure 6 As shown, the electronic device includes one or more processors and memory.

[0123] A processor can be a central processing unit (CPU) or other form of processing unit with data processing and / or instruction execution capabilities, and can control other components in an electronic device to perform desired functions.

[0124] The memory can store one or more computer program products, and the memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor can run the computer program products to implement the code update methods in parallel development of the various embodiments of this disclosure described above, and / or other desired functions.

[0125] In one example, the electronic device may also include input devices and output devices, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0126] In addition, the input device may also include, for example, a keyboard, a mouse, etc.

[0127] This output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0128] Of course, for the sake of simplicity, Figure 6 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0129] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps in the code update methods in parallel development according to various embodiments of this disclosure as described in the foregoing portions of this specification.

[0130] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0131] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the code update methods in parallel development according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0132] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0133] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0134] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0135] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0136] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0137] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0138] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0139] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A code update method in parallel development, characterized by, include: Based on at least one code update requirement, determine at least one requirement identifier; Each of the aforementioned requirement identifiers is used to uniquely identify the corresponding code update requirement; Obtain the first main code and its corresponding first code version number; The first code is the update object corresponding to the at least one code update requirement; The first code version number is combined with the at least one requirement identifier to generate at least one branch version number; wherein each branch version number corresponds to one requirement identifier; Obtain at least one update code, and determine at least one update branch version number based on the at least one branch version number; the at least one update code is the code obtained by the first main code according to the at least one code update requirement, and the at least one update code corresponds one-to-one with the at least one update branch version number; Based on the at least one update code and the at least one update branch version number, at least one second main code and its corresponding at least one second code version number are determined.

2. The method according to claim 1, characterized in that, The step of combining the first code version number with the at least one requirement identifier to generate at least one branch version number includes: Based on the first code version number, a preset version number template is determined, wherein the preset position of the preset version number template includes a placeholder; Write the at least one requirement identifier into the placeholder in the preset version number template to obtain the corresponding at least one branch version number.

3. The method according to claim 1 or 2, characterized in that, The step of obtaining at least one updated code and determining at least one updated branch version number based on the at least one branch version number includes: At least one code update branch is determined based on the at least one branch version number; each code update branch corresponds to one code update requirement. In each code update branch, the first main code is updated according to the corresponding code update requirements, and the branch version number is updated to obtain the updated code and its corresponding update branch version number.

4. The method according to any one of claims 1-3, characterized in that, The step of determining at least one second main code and its corresponding at least one second code version number based on the at least one updated code and the at least one updated branch version number includes: The at least one update code is used as the at least one second main code; Determine at least one output time corresponding to the at least one update branch version number; Sort the version numbers of the at least one update branch according to the at least one output time to obtain a version number sequence; The at least one second code version number is determined according to the version number sequence.

5. The method according to claim 4, characterized in that, Determining the at least one second code version number according to the version number sequence includes: Based on the version number sequence, determine at least one version number increment with different values; The first code version number is incrementally processed based on at least one of the version number increments to obtain the at least one second code version number.

6. The method according to any one of claims 1-5, characterized in that, Also includes: The at least one second main code is merged to obtain the third main code; The third code version number corresponding to the third main code is determined based on the largest second code version number among the at least one second code version number.

7. The method according to claim 6, characterized in that, Also includes: Store the at least one second main code and / or the third main code in the code repository, and create an index for the at least one second main code based on the at least one second code version number, and / or create an index for the third main code based on the third code version number.

8. The method according to claim 7, characterized in that, The step of obtaining the first main code and its corresponding first code version number includes: The most recently updated code is obtained from the code repository as the first main code, and the version number corresponding to the first main code is obtained as the first code version number.

9. An electronic device, characterized in that, include: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the code update method in parallel development as described in any one of claims 1-8.

10. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the code update method in parallel development as described in any one of claims 1-8.

Images