CN112732265B

CN112732265B - Data processing method and related device

Info

Publication number: CN112732265B
Application number: CN201911038478.2A
Authority: CN
Inventors: 张林悦; 姚海波
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-10-29
Filing date: 2019-10-29
Publication date: 2024-03-19
Anticipated expiration: 2039-10-29
Also published as: CN112732265A

Abstract

The embodiment of the application discloses a data processing method and a related device, wherein the method comprises the following steps: acquiring a target source character string associated with a business management warehouse and incremental change attribute information corresponding to the target source character string; the target source character string is determined by the target terminal after changing the history source character string corresponding to the applet associated with the first application; embedding the target source character string into the history source character string according to the increment change attribute information, and generating a test data packet corresponding to the applet according to the history source character string embedded with the target source character string; and sending the test data packet to a first service server corresponding to the first application, so that the first service server distributes the test data packet to a target test user. By adopting the method and the device, the efficiency of generating the test data packet can be improved, and the waste of development resources can be avoided.

Description

Data processing method and related device

Technical Field

The present disclosure relates to the field of internet technologies, and in particular, to a data processing method and a related device.

Background

In the prior art, a developer can manually compile through a compiling button on a development interface of the development terminal, and manually upload a test data packet successfully compiled for the applet to the WeChat server through an uploading button. In other words, the prior art needs to consume a long man-machine interaction operation in the process of generating the test data packet, thereby reducing the generation efficiency of the test packet.

In addition, in the current development scene of the applet, each development terminal can be used for code development and code compiling, so that each development terminal can directly push the test data packet generated by each development terminal to the micro-letter server, namely, each development terminal in the prior art can directly perform data interaction with the micro-letter server, and further, the phenomenon that the micro-letter server can repeatedly receive the test data packet uploaded by a plurality of development terminals can be caused. For example, the WeChat server will wrap the test data packet received before the last time the test data packet is received, so that there is a waste of development resources in the development process of the current applet.

Content of the application

The embodiment of the application provides a data processing method and a related device, which can improve the generation efficiency of test data packets and avoid the waste of development resources.

In one aspect, an embodiment of the present application provides a data processing method, where the method is applied to a persistent integration server, and includes:

acquiring a target source character string associated with a business management warehouse and incremental change attribute information corresponding to the target source character string; the target source character string is determined by the target terminal after changing the history source character string corresponding to the applet associated with the first application;

embedding the target source character string into the history source character string according to the increment change attribute information, and generating a test data packet corresponding to the applet according to the history source character string embedded with the target source character string;

and sending the test data packet to a first service server corresponding to the first application, so that the first service server distributes the test data packet to a target test user.

The obtaining the target source character string associated with the business management warehouse and the increment change attribute information corresponding to the target source character string includes:

acquiring service submission notification information sent by a service management server corresponding to the service management warehouse aiming at a target source character string; the service submission notification information comprises a hash value of version information corresponding to the target source character string;

And pulling the target source character string and the increment change attribute information corresponding to the target character string from the service management warehouse according to the hash value.

when the current time length reaches the timing pulling time length, acquiring a source code pulling instruction aiming at a target source character string;

and pulling the target source character string and the increment change attribute information corresponding to the target character string from the service management warehouse according to the source code pulling instruction.

The service management warehouse is a code database used for data sharing in the service management server; the code database contains service code data uploaded by at least one terminal associated with the applet; the service code data comprises the target source character string uploaded by a target terminal in the at least one terminal and increment change attribute information corresponding to the target source character string; the service management server is used for carrying out distributed storage on the target source character string uploaded by the target terminal and carrying out version management on the version information of the target source character string.

The step of embedding the target source character string into the history source character string according to the increment change attribute information, and generating a test data packet corresponding to the applet according to the history source character string embedded with the target source character string, including:

embedding the target source character string into the history source character string according to the increment change attribute information, and generating a data packet to be compiled corresponding to the applet according to the history source character string embedded with the target source character string;

and compiling the data packet to be convenient according to the dependent data file corresponding to the applet, and obtaining the test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

The step of embedding the target source character string into the history source character string according to the increment change attribute information, and generating a data packet to be compiled corresponding to the applet according to the history source character string embedded with the target source character string, including:

performing anomaly detection on the target source character string;

when the target source character string is detected not to meet the abnormal pulling condition, determining the position information of the target source character string in the historical source character string according to the increment change attribute information;

And embedding the target source character string into the historical source character string based on the position information, and taking the historical source character string embedded with the target source character string as a data packet to be compiled corresponding to the applet.

Wherein,

the method further comprises the steps of:

when the target source character string is detected to meet the abnormal pulling condition, generating abnormal pulling log information corresponding to the target source character string;

generating first abnormality reminding information corresponding to the applet according to at least one abnormality pulling factor in the abnormality pulling log information;

pushing the first abnormal reminding information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application; the group includes at least one development user that participates in developing the applet.

The compiling processing is performed on the data packet to be compiled according to the dependency data file corresponding to the applet, and when the compiling state of the data packet to be compiled is a successful state, a test data packet corresponding to the applet is obtained, including:

acquiring a dependent data packet associated with the data packet to be compiled, and acquiring a dependent data file for compiling the data packet to be compiled when the installation state of the dependent data packet is a successful state;

According to a third-party class library provided in the dependent data file, code compiling is carried out on the data packet to be compiled, and a sub-packaging mechanism corresponding to the applet is obtained;

dividing the data packet to be compiled into N sub-packets based on the sub-packet mechanism; n is a positive integer; the N subpackets comprise a first data packet associated with a main page of the applet and a second data packet associated with a sub page of the applet;

and when the compiling state of the data packet to be compiled is a successful state, obtaining a test data packet corresponding to the applet based on the first data packet and the second data packet.

Wherein the method further comprises:

generating installation abnormal log information when the installation state of the dependent data packet is a failure state;

generating installation error prompt information based on installation abnormal factors associated with the installation abnormal log information;

if the installation abnormality factors belong to environment abnormality factors which are irrelevant to the target source character string, the installation error prompt information is used as first type abnormality prompt information corresponding to the applet;

if the installation abnormality factors belong to the code abnormality factors related to the target source character string, acquiring a code submission record corresponding to the target source character string and developer information related to the code submission record, supplementing the code submission record and the developer information to the installation error prompt information, and taking the supplemented installation error prompt information as second type abnormality prompt information corresponding to the applet.

Wherein the method further comprises:

when the compiling state of the data packet to be compiled is a failure state, generating compiling error log information corresponding to the data packet to be compiled, and carrying out error analysis on the compiling error log information to obtain compiling error factors corresponding to the data packet to be compiled; the compiling error factor comprises a static grammar error corresponding to a target source character string in the data packet to be compiled;

generating second abnormal reminding information corresponding to the applet based on the static grammar error;

sending the second abnormal reminding information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application.

The sending the test data packet to a first service server corresponding to the first application includes:

acquiring a target interface provided by a continuous integration platform on the continuous integration platform corresponding to the applet; the target interface includes an IDE interface associated with the applet;

and calling the IDE interface to simulate and upload the test data packet to a first service server corresponding to the first application.

Wherein the method further comprises:

if the response text information returned by the first service server for the test data packet is obtained in the response time length, the completion of uploading the test data packet is determined;

if the response text information returned by the first service server is not acquired within the response time, generating abnormal uploading log information, generating third abnormal reminding information corresponding to the small program according to abnormal uploading factors in the abnormal uploading log information, and sending the third abnormal reminding information to a group associated with the small program through a second service server associated with the small program; the group is a group in a second application different from the first application.

In one aspect, an embodiment of the present application provides a data processing apparatus, where the apparatus is applied to a persistent integration server, including:

the character string acquisition module is used for acquiring a target source character string associated with the business management warehouse and increment change attribute information corresponding to the target source character string; the target source character string is determined by the target terminal after changing the history source character string corresponding to the applet associated with the first application;

The character string embedding module is used for embedding the target source character string into the historical source character string according to the increment change attribute information and generating a test data packet corresponding to the applet according to the historical source character string embedded with the target source character string;

and the data packet sending module is used for sending the test data packet to a first service server corresponding to the first application so that the first service server distributes the test data packet to a target test user.

Wherein, the character string acquisition module includes:

the notification acquisition unit is used for acquiring service submission notification information sent by the service management server corresponding to the service management warehouse aiming at the target source character string; the service submission notification information comprises a hash value of version information corresponding to the target source character string;

and the first acquisition unit is used for pulling the target source character string and the increment change attribute information corresponding to the target character string from the service management warehouse according to the hash value.

Wherein, the character string acquisition module includes:

the instruction acquisition unit is used for acquiring a source code pulling instruction aiming at a target source character string when the current time length reaches the timing pulling time length;

And the second acquisition unit is used for pulling the target source character string and the increment change attribute information corresponding to the target character string from the service management warehouse according to the source code pulling instruction.

Wherein, the character string embedding module includes:

the character embedding unit is used for embedding the target source character string into the historical source character string according to the increment change attribute information and generating a data packet to be compiled corresponding to the applet according to the historical source character string embedded with the target source character string;

And the compiling processing unit is used for compiling the data packet to be convenient according to the dependency data file corresponding to the applet, and obtaining the test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

Wherein the character embedding unit includes:

an anomaly detection subunit, configured to perform anomaly detection on the target source string;

