A cloud computing-based software development data hierarchical processing method and system

Abstract

The application relates to the technical field of software development data processing, and discloses a software development data layered processing method and system based on cloud computing, which comprises the following steps: S1, collecting multi-source software development data in the whole life cycle of software development; S2, extracting corresponding research and development object identifiers and establishing the correlation between the software development data; S3, determining the event influence domain corresponding to a development event; S4, performing correlation propagation calculation to obtain the hierarchical migration value corresponding to each software development data; S5, determining a target processing level and updating the corresponding level; S6, executing a differentiated cloud processing strategy. Through unified research and development object identifier conversion, correlation relationship establishment, event influence domain determination and correlation propagation calculation on the multi-source software development data in the whole life cycle of software development, dynamic layered processing of the software development data is realized, so that different software development data can be migrated according to the event correlation degree and execute differentiated cloud processing.

Description

Technical Field

[0001] This invention relates to the field of software development data processing technology, specifically to a cloud computing-based method and system for layered processing of software development data. Background Technology

[0002] With the development of cloud computing and software engineering technologies, the scale of data in the software development process is constantly increasing, and the types of data are becoming increasingly diverse. Software development data typically spans multiple stages, including requirements analysis, code development, continuous integration, testing and verification, version release, and operation and maintenance. Specifically, it can include code submission data, build data, test data, defect data, release data, and operational alarm data. Cloud-based layered processing of software development data refers to relying on the storage and processing capabilities of the cloud platform to collect, organize, associate, and layer multi-source software development data throughout the entire software development lifecycle. This allows for the classification, management, and subsequent processing of different types and degrees of association of software development data. Existing software development data processing methods typically involve collecting and storing data from code repository systems, continuous integration systems, test management systems, defect management systems, release management systems, and operational monitoring systems separately, and then processing them according to preset data categories or fixed rules.

[0003] However, in current technology, due to the lack of effective correlation between software development data from different sources around development events, it is difficult to accurately identify the scope of software development data related to a development event after receiving it, and it is also difficult to dynamically and hierarchically schedule the relevant software development data based on the correlation strength of the development event. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a cloud computing-based method and system for layered processing of software development data, which solves the problem of accurately identifying the scope of software development data related to development events and dynamically scheduling it in layers.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a cloud computing-based software development data layering processing method, comprising: S1. Collect multi-source software development data throughout the entire software development lifecycle, including at least code submission data, build data, test data, defect data, release data, and runtime alarm data; S2. Parse the multi-source software development data, extract the corresponding R&D object identifier, and perform unified R&D object identifier conversion on the identifier information from different sources. Based on the R&D object identifier, establish the association relationship between each software development data. S3. Upon receiving a development event, determine the event influence domain corresponding to the current development event based on the event type, event object identifier, and association relationship of the development event; S4. For the software development data within the event's influence domain, perform association propagation calculations based on the association relationships to obtain the hierarchical migration values ​​corresponding to each piece of software development data. S5. Compare the level migration value corresponding to each software development data with the preset level judgment condition, determine the target processing level corresponding to each software development data, and update the level to which it belongs. S6. Based on the updated target processing level, execute differentiated cloud processing strategies on the corresponding software development data to perform dynamic hierarchical processing of software development data driven by development events.

[0006] Preferably, step S2 includes: The multi-source software development data is parsed to extract identification information, which includes code submission identifier, build task identifier, test task identifier, defect report identifier, release version identifier, and service identifier. According to the preset identifier mapping rules, the identifier information with different sources, different naming formats and different field structures is uniformly converted into the R&D object identifier to obtain the corresponding R&D object identifier; Based on the R&D object identifier corresponding to each software development data, software development data with the same R&D object identifier are matched and associated, and R&D object identifiers with preset corresponding relationships are mapped and associated to establish the relationship between each software development data.

[0007] Preferably, obtaining the corresponding R&D object identifier includes: The identification information is standardized to eliminate differences in naming format, character form, and field structure between identification information from different sources; The standardized identification information is matched according to the preset mapping table. When a match is successful, the corresponding identification information is converted into the same R&D object identification; When a match fails, the relevant software development data is supplemented by matching according to preset association fields. The preset association fields include one or more of the following: version number, service name, build task number, test task number, and time information. The corresponding R&D object identifier is determined based on the supplementary matching results.

[0008] Preferably, step S3 includes: Obtain the event type and event object identifier of the development event; Based on the event object identifier, software development data directly associated with the development event is dynamically determined in the association relationship as directly influencing data; Starting with the R&D object identifier corresponding to the directly impacting data, and following a preset association traversal rule, software development data that is associated with the directly impacting data is searched in the association relationship as indirect impacting data; The direct impact data and the indirect impact data are determined as the event impact domain corresponding to the development event.

[0009] Preferably, the development events include code commit events, build events, test events, defect events, release events, and runtime alert events; Among them, the event object identifier corresponding to the code submission event is the code submission identifier, the event object identifier corresponding to the build event is the build task identifier, the event object identifier corresponding to the test event is the test task identifier, the event object identifier corresponding to the defect event is the defect ticket identifier, the event object identifier corresponding to the release event is the release version identifier, and the event object identifier corresponding to the runtime alarm event is the service identifier.

[0010] Preferably, step S4 includes: Obtain the R&D object identifiers corresponding to each software development data within the event impact domain, and determine the association paths between each R&D object identifier; Based on the path length of the associated path, the relationship type of the associated relationships in the path, the propagation weight corresponding to each associated relationship, and the event type of the development event, calculate the association propagation value of each software development data relative to the development event; Based on the correlation propagation value corresponding to each software development data, determine the hierarchical migration value corresponding to each software development data.