a position determining subunit, configured to determine, when it is detected that the target source string does not satisfy an abnormal pull condition, position information of the target source string in the history source string according to the incremental change attribute information;

and the character embedding subunit is used for embedding the target source character string into the history source character string based on the position information, and taking the history source character string embedded with the target source character string as a data packet to be compiled corresponding to the applet.

Wherein,

the character embedding unit further includes:

the first log generation subunit is used for generating abnormal pull log information corresponding to the target source character string when the target source character string is detected to meet the abnormal pull condition;

the first abnormality reminding subunit is used for generating first abnormality reminding information corresponding to the applet according to at least one abnormality pulling factor in the abnormality pulling log information;

A first alert pushing subunit, configured to push the first abnormal alert information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application; the group includes at least one development user that participates in developing the applet.

Wherein the compiling processing unit includes:

the dependency acquisition subunit is used for acquiring a dependency data packet associated with the data packet to be compiled, and acquiring a dependency data file for compiling the data packet to be compiled when the installation state of the dependency data packet is a successful state;

the compiling subunit is used for compiling codes of the data packets to be compiled according to a third party class library provided in the dependent data file and obtaining a sub-packaging mechanism corresponding to the applet;

the sub-sub unit is used for dividing the data packet to be compiled into N sub-packets based on the sub-packet mechanism; n is a positive integer; the N subpackets comprise a first data packet associated with a main page of the applet and a second data packet associated with a sub page of the applet;

And the test packet generation subunit is used for obtaining the test data packet corresponding to the applet based on the first data packet and the second data packet when the compiling state of the data packet to be compiled is a successful state.

Wherein the compiling processing unit further includes:

the second log generation subunit is used for generating installation abnormal log information when the installation state of the dependent data packet is a failure state;

an installation error subunit, configured to generate installation error prompt information based on an installation abnormality factor associated with the installation abnormality log information;

a character-independent subunit, configured to take the installation error prompt information as first type abnormality prompting information corresponding to the applet if the installation abnormality factor belongs to an environment abnormality factor that is independent of the target source character string;

and the character related subunit is used for acquiring a code submitting record corresponding to the target source character string and developer information related to the code submitting record if the installation abnormality factor belongs to the code abnormality factor related to the target source character string, supplementing the code submitting record and the developer information to the installation error prompt information, and taking the supplemented installation error prompt information as second type abnormality prompt information corresponding to the applet.

Wherein the compiling processing unit further includes:

the compiling error subunit is used for generating compiling error log information corresponding to the data packet to be compiled when the compiling state of the data packet to be compiled is a failure state, and carrying out error analysis on the compiling error log information to obtain compiling error factors corresponding to the data packet to be compiled; the compiling error factor comprises a static grammar error corresponding to a target source character string in the data packet to be compiled;

the second abnormal reminding subunit is used for generating second abnormal reminding information corresponding to the applet based on the static grammar error;

the second reminding pushing subunit is used for sending the second abnormal reminding information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application.

Wherein, the data packet sending module includes:

the interface acquisition unit is used for acquiring a target interface provided by the continuous integration platform on the continuous integration platform corresponding to the applet; the target interface includes an IDE interface associated with the applet;

And the data packet uploading unit is used for calling the IDE interface to simulate and upload the test data packet to a first service server corresponding to the first application.

Wherein the apparatus further comprises:

the response acquisition module is used for determining that the uploading of the test data packet is finished if response text information returned by the first service server for the test data packet is acquired within the response time length;

the abnormal uploading module is used for generating abnormal uploading log information if the response text information returned by the first service server is not acquired within the response time, generating third abnormal reminding information corresponding to the small program according to the abnormal uploading factors in the abnormal uploading log information, and sending the third abnormal reminding information to a group associated with the small program through a second service server associated with the small program; the group is a group in a second application different from the first application.

In one aspect, the present application provides a computer device comprising: a processor, a memory, a network interface;

the processor is connected with the memory and the network interface, wherein the network interface is used for providing a data communication function, the memory is used for storing a computer program, and the processor is used for calling the computer program to execute the method in the aspect in the embodiment of the application.

An aspect of the present application provides a computer readable storage medium storing a computer program comprising program instructions which, when executed by a processor, perform the method of the above aspect of the embodiments of the present application.

According to the embodiment of the application, the target source character string associated with the business management warehouse and the increment change attribute information corresponding to the target source character string can be obtained; the target source character string is determined by the target terminal after changing the history source character string corresponding to the applet associated with the first application; embedding the target source character string into the history source character string according to the increment change attribute information, and generating a test data packet corresponding to the applet according to the history source character string embedded with the target source character string; and sending the test data packet to a first service server corresponding to the first application, so that the first service server distributes the test data packet to a target test user. Therefore, the method and the system can embed the target source character string (such as the latest uploaded source code) acquired from the service management warehouse into the history source character string through the introduced continuous integrated server, the history source character string can be the source code (such as the last uploaded source code) existing in the continuous integrated server, and the continuous integrated server can provide continuous integrated service so as to automatically generate the test data packet, so that man-machine interaction can be avoided, and the generation efficiency of the test data packet can be improved under the condition of no buttons. In addition, by automatically generating the test data packet in the continuous integrated server, direct data interaction between the target terminal (i.e. the development terminal) and the first service server (e.g. the WeChat server) can be avoided, so that decoupling cooperation can be fully exerted in the development process of the applet, and waste of development resources is avoided.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic structural diagram of a network architecture according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a data processing method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a scenario for on-demand pull provided in an embodiment of the present application;

FIG. 4 is a schematic flow chart of a continuous integration task according to an embodiment of the present application;

FIG. 5 is a schematic view of a scenario for generating installation anomaly log information provided by an embodiment of the present application;

FIG. 6 is a flowchart of another data processing method according to an embodiment of the present disclosure;

fig. 7 is a schematic diagram of a scenario of uploading a test data packet according to an embodiment of the present application;

fig. 8 is a schematic view of a scenario for collaborative development according to a plurality of development terminals according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;

fig. 10 is a schematic diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

Fig. 1 is a schematic structural diagram of a network architecture according to an embodiment of the present invention. As shown in fig. 1, the network architecture may include a target terminal 7000n, a service management server 6000, a persistent integrated server 2000, a first service server 4000, a first user terminal cluster, a second service server 5000 and a second user terminal cluster.

As shown in fig. 1, the first user terminal cluster may include a plurality of user terminals, and the plurality of user terminals may specifically include user terminals 3000a, … and user terminal 3000b shown in fig. 1; as shown in fig. 1, the user terminals 3000a, … and 3000b may be respectively connected to the first service server 4000 in a network manner, so as to enable data interaction in the first user terminal cluster through the first application server 4000.

Further, the network architecture may further include a second service server 5000 and a second user terminal cluster, where the second user terminal cluster may include a plurality of user terminals, as shown in fig. 1, and specifically may include user terminals 3000c, …, and user terminal 3000n; as shown in fig. 1, the user terminals 3000c, … and 3000n may be respectively connected to the second application server 5000 through a network, so as to enable data interaction in the second user terminal cluster through the second application server 5000.

The applications installed in each user terminal (e.g., user terminal 3000 a) in the first user terminal cluster may include a first application, which may be an instant messaging application. As shown in fig. 1, each user terminal in the first user terminal cluster may implement user data interaction with the first service server 4000 through an instant messaging platform in the first application.

Similarly, as shown in fig. 1, the applications installed in each user terminal (e.g., user terminal 3000 c) in the second user terminal cluster may include a second application, where the second application may be understood as an office application, and the office application may be referred to as another instant messaging application; as shown in fig. 1, each user terminal in the second user terminal cluster may implement user data interaction with the second service server 5000 through an instant messaging platform in the second application.

It can be appreciated that, according to the development framework of the first application (for example, the WeChat application), the embodiment of the application can provide a set of continuous integration platform for realizing automatic detection, automatic generation of the test data packet and automatic uploading of the test data packet for development of the applet.

As shown in fig. 1, the present application may introduce the persistent integration server 2000 in the development scenario of the applet, so as to modify the network architecture of the applet when developing the applet in the prior art, for example, at this time, a development terminal (for example, the target terminal 7000n shown in fig. 1) for performing applet development cannot directly perform data interaction with the persistent integration server 2000. Therefore, through the network architecture shown in fig. 1, the embodiment of the application can avoid the phenomenon that the first service server 4000 repeatedly receives a plurality of test data packets uploaded by a plurality of development terminals because the plurality of development terminals directly interact with the first service server 4000 in the development process of the applet, so that the waste of development resources can be avoided. In addition, the introduced continuous integration server 2000 can automatically compile and generate a test data packet under the condition of no button, and automatically upload the generated test data packet, so that the generation efficiency of the test data packet can be improved.

Among them, with the development of internet technology, an applet (Mini Program) is an application Program that can be used without downloading and installing. In order to provide more diversified business services to the user, a developer may develop a corresponding applet for an application (e.g., a first application, which may specifically include an instant messaging application, a shopping application, a mail application, etc.) of the terminal, which applet may be embedded as a sub-application into an application (i.e., a first application) of the terminal, and may provide the corresponding business service to the user by running the sub-application (i.e., the corresponding applet) within the first application.