[0011] Preferably, step S5 includes: Obtain the current level corresponding to each software development data, and compare the level migration value corresponding to each software development data with the preset level determination conditions; When the level migration value meets the promotion condition, the target processing level of the corresponding software development data is determined to be a processing level higher than the current level. When the level migration value meets the downgrade condition, the target processing level of the corresponding software development data is determined to be a processing level lower than the current level. When the level migration value does not meet the promotion condition and does not meet the demotion condition, the target processing level of the corresponding software development data is determined as the current level. Based on the target processing level, the corresponding software development data level is dynamically updated.

[0012] Preferably, step S6 includes: According to the updated target processing hierarchy, the software development data is scheduled in a hierarchical manner. Software development data with a high priority processing level will be allocated to cache processing and priority index processing; Software development data with an intermediate target processing level is allocated to the standard computing queue for processing; Software development data with a low priority level will be allocated to archive storage for processing.

[0013] Preferably, the caching process includes writing the corresponding software development data into a preset high-speed cache area; The priority indexing process includes establishing a priority retrieval index for the corresponding software development data; The standard computing queue processing includes writing the corresponding software development data into a preset computing queue and performing data processing according to the queue scheduling order. The archiving and storage process includes writing the corresponding software development data into a preset archiving and storage area.

[0014] A cloud computing-based software development data tiered processing system, the system comprising: The data acquisition module collects multi-source software development data throughout the entire software development lifecycle. The association module parses the multi-source software development data, extracts the corresponding R&D object identifier, and establishes the association relationship between each piece of software development data based on the R&D object identifier. The influence domain determination module, upon receiving a development event, determines the event influence domain corresponding to the development event based on the event type and the associated relationship of the development event. The migration value calculation module performs association propagation calculation based on the association relationship for the software development data within the event influence domain to obtain the hierarchical migration value corresponding to each software development data. The hierarchical update module compares the hierarchical migration value corresponding to each software development data with the preset hierarchical judgment conditions to determine the target processing level corresponding to each software development data and updates its corresponding level. The processing module executes differentiated cloud processing strategies on the corresponding software development data based on the updated target processing level.

[0015] This invention provides a method and system for layered data processing in software development based on cloud computing. It has the following beneficial effects: 1. This invention achieves dynamic hierarchical scheduling based on the correlation strength of development events by uniformly converting R&D object identifiers, determining event impact domains, and calculating correlation propagation of multi-source software development data throughout the entire software development lifecycle. This avoids static processing according to fixed rules and improves the relevance of relevant data processing and the rationality of hierarchical scheduling.

[0016] 2. This invention incorporates code submission data, build data, test data, defect data, release data, and runtime alarm data into a unified processing scope, and establishes a correlation based on the R&D object identifier, so that the originally scattered data can be formed into a data set that can be correlated, which facilitates continuous analysis and processing around development events.

[0017] 3. This invention determines the event influence domain corresponding to the development event after receiving the development event, so that software development data that is directly or indirectly related to the current development event can be identified, thereby providing a clear data range for subsequent hierarchical migration value calculation and target processing hierarchical update.

[0018] 4. This invention performs caching, indexing, computation queue processing, and archiving storage processing on software development data according to the updated target processing level, enabling different levels of software development data to correspond to different cloud processing methods, thereby achieving hierarchical scheduling and classification processing of software development data. Attached Figure Description

[0019] Figure 1 This is a flowchart of a cloud computing-based software development data layering processing method according to the present invention; Figure 2 This is an architecture diagram of a cloud computing-based software development data layering processing system according to the present invention. Detailed Implementation

[0020] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please see the appendix Figure 1 This invention provides a cloud computing-based software development data layering processing method, including: S1. Collect multi-source software development data throughout the entire software development lifecycle, including at least code submission data, build data, test data, defect data, release data, and runtime alarm data; Specifically, this can be achieved by acquiring corresponding data from code repository systems, continuous integration systems, test management systems, defect management systems, release management systems, and operation monitoring systems to collect multi-source software development data throughout the entire software development lifecycle. This multi-source software development data includes at least code submission data, build data, test data, defect data, release data, and runtime alarm data. During collection, data records can be read from each data source according to a preset collection cycle or after a corresponding development event occurs. The read data records are then aggregated to form a basic data set for subsequent processing steps. For example, during a version iteration, the code submission records, build records, test records, defect records, release records, and runtime alarm records corresponding to that version can be acquired sequentially, thus forming multi-source software development data corresponding to that version iteration process. This provides a data foundation for subsequent extraction of R&D object identifiers and the establishment of relationships between various software development data. In one embodiment, in the context of the entire software development lifecycle, the aforementioned code repository system, continuous integration system, test management system, defect management system, release management system, and operation monitoring system together constitute a software development data source system for DevOps and cloud development environments. Therefore, the unified R&D object identification conversion, event impact domain determination, and hierarchical dynamic migration in this embodiment are not general data processing rules detached from the application scenario, but rather dedicated processing mechanisms designed for the dynamic hierarchical management needs of multi-source heterogeneous data in this type of R&D environment.

[0022] S2. Analyze the multi-source software development data, extract the corresponding R&D object identifiers, and perform unified R&D object identifier conversion on the identifier information from different sources. Based on the R&D object identifiers, establish the association relationship between various software development data. Furthermore, step S2 includes: The multi-source software development data is parsed to extract identification information, including code submission identifiers, build task identifiers, test task identifiers, defect report identifiers, release version identifiers, and service identifiers. According to the preset identifier mapping rules, the identifier information with different sources, different naming formats and different field structures is uniformly converted into the R&D object identifier to obtain the corresponding R&D object identifier; Based on the R&D object identifier corresponding to each software development data, software development data with the same R&D object identifier are matched and associated, and R&D object identifiers with preset corresponding relationships are mapped and associated to establish the relationship between each software development data.

[0023] Specifically, firstly, extract the identifying content that can characterize the R&D activity object from code submission data, build data, test data, defect data, release data, and runtime alarm data. Then, perform a unified R&D object identification conversion on the identifying content from different sources to obtain the corresponding R&D object identification. Based on the R&D object identification, establish the relationship between various software development data. For example, in the version iteration process of a certain payment service, the relevant identifying content in code submission records, build records, test records, defect records, release records, and alarm records can be used to associate different software development data accordingly. First, identification information can be extracted by reading predetermined fields from software development data from different sources. Specifically, code submission identifiers can be extracted from code submission data, build task identifiers from build data, test task identifiers from test data, defect ticket identifiers from defect data, release version identifiers from release data, and service identifiers from runtime alarm data. For example, the submission number in the submission record, the build task number in the build record, the test task number in the test record, the defect ticket number in the defect record, the version number in the release record, and the service name in the alarm record can be extracted as identification information. Subsequently, the extracted identification information can be converted into a unified R&D object identifier. Specifically, the identification information can first be standardized, and then mapped according to preset identifier mapping rules. Standardization can include unified character format, unified naming format, and unified version expression. Preset identifier mapping rules can include direct mapping of identification information with consistent content, and corresponding conversion of identification information with preset relationships. After the above processing, identification information from different sources and with different expression forms can be converted into a unified R&D object identifier. After obtaining the corresponding R&D object identifier, matching associations can be established for software development data with the same R&D object identifier, and mapping associations can be established for R&D object identifiers with preset corresponding relationships, thereby forming the association relationship between various software development data.

[0024] Furthermore, the corresponding R&D object identifiers are obtained, including: Standardize the identification information to eliminate differences in naming format, character form, and field structure between identification information from different sources; The standardized identification information is matched according to the preset mapping table. When a match is successful, the corresponding identification information is converted into the same R&D object identification; When a match fails, the relevant software development data is supplemented by matching according to the preset associated fields. The preset associated fields include one or more of the following: version number, service name, build task number, test task number, and time information. The corresponding R&D object identifier is determined based on the supplementary matching results.

[0025] Specifically, when converting identification information from different sources into a unified R&D object identifier, the process can proceed through standardization, correspondence matching, unified R&D object identifier conversion, and supplementary matching to obtain the corresponding R&D object identifier. First, the expression format of the identification information is standardized. Then, based on a preset mapping table, it is determined whether different identification information points to the same R&D activity object. For identification information that can be directly matched, it is converted into the same R&D object identifier. For identification information that cannot be directly matched, supplementary matching is performed using related fields in relevant software development data, thereby improving the completeness of the R&D object identifier determination. For example, during a payment service version iteration, the service name in the code submission data can be recorded as "payment_service", the service name in the release data can be recorded as "payment service", and the service name in the running alarm data can be recorded as "Payment-Service". After the above processing, they can be uniformly identified as the R&D object identifier corresponding to the same service. First, the identification information can be standardized to eliminate differences in naming format, character form, and field structure among identification information from different sources. Specifically, this can be achieved by standardizing capitalization, delimiters, removing redundant prefixes and suffixes, adjusting field order, and standardizing version number expression. This transforms inconsistent identification information into a unified format. For example, "Payment-Service", "payment_service", and "paymentservice" can be standardized into the same standard form. This step ensures that subsequent matching of correspondences is based on consistent data expression, preventing the same R&D activity object from being identified as different objects due to different writing styles. Subsequently, the standardized identification information can be matched against a pre-defined mapping table. This table can be pre-established to record the correspondence between different names, numbers, or expressions. During matching, the standardized identification information is compared with the records in the pre-defined mapping table to determine if a correspondence exists. For example, the pre-defined mapping table can record the correspondence between "payment_service" and "payment service," or the correspondence between different versions of the expression. This step allows for the merging and judgment of identification information from different sources that actually point to the same R&D activity object. When a match is successful, the corresponding identification information can be converted into the same R&D object identification. Specifically, when the standardized identification information is successfully matched with a record in the preset mapping table, the identification information and other corresponding identification information can be uniformly mapped to the same R&D object identification. For example, when "payment service" in the published data and "payment_service" in the running alarm data are successfully matched in the preset mapping table, the two can be uniformly converted into the same service object identification. Through this step, software development data from different sources can be organized around a unified R&D object identification, providing a consistent identification basis for establishing matching and mapping relationships in the future. When a match fails, the relevant software development data can be supplemented by matching according to the preset associated fields, and the corresponding R&D object identifier can be determined based on the supplementary matching results. In specific implementation, the preset associated fields related to the current identifier information can be selected as the supplementary judgment basis. The preset associated fields may include one or more of the following: version number, service name, build task number, test task number, and time information. When a certain identifier information cannot be directly matched through the preset mapping table, it can be further compared with the preset associated fields in the relevant software development data to determine its corresponding R&D activity object. For example, if the version identifier in the defect data does not directly match the version identifier in the release data in the preset mapping table, the service name and release time information in the two can be further combined for supplementary matching. When the supplementary matching result shows that the two correspond to the same release activity, they can be identified as the same R&D object identifier. Thus, the identifier information that has not been directly matched can continue to be identified, thereby improving the process of determining the R&D object identifier. Furthermore, the supplementary matching is not simply a matter of filling in missing identifier information. Instead, it addresses the situation in real-world software development environments where a large amount of data cannot be directly linked through a single identifier. It utilizes contextual fields related to the current identifier information, such as version number, service name, build task number, test task number, and time information, to assist in the determination. This allows a unified association for the same R&D activity object to be established even when direct mapping fails, thereby improving the completeness and robustness of cross-system R&D data association establishment.