For ease of understanding, the embodiment of the present application uses the first application as a WeChat application in the instant messaging application as an example, to illustrate a specific process of generating the test data packet by the continuous integration server 2000 shown in fig. 1 in the development scenario of the foregoing applet. In this embodiment, the servers for storing source codes (i.e., source strings) and for performing version management may be collectively referred to as a git server, which may be the service management server 6000 described in fig. 1. It should be understood that, in the process of version management, the service management server 6000 in the embodiment of the present application mainly performs hash calculation on the version information of the source code uploaded by the development terminal, so as to uniquely obtain a hash value that can be used to identify the version information of the source code. It should be understood that the number of development terminals having a network connection relationship with the service management server 6000 may be plural or one, and the number of development terminals will not be limited here.

The git server (i.e. the service management server 6000) may be configured to store the source code uploaded by each development terminal in a distributed manner, so that each development terminal may implement data sharing through the service management repository in the git server (i.e. the service management server 6000). Among other things, it should be appreciated that embodiments of the present application may refer to a business management repository on a git server as a remote repository. Furthermore, it can be appreciated that in the process of developing the project a created for the same applet, the decoupled collaboration (i.e., distributed development) between the multiple terminals can be facilitated by the git server, i.e., when it is determined that a new source code for the project a of the applet is acquired, synchronization of the new source code can be performed at each development terminal.

In order to facilitate distinguishing the source codes uploaded by each terminal, the embodiment of the present application may calculate, by using the git server, a hash value of version information corresponding to each source code, so as to obtain a hash value for uniquely identifying the version information of each source code. For example, taking the development terminal a and the development terminal B of the plurality of development terminals as an example, the git server may quickly calculate a hash value (for example, hash value 1) of version information of the source code 1 that the development terminal a newly developed for the project a, and may also obtain a hash value (for example, hash value 2) of version information of the source code 2 that the development terminal B newly developed for the project a. It should be appreciated that the persistent integration server according to the embodiments of the present application may verify the integrity of the acquired newly developed source code by using the hash value, so as to ensure the integrity of the target source code participating in the persistent integration task.

It is understood that the source code newly developed for a certain project may be referred to as a target source code or a target source string in the embodiments of the present application. For example, when the current time is T1, the embodiment of the present application may refer to the source code that is developed and uploaded by the development terminal a this time as a target source code (i.e., a target source string), and the source code that is developed and uploaded by the development terminal B at T2 (i.e., the time immediately before T1) as a history source code, and may also be referred to as a history source string. In addition, it may be understood that the development terminal a may synchronize, in advance, the source code uploaded by the development terminal B to the local repository 1 through the source code acquisition instruction on the foregoing service management repository (i.e., the remote repository) to store the source code, so that a developer may perform modification processing (for example, may perform a deletion operation of the source code, an addition operation of the source code, etc.) on the work file where the stored historical source string is located in the development terminal.

For ease of understanding, the embodiment of the present application takes one development terminal of a plurality of development terminals as an example, and the development terminal may be the target terminal 7000n shown in fig. 1. As shown in fig. 1, when a developer (for example, developer a) corresponding to the target terminal 7000n locally completes a change operation (for example, a delete operation, an add operation, a correct operation, etc.) for a work file to which the history source string belongs, a target source code corresponding to the change operation (i.e., the target source string n shown in fig. 1) may be submitted to the service management repository shown in fig. 1 for storage in the work file. It should be appreciated that when there is a target source string n submitted by the target terminal 7000n in the service management repository, the persistent integration server 2000 shown in fig. 1 may be notified of the synchronous update for the target source string n, i.e., the persistent integration server may pull the target source string n as needed from the service management repository when a commit notification (i.e., service commit notification information) is acquired.

It is appreciated that the persistent integration server 2000 may be used to provide persistent integration services for applets. In other words, the service management server 6000 may synchronize the history source character string with the continuous integration server 2000 shown in fig. 1 when synchronizing the history source character string with the target terminal 7000 n. Therefore, the aforementioned history source string may be stored in the local repository 2 of the continuous integration server 2000 shown in fig. 1. Further, it can be appreciated that when the persistent integration server 2000 pulls the target source string n from the service management repository shown in fig. 1, the incremental change attribute information corresponding to the target source string n may be obtained together. For example, the incremental change attribute information may specifically include: the source code is added to the working file in which the history source character string is located, and specific position information such as the source code is deleted in the line.

Further, the persistent integration server 2000 may automatically embed the target source string n in the corresponding position of the history source string according to the incremental change attribute information, so as to automatically compile according to the history source string embedded with the target source string n, so as to automatically generate the test data packet corresponding to the applet.

As shown in fig. 1, the persistence integration server 2000 can upload automatically generated test packets to the first service server 4000 shown in fig. 1. It should be appreciated that the first service server 4000 may be a background server corresponding to the aforementioned first application. For ease of understanding, the embodiment of the present application may take the first application as the foregoing instant messaging application, for example, the instant messaging application may be a micro-messaging application, where the first service server 4000 shown in fig. 1 may be a micro-messaging server. It will be appreciated that when the experience version of the developed applet is run in a user terminal (here, a test user terminal corresponding to the target test user) integrated with the micro-letter application, a corresponding business service may be provided through an experience data packet in the micro-letter server.

As shown in fig. 1, when a test data packet corresponding to the applet is obtained, the first service server 4000 may use the test data packet as an experience data packet and store the experience data packet, and further may issue a split identification image (e.g., a two-dimensional code) corresponding to the experience data packet to a target test user, so that the target test user may access an experience version of the applet by identifying the two-dimensional code in a test user terminal running a first application (e.g., the foregoing WeChat application), thereby enabling the experience version of the applet to be started in the first application.

It can be understood that, in the embodiment of the present application, the target test user may be a user corresponding to each of a plurality of user terminals in the first user terminal cluster shown in fig. 1. The plurality of user terminals in the first user terminal cluster may specifically be user terminal 3000a, fig. 1. In this embodiment of the present application, a user terminal corresponding to a specified user (i.e., the foregoing target test user) in the first user terminal cluster may be referred to as a test user terminal. In addition, it should be understood that, during the process of starting the applet in the first application, the corresponding test user terminal (for example, the user terminal 3000a shown in fig. 1) may obtain the experience data packet from the first service server 4000, so as to load the source code in the test data packet, and thus may provide the corresponding service for the target test user. For example, if the applet is a WeChat reading applet in a reading application applet, a reading service for electronic books in the WeChat reading applet may be provided to the target test user.

As shown in fig. 1, if the persistent integration server 2000 fails to compile in the process of executing the persistent integration task, the task state of the persistent integration task may be set to a failure state, and corresponding abnormal reminding information may be generated when the compilation fails, so that the abnormal reminding information may be pushed to the second service server 5000 shown in fig. 1, so that the second service server 5000 may find a group to which a developer participating in the development of the applet belongs, so as to perform abnormal reminding in an enterprise WeChat (i.e., a second application), thereby ensuring that corresponding developers in the group located in the enterprise WeChat may learn the abnormal reminding information. It will be appreciated that the second service server 5000 may be the second application (e.g., the enterprise micro messaging application in the another instant messaging application), which is not limited herein.

It should be understood that, the subsequent developer may further perform a new change operation on the working file containing the target source code locally in the development terminal, and may further submit a new target source string corresponding to the new change operation to the service management repository. Therefore, when the development task is completed, the development terminal in the embodiment of the application does not need to submit the whole working file of the project aiming at the applet, so that repeated submission of source codes in the development process can be avoided.

The specific processes of the persistent integration server 2000 obtaining the target source string and the incremental change attribute information corresponding to the target source string, and automatically generating and uploading the test data packet may be referred to as the implementation manners provided in the embodiments corresponding to fig. 2 to 8 below.

Further, please refer to fig. 2, which is a flowchart illustrating a data processing method according to an embodiment of the present application. The main implementation of the data processing method may be a persistent integration server, which may be the persistent integration server 2000 in the embodiment corresponding to fig. 1. As shown in fig. 2, the method provided in the embodiment of the present application may include:

Step S101, acquiring a target source character string associated with a business management warehouse and increment change attribute information corresponding to the target source character string;

specifically, in the development scenario of an applet, the continuously integrated server may be implemented in two ways: the latest source code (i.e., the target source string) is obtained from a service management repository (e.g., the remote repository described above in fig. 1) in either a pull-on-demand manner or a timed pull manner, and a continuous integration task can be performed in the continuous integration server for the currently obtained target source string. It can be understood that the persistent integration server can acquire the incremental change attribute information corresponding to the target source character string while acquiring the target source character string.

Wherein, the service management warehouse can be a code database (such as the git warehouse) used for data sharing in a service management server; the code database may contain service code data uploaded by at least one terminal associated with the applet; the service code data may include the target source character string uploaded by a target terminal in the at least one terminal and incremental change attribute information corresponding to the target source character string; the service management server may be configured to perform distributed storage on a target source string uploaded by the target terminal, and perform version management on version information of the target source string.

The service management repository may be a remote repository in the embodiment corresponding to fig. 1, where the remote repository may be a git repository corresponding to the git server. It will be appreciated that the git repository in the embodiments of the present application may be a storage device independent of the git server, alternatively, the git repository may be a storage device integrally installed in the git server, which will not be limited herein. It should be understood that the git repository may be configured to uniformly store the development data packet uploaded by each development terminal, where the development data packet may include the target source string (i.e., the target source code) uploaded by each development terminal and incremental change information corresponding to the target source string. In addition, the git warehouse can also be used for updating and processing the version information of the received data packet, namely, version management. For example, the git repository may be configured to hash the hash value of the version information corresponding to each received target source string (i.e., target source code) to create an index file for source code indexing in the git server by using the hash value with uniqueness.