[0026] S3. Upon receiving a development event, determine the event influence domain corresponding to the current development event based on the event type, event object identifier, and association relationship of the development event; Furthermore, step S3 includes: Obtain the event type and event object identifier of the development event; Based on the event object identifier, dynamically determine the software development data directly related to the development event in the association relationship, as the directly influencing data; Starting with the R&D object identifier corresponding to the directly impacting data, and following the preset association traversal rules, software development data that is related to the directly impacting data is searched in the association relationships and used as indirect impacting data. The data that directly affects the data and the data that indirectly affects the data are identified as the event impact domains corresponding to the development events.

[0027] Specifically, upon receiving a development event, the event impact domain can be dynamically determined based on the event type and pre-established relationships. This involves first identifying the event object itself, then determining directly related software development data within the relationships associated with that event object as directly affected data. Following this, the system continues searching for related software development data as indirectly affected data. Finally, both directly and indirectly affected data are combined to define the event impact domain for the development event. This approach avoids pre-emptively expanding all potential relationships, instead identifying the affected data range on demand for the current development event. First, the event type and event object identifier of the development event can be obtained. The event type field, which represents the event category, and the event object identifier field, which represents the corresponding object, can be read from the received development event record. The event type can be used to distinguish whether the current development event belongs to a code submission event, build event, test event, defect event, release event, or runtime alarm event. The event object identifier can be used to identify the R&D activity object directly corresponding to the development event. For example, when a test failure record is received, the test event can be extracted from the record as the event type, and the corresponding test task number can be extracted as the event object identifier. Through this step, the starting object for subsequent event impact domain identification can be determined. After obtaining the event type and event object identifier, software development data directly related to the development event can be determined in the association relationship based on the event object identifier, as directly impacting data. The R&D object identifier corresponding to the event object identifier is searched in the aforementioned established association relationship, and software development data directly associated with the R&D object identifier is identified. Direct association may include association relationships with the same R&D object identifier, or association relationships directly corresponding to the R&D object identifier in the preset correspondence relationship. For example, when the event object identifier is a test task number, the test data directly corresponding to the test task can be determined in the association relationship as directly impacting data. If the test task has established a direct association with a build task, the build data corresponding to the build task can also be used as directly impacting data. Through this step, software development data directly related to the current development event can be extracted from multi-source software development data. After identifying the directly impacting data, the R&D object identifier corresponding to the directly impacting data can be used as a starting point. According to the preset association traversal rules, software development data that is related to the directly impacting data can be searched in the association relationship as indirectly impacting data. In specific implementation, according to the preset association traversal rules, other R&D object identifiers connected to the R&D object identifier corresponding to the directly impacting data can be searched level by level, and the software development data corresponding to them can be identified as indirectly impacting data. The preset association traversal rules may include traversing according to the connection direction of the association relationship and restricting the association path according to the preset level range. In one embodiment, in the aforementioned test failure event, the R&D object identifier corresponding to the test data can be used as a starting point to continue searching for the build data, code submission data, defect data, or release data associated with it, and the software development data found can be identified as indirectly impacting data, so as to further identify the software development data that directly corresponds to the development event but is affected by the development event. After obtaining the directly impacted data and the indirectly impacted data, they can be jointly identified as the event impact domain corresponding to the development event. Specifically, the directly impacted data and the indirectly impacted data are aggregated to form a software development data set associated with the current development event, and this software development data set is identified as the event impact domain corresponding to the development event. For example, in the scenario of the test failure event mentioned above, the test data, build data, code submission data, and defect data can be jointly identified as the event impact domain corresponding to the test failure event. All software development data associated with the current development event are uniformly included in the subsequent processing scope, thereby providing an input basis for the calculation of subsequent hierarchical migration values. The above method eliminates the need to fully expand all potential relationships between R&D objects in advance. Instead, it identifies the scope of affected software development data as needed around the current development event, thereby reducing the resource consumption caused by irrelevant data participating in subsequent calculations and improving the targeting and processing efficiency of the scope of impact.

[0028] Furthermore, development events include code commit events, build events, test events, defect events, release events, and runtime alert events; Among them, the event object identifier corresponding to the code submission event is the code submission identifier, the event object identifier corresponding to the build event is the build task identifier, the event object identifier corresponding to the test event is the test task identifier, the event object identifier corresponding to the defect event is the defect ticket identifier, the event object identifier corresponding to the release event is the release version identifier, and the event object identifier corresponding to the runtime alarm event is the service identifier.

[0029] Specifically, development events can include code commit events, build events, test events, defect events, release events, and runtime alert events. In practice, development events can be identified based on the event source, event category, or event status fields in the received event records. When an event record originates from the code repository system, it can be identified as a code commit event; when it originates from the continuous integration system, it can be identified as a build event; when it originates from the test management system, it can be identified as a test event; when it originates from the defect management system, it can be identified as a defect event; when it originates from the release management system, it can be identified as a release event; and when it originates from the runtime monitoring system, it can be identified as a runtime alert event. Classifying development events by type provides a foundation for subsequently determining the corresponding event object identifier. Furthermore, for different types of development events, the event object identifier corresponding to the development event can be extracted. Specifically, the event object identifier corresponding to a code submission event is the code submission identifier, the event object identifier corresponding to a build event is the build task identifier, the event object identifier corresponding to a test event is the test task identifier, the event object identifier corresponding to a defect event is the defect ticket identifier, the event object identifier corresponding to a release event is the release version identifier, and the event object identifier corresponding to a runtime alarm event is the service identifier. In implementation, the corresponding field can be read from the corresponding event record as the event object identifier according to the event type.

[0030] For example, during the version iteration of a payment service, when the code repository system generates a code commit record, the record can be identified as a code commit event, and the corresponding commit number can be extracted as the event object identifier. When the continuous integration system generates a build record, the record can be identified as a build event, and the corresponding build task number can be extracted as the event object identifier. When the operation monitoring system generates a service exception alarm, the record can be identified as an operation alarm event, and the corresponding service name can be extracted as the event object identifier. Through the above processing, development events from different sources can all correspond to clear event object identifiers, which facilitates the subsequent determination of the event impact domain corresponding to the development event based on the event object identifier.

[0031] S4. For software development data within the event's impact domain, perform correlation propagation calculations based on the relationships to obtain the hierarchical migration values ​​corresponding to each piece of software development data. Furthermore, step S4 includes: Obtain the R&D object identifiers corresponding to each software development data within the event impact domain, and determine the association paths between each R&D object identifier; Based on the path length of the associated path, the relationship type of the associated relationships in the path, the propagation weight of each associated relationship, and the event type of the development event, calculate the association propagation value of each software development data relative to the development event. Based on the correlation propagation value corresponding to each software development data, determine the hierarchical migration value corresponding to each software development data.

[0032] Specifically, after determining the event impact domain corresponding to the development event, association propagation calculations can be performed on the software development data within the event impact domain based on the relationships, and the hierarchical migration value corresponding to each piece of software development data can be determined accordingly. In specific implementation, the R&D object identifiers corresponding to each piece of software development data within the event impact domain and the association paths between each R&D object identifier can be determined first. Then, the association propagation value can be calculated by combining the path length of the association path, the relationship type of the association in the path, the propagation weight corresponding to each association, and the event type of the development event. Finally, the hierarchical migration value corresponding to each piece of software development data can be determined based on the association propagation value. The association propagation value is used to characterize the degree of association propagation of each piece of software development data within the event impact domain relative to the current development event. The higher the degree of association propagation, the more likely the corresponding software development data will be adjusted to a higher processing level in subsequent hierarchical migration. For example, in a test failure event of a certain payment service, association propagation calculations can be performed around the relationship between test data, build data, code submission data, and defect data to obtain the hierarchical migration value corresponding to each of the above software development data. First, the R&D object identifiers corresponding to each software development data within the event's impact domain can be obtained, and the association paths between each R&D object identifier can be determined. Specifically, the corresponding R&D object identifiers can be read from the software development data within the event's impact domain, and based on the pre-established association relationships, it can be determined whether there is a connection relationship between any two R&D object identifiers. If a connection relationship exists, the sequence of association relationships from the starting R&D object identifier to the target R&D object identifier can be determined as an association path. For example, in the aforementioned test failure event, the association path between the test object identifier and the build object identifier, the association path between the build object identifier and the code submission object identifier, and the association path between the test object identifier and the defect object identifier can be determined, thereby providing a path basis for the subsequent calculation of the association propagation value. After determining the association paths between the identifiers of each R&D object, the association propagation value corresponding to each software development data can be calculated based on the path length, the relationship type of the association in the path, the propagation weight corresponding to each association, and the event type of the development event. In this embodiment, the first... The correlation propagation value corresponding to each piece of software development data It can be represented as: ; in, Indicates the first The correlation propagation value corresponding to each piece of software development data Indicates the relationship with the first A set of associated paths related to the R&D object identifiers corresponding to each piece of software development data. Represents any associated path in the set of associated paths. This represents the event weight corresponding to the event type of a development event; the corresponding data is the development event data. Indicates the associated path The relationship weights corresponding to the types of relationships in the data are the relationship data. Represents the path attenuation coefficient. Indicates the associated path The path length is defined as the associated path data. This allows software development data with shorter path lengths, higher relation weights, and a higher degree of relevance to the current development event to obtain higher association propagation values. Consequently, the determination of the hierarchical migration value no longer depends on fixed data categories, storage durations, or access popularity, but rather on the degree of association propagation of software development data within the context of the current development event. This enables dynamic hierarchical processing oriented towards development events. For example, when the test data corresponding to a test failure event has one layer of association path with the build data, but two layers of association path with the code submission data, under the same relation weight, the association propagation value corresponding to the build data can be higher than that corresponding to the code submission data. After obtaining the correlation propagation value corresponding to each software development data point, the hierarchical migration value corresponding to each software development data point can be determined based on the correlation propagation value. In specific implementation, the correlation propagation value can be used as the hierarchical migration value, or a preset adjustment coefficient can be used to convert the correlation propagation value. In this embodiment, the hierarchical migration value can be determined in the following way: ; in, Indicates the first Hierarchical migration values ​​corresponding to each piece of software development data Indicates the first The correlation propagation value corresponding to each piece of software development data This represents the adjustment coefficient corresponding to the development event type. The corresponding data is the development event type data, which reflects the degree of influence of different types of development events on the hierarchical migration value, and provides a basis for determining the target processing level based on the hierarchical migration value.