The index file may record hash values corresponding to source codes submitted to the git repository each time, for example, hash value 1 corresponding to a target source code submitted this time (for example, a target source code submitted at a current time) may be recorded, and hash value 2 corresponding to a target source code submitted in history (for example, a target source code submitted at a previous time) may be recorded. For example, the history source character string corresponding to the corresponding version information submitted by the target terminal in the past can be quickly obtained from the git warehouse through the index file, and then version rollback can be performed through a version rollback instruction. In this embodiment of the present application, the object source code submitted by the history may be collectively referred to as the history source code, and the history source code may also be referred to as a history source string.

In other words, the git repository described in the embodiments of the present application may be understood as a hosting tool capable of performing distributed storage on the obtained target source code, and through the git repository, version management and distributed development can be performed on the source code submitted in the applet development process conveniently. The distributed development refers to the development terminals having a network connection relationship with the service management server, and the data sharing function can be realized through a git warehouse, for example, the git warehouse can ensure that each developer can obtain the latest updated source code from the git warehouse according to a source code pulling instruction (for example, a "fetch command" in a git command), so that distributed development can be performed on the projects in the respective development terminals. It may be understood that the persistent integration server may also capture data that is not in the local repository of the persistent integration server from the remote repository (i.e. the git repository) by invoking the "fetch command", so that the latest updated target source string on the git repository may be captured locally (i.e. the local repository of the persistent integration server), and further step S102 may be performed to perform the persistent integration task in the persistent integration server.

The pull-on-demand manner refers to that when the persistent integration server obtains the service submission notification information actively sent by the service management server (i.e., the git server) corresponding to the service management repository, the last uploaded source code (i.e., the target source string) of a developer (e.g., the developer a) is pulled from the git server. Specifically, the continuous integration server may acquire service submission notification information sent by the service management server corresponding to the service management repository for the target source character string; the service submission notification information comprises a hash value of version information corresponding to the target source character string; further, the persistent integration server may pull the target source string and the incremental change attribute information corresponding to the target string from the service management repository according to the hash value.

For ease of understanding, further, please refer to fig. 3, which is a schematic view of a scenario for on-demand pulling according to an embodiment of the present application. The service management server shown in fig. 3 may generate, when detecting that the target source string in the development data packet that is newly uploaded by the development terminal (i.e., the service management repository shown in fig. 3) is added to the git repository (i.e., the service management repository shown in fig. 3), service submission notification information shown in fig. 3 may be generated based on a hash value of version information corresponding to the target source string (for example, the hash value may be a string with a fixed length, for example, a string with 16 bits in a 16-ary representation), where the service submission notification information is used to notify the persistent integration server shown in fig. 3 to perform pull-on-demand, for example, the persistent integration server may quickly index the target source string stored in the service management repository shown in fig. 3 to the target source string in the local repository of the persistent integration server based on the hash value of the target source string, so that the persistent integration server may perform hash verification, and may determine that the hash value of the current-captured target source string is not consistent with the hash value of the last-captured target source string (i.e., the hash value of the last-captured target source string) according to the history information, and the incremental change history information is determined. The service submission notification information may include a hash value of version information corresponding to the target source string; it will be appreciated that the hash value may be used to uniquely identify version information of the target source string stored in the git repository (i.e., the aforementioned git repository). In other words, as shown in fig. 3, the persistent integration server may accurately pull the target source string from the service management repository according to the hash value corresponding to the target source string, and obtain the incremental change attribute information corresponding to the target string while obtaining the target source string.

It may be understood that, in the embodiment of the present application, the source code in the data packet received by the service management server each time may also be referred to as a source string. In this embodiment of the present application, the source string submitted and uploaded by the target terminal at the current moment may be referred to as a target source string, where the target source string may be the target source code in the embodiment corresponding to fig. 1. In addition, the source string submitted to be uploaded by the target terminal at the previous time may be referred to as a history source string, where the history source string may be the history source code in the embodiment corresponding to fig. 1.

It should be understood that the timing pull mode refers to that the continuous integration server can be used to determine whether the current time reaches the timing pull duration, and can pull the target source character string uploaded by the developer up-to-date from the git server (i.e. the service management server) at fixed time when the current time is determined to reach the timing pull duration. In other words, when the current duration reaches the timing pull duration, the continuous integration server acquires a source code pull instruction for the target source string (i.e. automatically invokes a source code acquisition instruction corresponding to the target source string, where the source code acquisition instruction may be a git command in the embodiment corresponding to fig. 1); further, the persistent integration server may pull the target source string and the incremental change attribute information corresponding to the target string from the service management repository (e.g., the service management repository in the embodiment corresponding to fig. 3) according to the source code pulling instruction.

The applet developed in the embodiment of the present application may be the applet described in the embodiment corresponding to fig. 1. The applet may specifically include at least one applet, such as an electronic reading applet, an entertainment application applet, a shopping application applet, etc., which will not be limited herein. It should be understood that in the development process of the applet, the continuous integration server may be introduced to perform automatic compiling, and when the compiling is successful, the test data packet obtained after automatic compiling is automatically given to the micro-letter server, so that the micro-letter server may take the test data packet as an experience data packet, and then may push the experience data packet to the target test user for experience.

Step S102, embedding the target source character string into the history source character string according to the increment change attribute information, and generating a test data packet corresponding to the applet according to the history source character string embedded with the target source character string.

Specifically, the continuous integration server may embed the target source string into the history source string according to the incremental change attribute information, and generate a data packet to be compiled corresponding to the applet according to the history source string in which the target source string is embedded; further, the continuous integration server may compile the data packet to be convenient according to the dependency data file corresponding to the applet, and obtain the test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

It will be understood that, as shown in fig. 3, the target source code uploaded to the service management repository by the developer a may be obtained after the developer a changes the working file to which the history source string belongs. For example, if the developer a adds several lines of source codes a in the working file to which the history source string belongs (for example, the lines of source codes a may be the target source string shown in fig. 3), the target source codes received by the service management repository shown in fig. 3 may be the lines of source codes a modified by the developer a, and the portions (for example, the history source string) that are not modified in the working file may not be uploaded. As shown in fig. 3, the development data packet uploaded by the developer a through the target terminal may include the lines of source code a.

In addition, since the service management repository shown in fig. 3 has a function of data sharing, the target source strings pulled by the continuous integration server in the embodiment of the present application from the service management repository may be several lines of source codes a submitted by the developer a. In addition, in the development scenario of the applet, in order to add the functions of the operation controls corresponding to the lines of source codes a to the applet of the previous version, the persistent integration server may acquire the target source codes a submitted recently from the foregoing service management server when starting the persistent integration service of the applet, and may further perform the persistent integration task on the lines of source codes a (i.e., the target source codes). Wherein the persistent integration task may include a plurality of subtasks; the plurality of subtasks may specifically include: automatically detecting subtasks, automatically installing subtasks, automatically compiling subtasks and automatically uploading subtasks.

The automatic detection subtask means that the continuous integration server can automatically detect whether the target source character string is successfully pulled in the process of pulling the target source character string. For example, when the hash value of the target source character string pulled from the service management warehouse (i.e. the remote warehouse) is compared with the hash value in the local warehouse, the target source character string can be successfully pulled when the hash value is different from the hash value in the local warehouse, the pulled target source character string can be embedded into the corresponding position of the history source character string, the data packet to be compiled corresponding to the applet can be obtained, and then the automatic installation subtask can be continuously executed. However, the continuous integration server may further generate abnormal pull log information corresponding to the target source string when the code pull fails (for example, when the network is abnormal or the service management server is down to cause an abnormal service management warehouse), and may perform log analysis on the abnormal pull log information to determine an abnormal pull factor, so as to generate first abnormal reminding information corresponding to the applet based on the determined abnormal pull factor.

The automatic installation subtask means that when the continuous integration server obtains the data packet to be compiled, the continuous integration server can automatically install the third-party dependency packet according to configuration information associated with the target source character string in the data packet to be compiled, and when the third-party dependency packet is successfully installed, a dependency data file for compiling the data packet to be compiled is obtained. At this time, the persistent integration server may use a class library (i.e., a third party class library, such as a public class library and an application class library) provided by a third party in the dependency data file corresponding to the third party dependency package to code the data package to be compiled, so that an automatic compiling subtask may be automatically executed subsequently.

The automatic compiling subtask means that the continuous integrating server can divide the data packet to be compiled into N sub-packets through a sub-packet mechanism in the process of compiling codes of the data packet to be compiled. For example, the persistent integration server needs to divide the data packet to be compiled corresponding to the applet into different sub-packets, so that different sub-packets can be obtained when the applet is constructed, and thus, a subsequent user can load the applet as required when using the developed applet (for example, an experience version of the applet) so as to improve the page loading efficiency of the applet. It should be understood that, in the embodiment of the present application, the first data packet and the second data packet obtained based on the packetizing mechanism may be collectively referred to as a test data packet of the applet, where the first data packet may be a main packet of the N packetizes, and the main packet may include source code for loading a main page of the applet. Wherein N is a positive integer.