[0033] S5. Compare the level migration value corresponding to each software development data with the preset level judgment condition, determine the target processing level corresponding to each software development data, and update the level to which it belongs. Furthermore, the S5 steps include: Obtain the current level corresponding to each software development data, and compare the level migration value corresponding to each software development data with the preset level determination conditions; When the hierarchical migration value meets the promotion conditions, the target processing level of the corresponding software development data will be determined to be a processing level higher than the current level. When the hierarchical migration value meets the downgrade condition, the target processing level of the corresponding software development data is determined to be a processing level lower than the current level. When the hierarchical migration value does not meet the conditions for promotion or demotion, the target processing level of the corresponding software development data will be determined as the current level. Update the corresponding software development data level according to the target processing level.

[0034] Specifically, after obtaining the level migration value corresponding to each software development data, the level migration value can be compared with the preset level determination conditions to determine the target processing level corresponding to each software development data, and the level to which it belongs can be updated accordingly. First, the current level of each software development data is read, and then the target processing level is determined according to whether the level migration value meets the preset promotion or demotion conditions. If the level migration value meets the promotion condition, the target processing level is determined to be a processing level higher than the current level. If the level migration value meets the demotion condition, the target processing level is determined to be a processing level lower than the current level. If the level migration value meets neither the promotion nor the demotion condition, the current level remains unchanged. For example, in the event impact domain corresponding to a certain test failure event, if the level migration value corresponding to the construction data is high, its target processing level can be determined to be a processing level higher than the current level. If the level migration value corresponding to a certain historical release data is low, its target processing level can be determined to be a processing level lower than the current level. First, the current level of each software development data can be obtained, and the level migration value of each software development data can be compared with the preset level judgment condition. Specifically, the current processing level of each software development data can be read from the existing layering results, and the corresponding level migration value can be compared with the preset level judgment condition to determine whether the software development data needs to be adjusted in level. The preset level judgment condition can be set in the form of a threshold range, thereby providing a basis for determining the target processing level in the future. After the comparison is completed, if the level migration value meets the promotion condition, the target processing level of the corresponding software development data is determined to be a processing level higher than the current level; if the level migration value meets the demotion condition, the target processing level of the corresponding software development data is determined to be a processing level lower than the current level; if the level migration value does not meet either the promotion or demotion condition, the target processing level of the corresponding software development data is determined to be the current level. In this embodiment, the first... The target processing level corresponding to each piece of software development data It can be represented as: ; in, Indicates the first The target processing level corresponding to each piece of software development data; Indicates the first The hierarchical migration value corresponding to each piece of software development data is the corresponding data, which is the hierarchical migration value data. Indicates a high priority level; Indicates an intermediate level; Indicates a low priority level; This indicates the decision threshold corresponding to a higher priority level; This represents the decision threshold corresponding to the intermediate level, and In this way, the hierarchical transition value can be converted into a specific target processing level; After determining the target processing level, the level to which the corresponding software development data belongs can be updated according to the target processing level. Specifically, when the target processing level is inconsistent with the current level, the level to which the corresponding software development data belongs can be adjusted to the target processing level. When the target processing level is consistent with the current level, the original level can be maintained. This completes the level update of the software development data and provides a basis for implementing differentiated cloud processing strategies based on the updated target processing level. Using the above method, the level of software development data can be dynamically adjusted based on the level migration value corresponding to each software development data under the current development event, so that the target processing level can change with the development event context, thereby providing a layered result that matches the current development event for subsequent differentiated cloud processing.

[0035] S6. Based on the updated target processing level, execute differentiated cloud processing strategies on the corresponding software development data to perform dynamic hierarchical processing of software development data driven by development events.

[0036] Furthermore, step S6 includes: According to the updated target processing hierarchy, the software development data is scheduled in a hierarchical manner. Software development data with a high priority processing level will be allocated to cache processing and priority index processing; Software development data with an intermediate target processing level is allocated to the standard computing queue for processing; Software development data with a low priority level will be allocated to archive storage for processing.

[0037] Specifically, after completing the update of the corresponding level, a differentiated cloud processing strategy can be executed on the corresponding software development data according to the updated target processing level. That is, the software development data is first scheduled in layers according to the updated target processing level, and then the software development data of different target processing levels are allocated to the corresponding processing methods. Among them, high-priority software development data can be allocated to cache processing and priority index processing, intermediate-priority software development data can be allocated to standard computing queue processing, and low-priority software development data can be allocated to archive storage processing. In one embodiment, in the handling of a certain test failure event, if the build data and test data are updated to high priority level, cache processing and priority index processing can be performed on them. If some related historical release data is determined to be low priority level, archive storage processing can be performed on them. First, according to the updated target processing level, the software development data can be scheduled in layers. Specifically, according to the target processing level corresponding to each software development data, it can be classified and collected to form data processing sets corresponding to different levels, so that the cloud processing strategies corresponding to each level can be executed separately in the future. After completing the hierarchical scheduling, software development data with a high priority level can be allocated to cache processing and priority index processing. Specifically, this part of the software development data can be written into the cache area, and a priority retrieval index can be established for this part of the software development data so that the high priority software development data can be processed in the corresponding way. For software development data with an intermediate processing level, it can be allocated to a standard computing queue for processing. Specifically, this part of the software development data can be written into a preset computing queue and the corresponding data processing can be performed according to the queue scheduling order so that the intermediate software development data can enter the regular processing flow. For software development data with a low priority level, it can be allocated to archive storage. This part of the software development data can be written to a preset archive storage area so that the low priority software development data is stored in an archive manner.

[0038] Furthermore, the caching process includes writing the corresponding software development data into a preset cache area; Priority indexing includes creating priority retrieval indexes for the corresponding software development data; Standard computation queue processing includes writing the corresponding software development data into a preset computation queue and performing data processing according to the queue scheduling order; The archiving and storage process includes writing the corresponding software development data into a pre-defined archiving storage area.

[0039] Specifically, for software development data allocated to different processing methods, corresponding processing operations can be performed respectively. Among them, caching processing can be achieved by writing the corresponding software development data into a preset high-speed cache area; priority index processing can be achieved by establishing a priority retrieval index for the corresponding software development data; standard computation queue processing can be achieved by writing the corresponding software development data into a preset computation queue and executing data processing according to the queue scheduling order; and archive storage processing can be achieved by writing the corresponding software development data into a preset archive storage area. For example, in the handling of a certain test failure event, if the test data and build data are allocated to a high priority level, they can be written into a preset high-speed cache area and a priority retrieval index can be established. If some historical release data is allocated to a low priority level, it can be written into a preset archive storage area. For caching, the corresponding software development data can be written to a preset high-speed cache area, that is, high-priority software development data can be stored in a pre-set cache storage area for subsequent fast reading and retrieval. For priority index processing, priority retrieval indexes can be created for the corresponding software development data. For software development data with high priority, corresponding retrieval indexes can be generated and set as priority retrieval indexes so that subsequent index retrieval can be performed according to priority. For standard computation queue processing, the corresponding software development data is written into the preset computation queue, and the data processing is performed according to the queue scheduling order. Specifically, intermediate-level software development data can be written into the preset computation queue, and then the corresponding data processing is performed according to the scheduling order in the computation queue. For archiving and storage processing, the corresponding software development data can be written to the preset archiving storage area, and the low-priority software development data can be written to the preset archiving storage area to complete the archiving and storage of the corresponding software development data. Since the updated target processing hierarchy is dynamically determined based on the degree of software development data association and propagation and the hierarchy migration value under the current development event, the above-mentioned caching processing, priority indexing processing, standard computing queue processing and archive storage processing are not fixed processing after static hot and cold partitioning of software development data, but rather dynamic hierarchical scheduling of software development data according to the current development event context.

[0040] Please see the appendix Figure 2 A cloud computing-based software development data tiered processing system, the system comprising: The data acquisition module collects multi-source software development data throughout the entire software development lifecycle. The association module parses multi-source software development data, extracts the corresponding R&D object identifiers, and establishes the association relationships between various software development data based on the R&D object identifiers. The influence domain determination module, upon receiving a development event, determines the event influence domain corresponding to the development event based on the event type and relationships of the development event. The migration value calculation module performs correlation propagation calculations based on the relationships of software development data within the event's impact domain to obtain the hierarchical migration values ​​corresponding to each piece of software development data. The hierarchical update module compares the hierarchical migration value corresponding to each software development data with the preset hierarchical judgment conditions to determine the target processing level corresponding to each software development data and updates its corresponding level. The processing module executes differentiated cloud processing strategies on the corresponding software development data based on the updated target processing level.

[0041] Specifically, the acquisition module collects multi-source software development data throughout the entire software development lifecycle; the association module parses the multi-source software development data, extracts the corresponding R&D object identifiers, and establishes associations between various software development data based on these identifiers; the influence domain determination module, upon receiving a development event, determines the event influence domain corresponding to the event based on the event type and associations; the migration value calculation module performs association propagation calculations on the software development data within the event influence domain based on the associations to obtain the hierarchical migration value corresponding to each piece of software development data; the hierarchical update module compares the hierarchical migration value corresponding to each piece of software development data with preset hierarchical judgment conditions to determine the target processing level for each piece of software development data and updates its corresponding level; and the processing module executes differentiated cloud processing strategies on the corresponding software development data based on the updated target processing level. Through the cooperation of these modules, the entire processing process from multi-source software development data acquisition, association establishment, event influence domain determination, hierarchical migration value calculation, target processing level update to differentiated processing execution can be completed.

[0042] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A cloud computing-based software development data layering processing method, characterized in that, include: S1. Collect multi-source software development data throughout the entire software development lifecycle, including at least code submission data, build data, test data, defect data, release data, and runtime alarm data; S2. Parse the multi-source software development data, extract the corresponding R&D object identifier, and perform unified R&D object identifier conversion on the identifier information from different sources. Based on the R&D object identifier, establish the association relationship between each software development data. S3. Upon receiving a development event, determine the event influence domain corresponding to the current development event based on the event type, event object identifier, and association relationship of the development event; S4. For the software development data within the event's influence domain, perform association propagation calculations based on the association relationships to obtain the hierarchical migration values ​​corresponding to each piece of software development data. S5. Compare the level migration value corresponding to each software development data with the preset level judgment conditions to determine the target processing level corresponding to each software development data, and dynamically update the level to which it belongs. S6. Based on the updated target processing level, execute differentiated cloud processing strategies on the corresponding software development data to perform dynamic hierarchical processing of software development data driven by development events.