It should be appreciated that in constructing a subcontracting item (simply called a subcontracting) of an applet, one or more subcontracts may be available, and the number of subcontracts will not be limited here. However, one main package may be included in N sub-packages constructed based on the sub-package mechanism in the continuous integration server. It should be appreciated that the main package in embodiments of the present application may contain pages associated with the main page of the applet, such as a place default launch page, a toolbar (TabBar) page, and some subcontracts that all require use of common resources/JS scripts. It can be understood that when the applet is started, the main package is downloaded by default and the page in the main package is started, and when the user enters a certain page in the sub package, the client downloads the corresponding sub package, and the download is completed and then displayed.

Wherein the packetization mechanism means that the persistent integration server needs to ensure that the entire applet does not have all packetization sizes exceeding a first threshold (e.g., 8M) and that the size of individual packetization or main packetization cannot exceed a second threshold (e.g., 2M). For example, the sub-packet 1 corresponding to the page a and the sub-packet 2 corresponding to the page B may be in the same sub-packet (e.g., main packet), and if the total pre-download size of the sub-packet 1 corresponding to the page a is 0.5M, the total pre-download size of the sub-packet 2 corresponding to the sub-packet B may be determined to be less than or equal to 1.5M according to the sub-packet mechanism. It should be appreciated that by subcontracting the applet, the embodiments of the present application may effectively optimize the download time for the initial start of the applet, and may better perform the decoupling collaboration when the applet is developed by multiple teams together.

For ease of understanding, further, please refer to fig. 4, which is a schematic flow chart for performing the continuous integration task according to an embodiment of the present application. As shown in fig. 4, when the persistent integration task is started, the persistent integration server may perform step 10 in two manners (i.e., manner a and manner B) shown in fig. 4, so as to obtain the target source string submitted by the developer recently from the git repository corresponding to the service management server (i.e., the git server) having the network connection relationship with the persistent integration server.

Specifically, for example, for the mode a shown in fig. 4, when the persistent integration server is started, the persistent integration server may execute a timing pull task to trigger a timer, so that a timing pull function may be implemented by the timer, in other words, the persistent integration server may determine whether the current time reaches a timing pull duration (for example, 4 hours) through the timer, and if the current time reaches the timing pull duration, the latest submitted source code on the git repository may be pulled, that is, the latest target source string may be pulled from the service management repository.

Alternatively, for example, for the mode B shown in fig. 4, the persistent integration server may perform the pull task as required when the persistent integration server is started, and at this time, the git server may also generate the service submission notification information when acquiring the latest target source string (i.e. the latest target source code) uploaded by the development terminal, so that the persistent integration server may be actively notified to pull the latest target source code. In other words, the git server in the embodiment of the present application may trigger to generate a code submission notification (the embodiment of the present application may refer to the code submission notification as the service submission notification information described above) when detecting the latest target source code uploaded by the developer, and send the code submission notification to the persistent integration server, so that the persistent integration server may pull the latest target source code uploaded by the developer from the git repository.

As shown in fig. 4, after the step 10 is performed, the persistent integration server may further perform step 20 to perform the above-mentioned automatic detection subtask to determine whether the latest target source string is successfully pulled, and if it is determined that the latest target source string is pulled, it may be determined that the target string does not meet the abnormal pulling condition, and then step 30 may be performed; otherwise, it is determined that the target source string meets the abnormal pulling condition, for example, in the time pulling duration, the developer does not upload the developed target source string, so that when the current time reaches the time pulling duration, the continuous integration server cannot acquire the latest target source string from the git warehouse, for example, when the latest target source string corresponding to the previous version is acquired from the git warehouse, it may be determined that the pulled target source string meets the abnormal pulling condition. Optionally, when an abnormality exists in the network between the continuous integration server and the git server or the git server is down, the continuous integration server cannot acquire the latest target source character string from the git warehouse, so that it can be determined that the pulled target source character string meets the abnormal pulling condition.

In other words, the persistent integration server may detect the pulled code when it is pulled, to detect if the pulled code is problematic (i.e., if the above-described exception pull condition is met). For another example, if there is a code pull failure, such as: if the code pulling fails due to an abnormal pulling factor such as a network abnormality or a git warehouse abnormality, step 90 shown in fig. 4 may be skipped to execute, that is, when it is detected that the target source string meets the abnormal pulling condition, an error log (for example, abnormal pulling log information) may be generated, so that an error cause (that is, at least one abnormal pulling factor may be obtained) may be analyzed in the persistent integrated server according to the error log, and thus error alert information (for example, first abnormal alert information) may be generated according to the error cause obtained by the analysis. As shown in fig. 4, when the persistent integration server performs step 100, it may determine whether the foregoing error cause is related to code submission, and if it is determined that the error cause is not related to code submission, it may jump to step 120 to issue error information as anomaly alert information to the enterprise micro-community; for example, in the process of pulling the target source character string, if it is determined that the abnormal pulling factor includes any one of network abnormality and a git server downtime, it may be determined that the current error cause belongs to an environmental abnormality factor, that is, does not belong to a code abnormality factor related to code submission.

As shown in fig. 4, the continuous integration server may perform an automatic install subtask through steps 30-40 after performing step 20. It may be appreciated that, after the data packet to be encoded is obtained through the above step 20, the persistent integration server may install a third party dependency packet according to configuration information in the data packet to be encoded, so that the target source string may be run through a third party class library provided by the third party dependency packet when the data packet to be encoded is compiled later. As illustrated in fig. 4, the continuous integration server may further perform step 50 upon completing the installation of a third party dependent package (also referred to as a dependent data package or a third party installation package).

It can be understood that, in the process of installing the third party dependent package, whether the installation is successful is further determined by step 40, and if the installation fails (for example, the third party dependent package cannot be obtained due to a network anomaly or the installation fails due to the third party dependent package anomaly), the continuous integration server may jump to step 90. At this time, since the network anomaly or the third party dependent packet anomaly belongs to the above environmental anomaly factor, the continuous integration server may continue to perform step 120 after performing step 100.

For ease of understanding, further, please refer to fig. 5, which is a schematic diagram of a scenario for generating installation anomaly log information according to an embodiment of the present application. The persistent integration server as described in fig. 5 may determine whether the installation of the third party dependency package is completed when the step 40 is completed, and if not, may generate the installation exception log information shown in fig. 5 when the installation state of the dependency data package (i.e., the third party dependency package) is a failure state; and further, error analysis can be performed on the installation anomaly log information to determine corresponding installation anomaly factors, and installation error prompt information can be generated based on the installation anomaly factors associated with the installation anomaly log information. As shown in fig. 5, when determining that the installation anomaly factor associated with the installation anomaly log information belongs to an environmental anomaly factor (i.e., when determining that the error root code is not related to the submission in step 100 above), the persistent integration server may execute step 120 above to display, in the target terminal (i.e., the development terminal) shown in fig. 5, first-type anomaly alert information corresponding to the applet, where the first-type anomaly alert information may be the installation error alert information generated based on the installation anomaly factor.

Optionally, if the persistent integration server detects that the version of the third party dependency package declared in the dependency data file associated with the target source string submitted at this time does not exist or the name of the third party dependency package is wrong, the third party dependency package cannot be installed, so that the installation of the third party dependency package fails, and the persistent integration server may jump to execute step 90. At this time, since the version of the third party dependency package declared in the dependency data file by the developer (for example, the developer a described above) does not exist or the installation abnormality factor such as a name error belongs to the code abnormality factor. Therefore, after the step 100 is performed, the continuous integration server may continue to perform the step 110 to obtain the code submission record corresponding to the target source character string and the developer information associated with the code submission record, so that the code submission record and the developer information may be supplemented to the installation error prompt information, and the supplemented installation error prompt information may be used as the second type of abnormality prompt information corresponding to the applet. In other words, as shown in fig. 4, after the step 110 is performed, the persistent integration server may continue to step 120 to supplement the installation error prompt information with the code submission record submitted by the developer a and the developer information of the developer a (for example, the group of the project to which the developer a belongs in the development process of the applet and the account information of the developer in the second application) so as to push the supplemented installation error prompt information to the second service server (i.e., the enterprise micro-letter server) corresponding to the second application (e.g., the enterprise micro-letter), so that the second service server may notify the development group (for example, the group K in the embodiment corresponding to fig. 5) where the developer a is located of the second class of the abnormality prompt information, that is, may issue the supplemented installation error prompt information to the group K associated with the applet, thereby implementing alarm processing in the micro-letter.

As shown in fig. 5, after the continuous integration server performs the step 40, the continuous integration server further performs an automatic compiling subtask through a step 50, and it can be understood that, in the process of performing automatic compiling, the continuous integration server may perform a packetizing process on a data packet to be compiled through a packetizing mechanism.

As shown in fig. 4, after the step 50 is performed, the continuous integration server may continue to step 60 to determine whether the compilation is successful, and if so, may jump to step 70, where the step 70 may be the following step S103; otherwise, the process may jump to step 90. Immediately, the compiling error factor determined in the process of compiling the compiling data packet may include a static syntax error, for example, a compiling failure caused by a problem of the target source code uploaded by the developer, and at this time, the persistent integration server may generate the second exception reminding information corresponding to the applet according to the static syntax error, so that the exception alarm may be implemented through the steps 100, 110 and 120. In other words, the method for performing the abnormality alert in the embodiment of the present application is the same as the alert method of the second type abnormality alert information generated according to the code abnormality factor, and will not be described in detail here.