2. The method for layered processing of software development data based on cloud computing according to claim 1, characterized in that, Step S2 includes: The multi-source software development data is parsed to extract identification information, which includes code submission identifier, build task identifier, test task identifier, defect report identifier, release version identifier, and service identifier. According to the preset identifier mapping rules, the identifier information with different sources, different naming formats and different field structures is uniformly converted into the R&D object identifier to obtain the corresponding R&D object identifier; Based on the R&D object identifier corresponding to each software development data, software development data with the same R&D object identifier are matched and associated, and R&D object identifiers with preset corresponding relationships are mapped and associated to establish the relationship between each software development data.

3. The method for layered processing of software development data based on cloud computing according to claim 2, characterized in that, The process of obtaining the corresponding R&D object identifier includes: The identification information is standardized to eliminate differences in naming format, character form, and field structure between identification information from different sources; The standardized identification information is matched according to the preset mapping table. When a match is successful, the corresponding identification information is converted into the same R&D object identification; When a match fails, the relevant software development data is supplemented by matching according to preset association fields. The preset association fields include one or more of the following: version number, service name, build task number, test task number, and time information. The corresponding R&D object identifier is determined based on the supplementary matching results.

4. The method for layered processing of software development data based on cloud computing according to claim 1, characterized in that, Step S3 includes: Obtain the event type and event object identifier of the development event; Based on the event object identifier, software development data directly associated with the development event is dynamically determined in the association relationship as directly influencing data; Starting with the R&D object identifier corresponding to the directly impacting data, and following a preset association traversal rule, software development data that is associated with the directly impacting data is searched in the association relationship as indirect impacting data; The direct impact data and the indirect impact data are determined as the event impact domain corresponding to the development event.

5. The method for layered processing of software development data based on cloud computing according to claim 4, characterized in that, The development events include code commit events, build events, test events, defect events, release events, and runtime alert events; Among them, the event object identifier corresponding to the code submission event is the code submission identifier, the event object identifier corresponding to the build event is the build task identifier, the event object identifier corresponding to the test event is the test task identifier, the event object identifier corresponding to the defect event is the defect ticket identifier, the event object identifier corresponding to the release event is the release version identifier, and the event object identifier corresponding to the runtime alarm event is the service identifier.

6. The method for layered processing of software development data based on cloud computing according to claim 1, characterized in that, The S4 step includes: Obtain the R&D object identifiers corresponding to each software development data within the event impact domain, and determine the association paths between each R&D object identifier; Based on the path length of the associated path, the relationship type of the associated relationships in the path, the propagation weight corresponding to each associated relationship, and the event type of the development event, calculate the association propagation value of each software development data relative to the development event; Based on the correlation propagation value corresponding to each software development data, determine the hierarchical migration value corresponding to each software development data.

7. The method for layered processing of software development data based on cloud computing according to claim 1, characterized in that, Step S5 includes: Obtain the current level corresponding to each software development data, and compare the level migration value corresponding to each software development data with the preset level determination conditions; When the level migration value meets the promotion condition, the target processing level of the corresponding software development data is determined to be a processing level higher than the current level. When the level migration value meets the downgrade condition, the target processing level of the corresponding software development data is determined to be a processing level lower than the current level. When the level migration value does not meet the promotion condition and does not meet the demotion condition, the target processing level of the corresponding software development data is determined as the current level. Based on the target processing level, the level to which the corresponding software development data belongs is dynamically updated.

8. The method for layered processing of software development data based on cloud computing according to claim 1, characterized in that, Step S6 includes: According to the updated target processing hierarchy, the software development data is scheduled in a hierarchical manner. Software development data with a high priority processing level will be allocated to cache processing and priority index processing; Software development data with an intermediate target processing level is allocated to the standard computing queue for processing; Software development data with a low priority level will be allocated to archive storage for processing.

9. A method for layered processing of software development data based on cloud computing according to claim 8, characterized in that, The caching process includes writing the corresponding software development data into a preset high-speed cache area; The priority indexing process includes establishing a priority retrieval index for the corresponding software development data; The standard computing queue processing includes writing the corresponding software development data into a preset computing queue and performing data processing according to the queue scheduling order. The archiving and storage process includes writing the corresponding software development data into a preset archiving and storage area.

10. A cloud computing-based software development data layering processing system, characterized in that, The system for a cloud computing-based software development data layering processing method according to any one of claims 1-9, the system comprising: The data acquisition module collects multi-source software development data throughout the entire software development lifecycle. The association module parses the multi-source software development data, extracts the corresponding R&D object identifier, and establishes the association relationship between each piece of software development data based on the R&D object identifier. The influence domain determination module, upon receiving a development event, determines the event influence domain corresponding to the development event based on the event type and the associated relationship of the development event. The migration value calculation module performs association propagation calculation based on the association relationship for the software development data within the event influence domain to obtain the hierarchical migration value corresponding to each software development data. The hierarchical update module compares the hierarchical migration value corresponding to each software development data with the preset hierarchical judgment conditions to determine the target processing level corresponding to each software development data and updates its corresponding level. The processing module executes differentiated cloud processing strategies on the corresponding software development data based on the updated target processing level.

Images