Step S103, the test data packet is sent to a first service server corresponding to the first application, so that the first service server distributes the test data packet to a target test user.

Specifically, the continuous integration server may acquire, on a continuous integration platform corresponding to the applet, a target interface provided by the continuous integration platform; the target interface includes an IDE interface associated with the applet; further, the persistent integration server may invoke the IDE interface to upload the test packet emulation to a first service server corresponding to the first application. When the first application is a micro-message application in the instant messaging application, the first service server may be a background server corresponding to the micro-message application.

It may be appreciated that, after the step S102 is performed, the embodiment of the present application may further perform step S103 to implement automatic uploading of the test data packet in the persistent integration server, so that automatic uploading of the test data packet in the persistent integration server may be performed without a button (e.g., without a compiling button and an uploading button).

As shown in fig. 4, step 103 of the persistent integration server may perform an automatic upload subtask through step 70, that is, the persistent integration server may call a target interface (i.e., IDE interface) provided by a developer tool in the persistent integration platform, and automatically upload the test packet after compiling successfully to the WeChat server (i.e., the first service server). It may be appreciated that, as shown in fig. 4, after the step 70 is performed, the continuous integration server may further perform step 80 to determine whether the response text information returned by the micro-letter server can be received within a preset response time period, and if the response text information is received, it is determined that the uploading of the test data packet is completed, where the single integration for the current target source character string may be completed in the continuous integration server.

Optionally, as shown in fig. 4, the continuous integration server may further generate exception uploading log information when no response text information returned by the WeChat server is obtained, and may generate third exception reminding information corresponding to the applet according to an exception uploading factor in the exception uploading log information. The exception uploading factors may specifically include: 1) Network anomalies; 2) The WeChat server is abnormal; 3) The compiled code does not conform to the applet specification (e.g., is too bulky, exceeding 2M; lack of necessary files, etc.). The exception uploading factor 1 and the exception uploading factor 2 belong to environmental exception factors, and at this time, the specific process of the third exception reminding information generated by the continuous integration server can refer to the description of the first type exception reminding information in the embodiment corresponding to fig. 5, and will not be described in detail here. In addition, since the exception uploading factor 3 belongs to a code exception factor, at this time, the specific process of the third exception reminding information generated by the continuous integration server may refer to the description of the second type exception reminding information, and will not be further described herein.

It should be understood that, after the first application server receives the test data packet of the applet, the test data packet may be used as an experience data packet, so that a two-dimensional code corresponding to the experience data packet may be generated, so that, based on account information of a target test user in the first application bound in the applet development process, the two-dimensional code may be pushed to the target test user corresponding to the account information, so that the target test user may experience, through the two-dimensional code, a service provided by the applet that is newly developed. It should be appreciated that during applet development, the applets obtained by these targeted test users are applets that carry the targeted identifications (e.g., carry the experience identifications).

It can be understood that the applet in the embodiment of the present application may be developed under the micro-letter framework of the micro-letter application (i.e. the first application), so that the test data packet finally generated by the continuous integration server may be uploaded to the micro-letter server (i.e. the first service server) so that the target test user using the micro-letter application may experience the service provided by the newly developed applet carrying the experience identifier. For example, taking a developed applet as an example of a video application applet, a developer may add a video playing plug-in to a previously developed video application applet, so that when a target test user specified by the developer uses the video application applet in a first application (i.e., a WeChat application), the developer may experience service functions provided by the newly added video playing plug-in.

Further, please refer to fig. 6, which is a flowchart illustrating another data processing method according to an embodiment of the present application. As shown in fig. 6, the method at least may include:

step S201, when the current time length reaches the time length of pulling at fixed time, a source code pulling instruction aiming at a target source character string is obtained;

step S202, pulling the target source character string and the increment change attribute information corresponding to the target character string from the business management warehouse according to the source code pulling instruction;

it can be understood that, in the embodiment of the present application, the user description duration integration server in step S102 and step S103 may obtain, from the service management repository, the target source string that is updated and uploaded by the development terminal in a timing pull manner. It should be understood that after the persistent integration server takes the target source string uploaded by the development terminal, it may further jump to execute step S203 to execute the persistent integration task through the persistent integration service provided by the execution integration server. The continuous integration task may include the automatic detection subtask, the automatic installation subtask, the automatic compiling subtask, the automatic uploading subtask, and the like.

Step 203, embedding the target source character string into the history source character string according to the increment change attribute information, and generating a data packet to be compiled corresponding to the applet according to the history source character string embedded with the target source character string;

specifically, the continuous integration server may perform anomaly detection on the target source character string; further, when the continuous integration server detects that the target source character string does not meet an abnormal pulling condition, determining position information of the target source character string in the historical source character string according to the increment change attribute information; further, the persistent integration server may embed the target source string into the history source string based on the location information, and use the history source string embedded with the target source string as the data packet to be compiled corresponding to the applet.

And step S204, compiling the data packet to be convenient according to the dependent data file corresponding to the applet, and obtaining the test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

Specifically, the continuous integration server may obtain a dependency data packet associated with the data packet to be compiled, and obtain a dependency data file for compiling the data packet to be compiled when the installation state of the dependency data packet is a successful state; further, the continuous integration server may code-compile the data packet to be compiled according to a third party class library provided in the dependency data file, and obtain a packetizing mechanism corresponding to the applet; further, the persistent integration server may divide the data packet to be compiled into N packets based on the packetization mechanism; n is a positive integer; the N subpackets comprise a first data packet associated with a main page of the applet and a second data packet associated with a sub page of the applet; further, the persistent integration server may obtain, based on the first data packet and the second data packet, a test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

Step S205, the test data packet is sent to a first service server corresponding to the first application.

Specifically, the continuous integration server may acquire, on a continuous integration platform corresponding to the applet, a target interface provided by the continuous integration platform; the target interface includes an IDE interface associated with the applet; further, the persistent integration server may invoke the IDE interface to upload the test packet emulation to a first service server corresponding to the first application.

Step S206, if the response text information returned by the first service server for the test data packet is obtained in the response time length, the uploading of the test data packet is determined to be completed;

for easy understanding, further, please refer to fig. 7, which is a schematic diagram of a scenario for uploading a test data packet according to an embodiment of the present application. As shown in fig. 7, the persistent integration server may obtain the test packet shown in fig. 7 when the data packet to be tested is successfully compiled, where the test packet is determined by dividing the data packet to be compiled based on the packetizing mechanism. As shown in fig. 7, the first service server (e.g., a WeChat server) may generate response text information for the test data packet when acquiring the test data packet uploaded by the persistent integration server, so that the persistent integration server may end a single integration for the target source string based on the response text information. In addition, the first service server (i.e. the WeChat server) shown in fig. 7 may further use the test data packet as an experience data packet, and further may generate an experience invitation notification for the experience data packet, so that the target test user associated with the applet may obtain the experience invitation notification through the public number (or subscription number, etc.) corresponding to the first application shown in fig. 7.

For ease of understanding, the terminal corresponding to the target test user may be referred to as a test user terminal shown in fig. 7 in this embodiment of the present application, and it may be understood that the test user terminal in this embodiment of the present application may be any one of the user terminals in the first user terminal cluster in the embodiment corresponding to fig. 1 (for example, the user terminal 3000a shown in fig. 1). As shown in fig. 7, when the target test user (e.g., test user K) corresponding to the test user terminal acquires the experience invitation notification, a trigger operation may be performed for the experience invitation notification, so as to display an identification image corresponding to the applet in the session interface shown in fig. 7 and including the public number corresponding to the first application (e.g., AAAA shown in fig. 7). It can be understood that, in this embodiment of the present application, the identity image is taken as an example of a two-dimensional code, so that the test user K may obtain the experience data packet in the session interface by long pressing the area where the two-dimensional code is located, so that an experience version of the applet may be started in the first application, so that an application display interface corresponding to the applet may be accessed through the experience data packet, and thus the service function newly added for the applet may be experienced in the corresponding application display interface.

Optionally, step S207 is configured to generate exception uploading log information if no response text information returned by the first service server is obtained within the response time period, generate third exception reminding information corresponding to the applet according to exception uploading factors in the exception uploading log information, and send the third exception reminding information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application.

For easy understanding, further, please refer to fig. 8, which is a schematic view of a scenario for collaborative development according to a plurality of development terminals according to an embodiment of the present application. Each of the development terminals 10a, 10n of development china as shown in fig. 8 may submit a corresponding source code to the business repository shown in fig. 8. For example, developer 1 shown in FIG. 8 may develop for plug-in A for the applet and developer n may develop for plug-in B for the applet. Therefore, as shown in fig. 7, the development terminal 10a corresponding to the developer 1 may upload the source code 1 for the plug-in a to the service management repository 20 corresponding to the service management server, and similarly, the development terminal 10n corresponding to the developer 2 may upload the source code n for the plug-in B to the service management repository 20 corresponding to the service management server. At this time, when the current time reaches the time pull duration, the persistent integration server 30 shown in fig. 8 may perform the persistent integration service on the source code uploaded by the two development terminals (in this case, the source code is the target source code).

Optionally, as shown in fig. 8, the service management server may further generate service submission notification information (i.e. the submission notification shown in fig. 8) for the two target source codes when detecting that a new target source character string exists in the service management repository shown in fig. 8, and further may pull two target source character strings from the service management repository shown in fig. 8 when the persistent integration server 30 shown in fig. 8 obtains the submission notification shown in fig. 8, so that a persistent integration task may be performed on the two target source character strings in the persistent integration server 30 (for example, a persistent integration task may be performed for two different plugins successively, or a persistent integration task may be performed for the two plugins simultaneously, which will not be limited herein). It should be understood that, in the embodiment of the present application, a specific implementation manner of performing the persistent integration task for two target source strings may be referred to the description of the persistent integration task in the embodiment corresponding to 4 above. Therefore, as shown in fig. 8, the persistent integration server may upload the generated test packet to the first service server 40b (e.g., the above-mentioned WeChat application) shown in fig. 8 when the compiling is successful. Conversely, when the compiling fails, the error prompt information shown in fig. 8 may be given to a second service server (for example, an enterprise WeChat server), so that an abnormal alarm in the enterprise WeChat (i.e., the second application) can be implemented by the enterprise WeChat server.

Further, please refer to fig. 9, which is a schematic diagram illustrating a structure of a data processing apparatus according to an embodiment of the present application. As shown in fig. 9, the data processing apparatus 1 may be applied to the persistent integration server 2000 in the embodiment corresponding to fig. 1. The data processing apparatus 1 may comprise: a character string acquisition module 10, a character string embedding module 20, a data packet transmission module 30; further, the data processing apparatus 1 may also respond to the acquisition module 40 and the abnormality uploading module 50;

a character string obtaining module 10, configured to obtain a target source character string associated with a service management repository and incremental change attribute information corresponding to the target source character string; the target source character string is determined by the target terminal after changing the history source character string corresponding to the applet associated with the first application;

wherein, the character string acquisition module 10 includes: a notification acquisition unit 101, a first acquisition unit 102; optionally, an instruction fetch unit 103, a second fetch unit 104;

a notification obtaining unit 101, configured to obtain service submission notification information sent by a service management server corresponding to the service management repository for a target source string; the service submission notification information comprises a hash value of version information corresponding to the target source character string;

And the first obtaining unit 102 is configured to pull the target source string and incremental change attribute information corresponding to the target string from the service management repository according to the hash value.

Optionally, the instruction obtaining unit 103 is configured to obtain a source code pulling instruction for the target source string when the current duration reaches the timing pulling duration;

and the second obtaining unit 104 is configured to pull the target source character string and incremental change attribute information corresponding to the target character string from the service management repository according to the source code pulling instruction.

It can be understood that, in the process of pulling the target source character string, the data processing apparatus 1 may pull the target source server from the service management repository by the notification acquisition unit 101, where the instruction acquisition unit 103 is not used, and the second acquisition unit 104 performs timing pulling; alternatively, the data processing apparatus 1 does not use the notification acquisition unit 101 when the second acquisition unit 104 periodically pulls the target origin server from the service management repository through the instruction acquisition unit 103, and the first acquisition unit 102 performs pull-on-demand.

The character string embedding module 20 is configured to embed the target source character string into the history source character string according to the incremental change attribute information, and generate a test data packet corresponding to the applet according to the history source character string into which the target source character string is embedded;

wherein, the string embedding module 20 includes: a character embedding unit 201, a compiling processing unit 202;

a character embedding unit 201, configured to embed the target source string into the history source string according to the incremental change attribute information, and generate a data packet to be compiled corresponding to the applet according to the history source string into which the target source string is embedded;

Wherein the character embedding unit 201 includes: an anomaly detection subunit 2011, a location determination subunit 2012, a character embedding subunit 2013, and optionally, the character embedding unit 201 further includes a first log generation subunit 2014, a first anomaly alert subunit 2015, and a first alert pushing subunit 2016;

an anomaly detection sub-sheet 2011, configured to perform anomaly detection on the target source character string;

a location determining subunit 2012 configured to determine, when it is detected that the target source string does not satisfy the abnormal pull condition, location information of the target source string in the history source string according to the incremental change attribute information;

and a character embedding subunit 2013, configured to embed the target source string into the history source string based on the location information, and use the history source string embedded with the target source string as a data packet to be compiled corresponding to the applet.

Optionally, the first log generation subunit 2014 is configured to generate, when it is detected that the target source string meets the abnormal pull condition, abnormal pull log information corresponding to the target source string;

a first abnormality alert subunit 2015, configured to generate first abnormality alert information corresponding to the applet according to at least one abnormality pulling factor in the abnormality pulling log information;

A first alert pushing subunit 2016, configured to push the first abnormal alert information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application; the group includes at least one development user that participates in developing the applet.

The abnormality detection subunit 2011, the location determination subunit 2012, the character embedding subunit 2013, and optionally, the character embedding unit 201 further includes a first log generation subunit 2014, a first abnormality alert subunit 2015, and a specific implementation manner of the first alert pushing subunit 2016 may refer to the description of the pulled target source character string in the embodiment corresponding to fig. 2, which will not be further described herein.

And the compiling processing unit 202 is configured to compile the to-be-facilitated data packet according to the dependency data file corresponding to the applet, and obtain a test data packet corresponding to the applet when the compiling state of the to-be-compiled data packet is a successful state.

Wherein the compiling processing unit 202 includes: a dependency acquisition subunit 2021, a compilation subunit 2022, a packetization subunit 2023, a test packet generation subunit 2024; optionally, the compiling processing unit 202 may further include: a second log generation subunit 2025, an installation error subunit 2026, a character-irrelevant subunit 2027, a character-relevant subunit 2028; a compile error subunit 2029, a second anomaly alert subunit 2030, and a second alert push subunit 2031;

A dependency acquisition sub-list 2021, configured to acquire a dependency data packet associated with the data packet to be compiled, and obtain a dependency data file for compiling the data packet to be compiled when an installation state of the dependency data packet is a successful state;

a compiling subunit 2022, configured to code-compile the data packet to be compiled according to a third party class library provided in the dependency data file, and obtain a packetizing mechanism corresponding to the applet;

a packetizing subunit 2023, configured to divide the data packet to be compiled into N packetizes based on the packetizing mechanism; n is a positive integer; the N subpackets comprise a first data packet associated with a main page of the applet and a second data packet associated with a sub page of the applet;

and a test packet generating subunit 2024, configured to obtain, when the compiling state of the data packet to be compiled is a successful state, a test data packet corresponding to the applet based on the first data packet and the second data packet.

Optionally, the second log generating subunit 2025 is configured to generate installation exception log information when the installation status of the dependent data packet is a failure status;

An installation error sub-unit 2026 for generating installation error prompt information based on the installation abnormality factors associated with the installation abnormality log information;

a character-independent subunit 2027, configured to take the installation error prompt information as first type abnormality alert information corresponding to the applet if the installation abnormality factor belongs to an environmental abnormality factor that is independent of the target source character string;

and a character-related subunit 2028, configured to, if the installation anomaly factor belongs to a code anomaly factor related to the target source string, obtain a code submission record corresponding to the target source string and developer information associated with the code submission record, supplement the code submission record and the developer information to the installation error prompt information, and use the supplemented installation error prompt information as a second type of anomaly prompt information corresponding to the applet.

Optionally, the compiling error subunit 2029 is configured to generate compiling error log information corresponding to the data packet to be compiled when the compiling state of the data packet to be compiled is a failure state, and perform error analysis on the compiling error log information to obtain a compiling error factor corresponding to the data packet to be compiled; the compiling error factor comprises a static grammar error corresponding to a target source character string in the data packet to be compiled;

A second anomaly alert subunit 2030, configured to generate second anomaly alert information corresponding to the applet based on the static syntax error;

a second alert pushing subunit 2031, configured to send the second abnormal alert information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application.

Wherein, the dependency acquisition subunit 2021, the compiling subunit 2022, the packetizing subunit 2023, the test packet generation subunit 2024, the second log generation subunit 2025, the installation error subunit 2026, the character-irrelevant subunit 2027, the character-relevant subunit 2028; the compiling error subunit 2029, the second anomaly alert subunit 2030, and the specific implementation manner of the second alert pushing subunit 2031 may refer to the description of generating the test data packet in the embodiment corresponding to fig. 2, which will not be further described herein.

The specific implementation manner of the character embedding unit 201 and the compiling unit 202 may refer to the description of step S102 in the embodiment corresponding to fig. 2, and the description will not be repeated here.

And the data packet sending module 30 is configured to send the test data packet to a first service server corresponding to the first application, so that the first service server distributes the test data packet to a target test user.

Wherein, the data packet sending module 30 includes: an interface acquisition unit 301, a packet uploading unit 302;

an interface obtaining unit 301, configured to obtain, on a continuous integration platform corresponding to the applet, a target interface provided by the continuous integration platform; the target interface includes an IDE interface associated with the applet;

and the data packet uploading unit 302 is configured to invoke the IDE interface to simulate and upload the test data packet to a first service server corresponding to the first application.

The specific implementation manner of the interface obtaining unit 301 and the data packet uploading unit 302 may refer to the description of step S103 in the embodiment corresponding to fig. 2, and the description will not be repeated here.

The specific implementation manner of the string obtaining module 10, the string embedding module 20, and the packet sending module 30 may refer to the description of step S101 to step S103 in the embodiment corresponding to fig. 2, and the description will not be repeated here.

A response obtaining module 40, configured to determine that the uploading of the test data packet is completed if response text information returned by the first service server for the test data packet is obtained within a response time period;

the exception uploading module 50 is configured to generate exception uploading log information if response text information returned by the first service server is not obtained within the response time period, generate third exception reminding information corresponding to the applet according to exception uploading factors in the exception uploading log information, and send the third exception reminding information to a group associated with the applet through a second service server associated with the applet; the group is a group in a second application different from the first application.

The specific implementation manner of the response obtaining module 40 and the exception uploading module 50 may refer to the description of step S206-step S207 in the embodiment corresponding to fig. 6, and the detailed description will not be repeated here.

Therefore, the method and the system can embed the target source character string (such as the latest uploaded source code) acquired from the service management warehouse into the history source character string through the introduced continuous integrated server, the history source character string can be the source code (such as the last uploaded source code) existing in the continuous integrated server, and the continuous integrated server can provide continuous integrated service so as to automatically generate the test data packet, so that man-machine interaction can be avoided, and the generation efficiency of the test data packet can be improved under the condition of no buttons. In addition, by automatically generating the test data packet in the continuous integrated server, direct data interaction between the target terminal (i.e. the development terminal) and the first service server (e.g. the WeChat server) can be avoided, so that decoupling cooperation can be fully exerted in the development process of the applet, and waste of development resources is avoided.

Further, please refer to fig. 10, which is a schematic diagram of a computer device according to an embodiment of the present application. As shown in fig. 10, the computer device 1000 may be the persistent integrated server 2000 in the corresponding embodiment of fig. 1, and the computer device 1000 may include: at least one processor 1001, such as a CPU, at least one network interface 1004, a user interface 1003, a memory 1005, at least one communication bus 1002. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a Display (Display), a Keyboard (Keyboard), and the network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others. The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 1005 may also optionally be at least one storage device located remotely from the aforementioned processor 1001. As shown in fig. 10, an operating system, a network communication module, a user interface module, and a device control application program may be included in the memory 1005, which is one type of computer storage medium.

In the computer device 1000 shown in fig. 10, the network interface 1004 is mainly used for network communication with a service server; while user interface 1003 is primarily used as an interface for providing input to a user; and the processor 1001 may be used to invoke a device control application stored in the memory 1005 to implement:

It should be understood that the computer device 1000 described in the embodiment of the present application may perform the description of the data processing method in the embodiment corresponding to fig. 2 and fig. 6, and may also perform the description of the data processing apparatus 1 in the embodiment corresponding to fig. 9, which is not repeated herein. In addition, the description of the beneficial effects of the same method is omitted.

Furthermore, it should be noted here that: the embodiments of the present application further provide a computer readable storage medium, where the computer readable storage medium stores a computer program executed by the aforementioned data processing apparatus 1, where the computer program includes program instructions, when executed by the processor, can perform the description of the data processing method in the embodiment corresponding to fig. 2 or fig. 6, and therefore, a description will not be repeated herein. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the computer-readable storage medium according to the present application, please refer to the description of the method embodiments of the present application.

Those skilled in the art will appreciate that implementing all or part of the above-described methods may be accomplished by way of computer programs, which may be stored on a computer-readable storage medium, and which, when executed, may comprise the steps of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), or the like.

The foregoing disclosure is only illustrative of the preferred embodiments of the present application and is not intended to limit the scope of the claims herein, as the equivalent of the claims herein shall be construed to fall within the scope of the claims herein.

Claims

1. A data processing method applied to a continuous integration server, comprising:

when service submission notification information which is actively sent by a service management server and corresponds to a service management warehouse is obtained, pulling the target source character string and incremental change attribute information corresponding to the target source character string from the service management warehouse based on a hash value of version information corresponding to the target source character string carried in the service submission notification information; the service submission notification information is generated based on a hash value of version information corresponding to a target source character string when the service management server detects that the target source character string in a development data packet uploaded by a target terminal at a time T1 is newly added in the service management warehouse; the development data packet comprises the target source character string and the increment change attribute information; the target source character string is determined by the target terminal after submitting a target source code corresponding to a change operation in a working file when the target terminal changes the working file corresponding to a history source character string corresponding to an applet associated with a first application; the incremental change attribute information is used for indicating position information of the target source character string relative to the history source character string; the service management warehouse is a code database used for carrying out data sharing on a plurality of terminals associated with the applet in the service management server; the service management server is used for synchronizing the history source character strings in the code database to the continuous integration server when synchronizing the history source character strings in the code database to the target terminal; the history source character string is uploaded by the development terminal at the moment T2; the time T2 is the time before the time T1; the target terminal and the development terminal are different terminals in the plurality of terminals;

When the hash value of the target source character string is inconsistent with the hash value of the historical source character string, embedding the target source character string into the historical source character string according to the increment change attribute information, and compiling the historical source character string embedded with the target source character string to obtain a test data packet corresponding to the applet;

2. The method of claim 1, wherein the service management repository has an index file built therein for source code indexing;

when acquiring service submission notification information actively sent by a service management server corresponding to a service management warehouse, pulling the target source character string and incremental change attribute information corresponding to the target source character string from the service management warehouse based on a hash value of version information corresponding to the target source character string carried in the service submission notification information, wherein the method comprises the following steps:

And according to the hash value of the version information corresponding to the target source character string, the hash value corresponding to the target source character string is found in the index file, and according to the hash value corresponding to the target source character string, the target source character string and the increment change attribute information corresponding to the target source character string are pulled from the service management warehouse.

3. The method of claim 1, wherein prior to said determining that the hash value of the target source string does not agree with the hash value of the history source string, the method further comprises:

and pulling the target source character string and the increment change attribute information corresponding to the target source character string from the service management warehouse according to the source code pulling instruction.

4. A method according to any of claims 1-3, characterized in that the code database contains service code data uploaded by at least one of the terminals associated with the applet; the service code data comprises the target source character string uploaded by a target terminal in the at least one terminal and increment change attribute information corresponding to the target source character string; the service management server is used for carrying out distributed storage on the target source character string uploaded by the target terminal and carrying out version management on the version information of the target source character string.

5. The method according to claim 1, wherein when it is determined that the hash value of the target source string is inconsistent with the hash value of the history source string, embedding the target source string into the history source string according to the incremental change attribute information, and compiling the history source string embedded with the target source string to obtain the test packet corresponding to the applet, includes:

when the hash value of the target source character string is inconsistent with the hash value of the historical source character string, embedding the target source character string into the historical source character string according to the increment change attribute information, and generating a data packet to be compiled corresponding to the applet according to the historical source character string embedded with the target source character string;

and compiling the data packet to be compiled according to the dependency data file corresponding to the applet, and obtaining the test data packet corresponding to the applet when the compiling state of the data packet to be compiled is a successful state.

6. The method of claim 5, wherein the embedding the target source string into the history source string according to the delta change attribute information, and generating the data packet to be compiled corresponding to the applet according to the history source string into which the target source string is embedded, comprises:

Performing anomaly detection on the target source character string;

7. The method of claim 6, wherein the method further comprises:

8. The method according to claim 5, wherein the compiling the data packet to be compiled according to the dependency data file corresponding to the applet, when the compiling state of the data packet to be compiled is a successful state, obtaining the test data packet corresponding to the applet includes:

9. The method as recited in claim 8, further comprising:

10. The method as recited in claim 8, further comprising:

11. The method of claim 1, wherein the sending the test data packet to a first traffic server corresponding to the first application comprises:

12. The method as recited in claim 1, further comprising:

13. A data processing apparatus for use with a continuously integrated server, comprising:

the character string acquisition module is used for pulling the target source character string and the increment change attribute information corresponding to the target source character string from the service management warehouse based on the hash value of version information corresponding to the target source character string carried in the service submission notification information when the service submission notification information actively sent by the service management server corresponding to the service management warehouse is acquired; the service submission notification information is generated based on a hash value of version information corresponding to a target source character string when the service management server detects that the target source character string in a development data packet uploaded by a target terminal at a time T1 is newly added in the service management warehouse; the development data packet comprises the target source character string and the increment change attribute information; the target source character string is determined by the target terminal after submitting a target source code corresponding to a change operation in a working file when the target terminal changes the working file corresponding to a history source character string corresponding to an applet associated with a first application; the incremental change attribute information is used for indicating position information of the target source character string relative to the history source character string; the service management warehouse is a code database used for carrying out data sharing on a plurality of terminals associated with the applet in the service management server; the service management server is used for synchronizing the history source character strings in the code database to the continuous integration server when synchronizing the history source character strings in the code database to the target terminal; the history source character string is uploaded by the development terminal at the moment T2; the time T2 is the time before the time T1; the target terminal and the development terminal are different terminals in the plurality of terminals;

The character string embedding module is used for embedding the target source character string into the history source character string according to the increment change attribute information when the hash value of the target source character string is inconsistent with the hash value of the history source character string, and compiling the history source character string embedded with the target source character string to obtain a test data packet corresponding to the applet;

14. A computer device, comprising: a processor, a memory, and a network interface;

the processor is connected to a memory for providing data communication functions, a network interface for storing program code, and for invoking the program code to perform the method of any of claims 1-12.

15. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program comprising program instructions which, when executed by a processor, perform the method of any of claims 1-12.