A code publishing method and related apparatus

Abstract

The application discloses a code publishing method and related device, constructs an iterative pipeline including multiple task nodes, and when code publishing is needed, multiple task nodes are triggered to process the code to be published in turn in response to a triggering operation of a first user. During the processing, the task progress of the multiple task nodes is collected. If it is monitored according to the task progress that a first task node completes the task for the code to be published, the processed code to be published is submitted to a second task node, so that the second task node completes the task for the code to be published. The second task node is the next task node of the first task node in the iterative pipeline. Until each task node completes its task for the code to be published, the code to be published is published to the corresponding server. The method enables information sharing between the R&D departments corresponding to different task nodes, thereby improving communication efficiency and shortening the release iteration period from development, testing to operation.

Description

Technical Field

[0001] This application relates to the field of software development, and in particular to a code deployment method and related apparatus. Background Technology

[0002] With the popularization and rapid development of mobile internet, derivative products and application scenarios are becoming more diversified and complex, and product applications provide various functions to meet user needs.

[0003] In order for the product application to provide various functions, the R&D personnel need to develop the functions. After the R&D personnel have completed the development of the functions, they will manually package the code that implements the functions, submit it for testing, and then manually go online to complete the release of the functions.

[0004] However, this release process is relatively primitive, making it difficult for different personnel to share information and resulting in low communication efficiency, which in turn leads to a long release iteration cycle from development and testing to operation and maintenance. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a code release method and related apparatus, enabling information sharing between R&D departments corresponding to different task nodes, thereby improving communication efficiency and shortening the release iteration cycle from development and testing to operation and maintenance.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a code deployment method for constructing an iterative pipeline including multiple task nodes, the method comprising:

[0008] In response to the first user's trigger operation, multiple task nodes in the iteration pipeline are triggered to process the code to be released in sequence;

[0009] During the process of the multiple task nodes processing the code to be released in sequence, the task progress of the multiple task nodes is collected.

[0010] If, based on the task progress, the first task node among the plurality of task nodes completes its task for the code to be released, it submits the processed code to be released to the second task node, so that the second task node completes its task for the code to be released until the code to be released is released to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline.

[0011] Secondly, embodiments of this application provide a code deployment apparatus for constructing an iterative pipeline including multiple task nodes. The apparatus includes a startup unit, a collection unit, and a deployment unit.

[0012] The startup unit is used to respond to the triggering operation of the first user and trigger multiple task nodes in the iterative pipeline to process the code to be released in sequence.

[0013] The collection unit is used to collect the task progress information of the multiple task nodes during the process of the multiple task nodes processing the code to be released in sequence.

[0014] The publishing unit is configured to, if it detects that the first task node among the plurality of task nodes has completed its task for the code to be published based on the task progress, submit the processed code to be published to the second task node, so that the second task node can complete its task for the code to be published until the code to be published is published to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline.

[0015] Thirdly, embodiments of this application provide an electronic device for code distribution, the electronic device including a processor and a memory:

[0016] The memory is used to store program code and transmit the program code to the processor;

[0017] The processor is configured to execute the method described in the first aspect according to instructions in the program code.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium for storing program code for executing the method described in the first aspect.

[0019] As can be seen from the above technical solution, an iterative pipeline comprising multiple task nodes is pre-constructed. When code release is required, in response to a trigger operation by the first user, multiple task nodes in the iterative pipeline are triggered to process the code to be released sequentially. During the sequential processing of the code to be released by multiple task nodes, the task progress of multiple task nodes is collected. If the task progress is monitored and the first task node completes its task for the code to be released, the processed code to be released is submitted to the second task node so that the second task node can complete its task for the code to be released. The second task node is the next task node in the iterative pipeline after the first task node, until each task node completes its task for the code to be released, thereby releasing the code to be released to the corresponding server. This method, through the concept of a pipeline, collects the task progress of each task node in real time, triggers task nodes to execute tasks in a timely manner, thereby enabling information sharing between the R&D departments corresponding to different task nodes, improving communication efficiency, and shortening the release iteration cycle from development and testing to operation and maintenance. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A schematic diagram of a code deployment method provided in this application embodiment;

[0022] Figure 2 A flowchart illustrating a code publishing method provided in an embodiment of this application;

[0023] Figure 3 A user interaction example diagram of a code publishing method provided in an embodiment of this application;

[0024] Figure 4 This application provides a schematic diagram of a code release process.

[0025] Figure 5 An example diagram illustrating a method for constructing a machine, provided in an embodiment of this application;

[0026] Figure 6 An example diagram illustrating the deployment of a testing environment and a testing method provided in an embodiment of this application;

[0027] Figure 7 A grayscale publishing diagram provided for an embodiment of this application;

[0028] Figure 8 is a schematic diagram of the system architecture of a code deployment method provided in an embodiment of this application;

[0029] Figure 9 A flowchart illustrating a code deployment method provided in an embodiment of this application;

[0030] Figure 10 A structural diagram of a code publishing device provided in an embodiment of this application;

[0031] Figure 11 A structural diagram of a terminal provided in an embodiment of this application;

[0032] Figure 12 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0033] The embodiments of this application will now be described with reference to the accompanying drawings.

[0034] The code deployment methods provided in related technologies are relatively primitive, making it difficult for different personnel to share information and resulting in low communication efficiency. Consequently, the deployment iteration cycle from development and testing to operation and maintenance is relatively long.

[0035] To address the aforementioned technical issues, this application provides a code deployment method. This method utilizes the concept of a pipeline to collect the task progress of each task node in real time, triggering each task node to execute tasks promptly. This enables information sharing between the R&D departments corresponding to different task nodes, thereby improving communication efficiency and shortening the deployment iteration cycle from development and testing to operation and maintenance.

[0036] See Figure 1 , Figure 1 This is a schematic diagram of the system architecture for the code deployment method provided in this application embodiment. The system architecture includes a code deployment system 101 and a server 102. The code deployment system 101 is built with an iterative pipeline comprising multiple task nodes. Each task node can be a terminal corresponding to various users involved in the research and development process. Terminals can be smartphones, tablets, laptops, desktop computers, etc., but are not limited to these. The server 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services; this application does not impose any limitations on these aspects.

[0037] When code deployment is required, the first user can execute a trigger operation through their corresponding terminal to initiate the sequential processing of the code to be deployed by multiple task nodes in the iterative pipeline of the code deployment system 101. These multiple task nodes process the code to be deployed sequentially according to the code deployment process and their respective processing capabilities, forming an iterative pipeline. For example, multiple task nodes... Figure 1 The task node shown is 1, task node 2, ..., task node N.

[0038] During the sequential processing of code to be released by multiple task nodes, the task progress of each node is collected. If the second task node (e.g.) Figure 1 Task node 2) is the first task node (e.g. Figure 1 In the next task node of the iterative pipeline, when the first task node among multiple task nodes has completed its task for the code to be released, it submits the processed code to be released to the second task node so that the second task node can complete its task for the code to be released. This continues until each task node completes its task for the code to be released, thereby releasing the code to be released to the corresponding server.

[0039] Next, the code publishing method provided in the embodiments of this application will be described in detail with reference to the accompanying drawings.

[0040] See Figure 2 , Figure 2 A flowchart of a code deployment method is shown, the method comprising:

[0041] S201. In response to the triggering operation of the first user, trigger multiple task nodes in the iterative pipeline to process the code to be released in sequence.

[0042] The code release system is built with an iterative pipeline that includes multiple task nodes. The code release system can be built on DevOps (a combination of Development and Operations). DevOps is a set of processes, methods and systems used to promote communication, collaboration and integration between development (application / software engineering), technical operations and quality assurance departments.

[0043] When a new feature needs to be released, the first user can perform a trigger operation on their corresponding terminal to trigger multiple task nodes in the iteration pipeline to process the code to be released in sequence.

[0044] Typically, the first user can be a developer, who triggers the iteration pipeline based on user feedback; the first user can also be a product manager, who triggers the iteration pipeline based on user feedback.

[0045] To ensure speed and efficiency, and to allow users to focus more on development, while also catering to non-developer users (such as product managers and project managers), this embodiment is designed with simplicity in mind. For ordinary first-time users, they can manually trigger the iteration pipeline by clicking on the controls displayed on their corresponding terminal (i.e., the front end of the code deployment system); if the first-time user is a technically savvy developer, they can also trigger the iteration pipeline through the Git command line (i.e., the back end of the code deployment system).

[0046] See Figure 3 As shown, the first user can manually trigger the iteration pipeline through the front end of the code deployment system 101, or trigger it through the back end of the code deployment system 101 using the Git command line. After the iteration pipeline is triggered, the code deployment system 101 processes the code to be deployed, thereby deploying the code to the corresponding server.

[0047] It should be noted that multiple task nodes process the code to be released sequentially according to the code release process and their respective processing functions, forming an iterative pipeline. For example, the code release process can typically be arranged as follows: Figure 4The process shown includes code submission (S401), code inspection (S402), compilation (S403), testing (S404), release review (S405), and release (S406). After release, it may also include online monitoring (S407) and online tracking (S408). Among them, testing can include automated testing and manual testing.

[0048] Figure 4 The code release process shown is only an example. Other steps can be added as needed, such as submitting development requirements (e.g., S409) before submitting the code. In addition, code inspection (S402) can be performed after code submission (S401) or before code submission (S401). That is, when the user triggers code submission, the code is inspected first, and then submitted after the inspection is passed. This application embodiment does not limit the code release process.

[0049] S202. During the process of the multiple task nodes processing the code to be released in sequence, collect the task progress information of the multiple task nodes.

[0050] In this embodiment, the task progress of multiple task nodes can be collected in real time, thereby determining when to submit the processed code to the next task node based on the task progress. Furthermore, when a user, such as a second user, triggers a query request to understand the code release progress, the system can respond to the second user's query request and display the task progress to them. This facilitates information sharing between departments and improves communication efficiency.

[0051] S203. If, based on the task progress, the first task node among the plurality of task nodes completes its task for the code to be released, it submits the processed code to be released to the second task node so that the second task node can complete its task for the code to be released until the code to be released is released to the corresponding server.

[0052] The second task node is the next task node in the iterative pipeline after the first task node. For example, the first task node is... Figure 4 The task node shown is used for submitting code. Therefore, the second task node can be the next task node, i.e. Figure 4 The task node shown is for code inspection.

[0053] It should be noted that, in order to inform users of the second task node that the second task node needs to process the code to be released, a prompt can be sent to the corresponding user through the second task node. This allows the user to participate in the processing of the code to be released in a timely manner when it is required, thereby improving release efficiency.

[0054] In this implementation, different task nodes may have different functions, so different task nodes will handle the released code in different ways.

[0055] If the first task node is used for submitting code and the second task node is used for code inspection, then after the second task node completes the code inspection, if the inspection result obtained by the second task node indicates that the code to be released has failed, such as errors or non-compliance with specifications, then it can send a code modification prompt to the first task node, thereby prompting the developers to modify the code to be released.

[0056] If the first task node is used for compilation, it can complete the task for the code to be released by building multiple build machines based on the business type, packaging the code to be released into an artifact package, and storing the artifact package in the target repository. The target repository could be, for example, a Ceph repository, used to store the artifact package.

[0057] The build machine can be a virtual environment built on a physical device, thereby isolating the code to be released for different business types and enabling concurrent builds.

[0058] For details, please refer to Figure 5 As shown, the build can be performed through the build machine scheduler in the code release platform. The corresponding compilation image is pulled from the Docker image source and started. The big data system involves multiple code repositories and is pulled into Docker containers through the worker bee system for building, resulting in multiple build machines, such as build machine 1, build machine 2, ..., build machine M. The build status is fed back to the backend of the code release system through the software development kit (SDK). The built artifacts are stored in the Ceph repository according to certain rules.

[0059] Because big data systems involve multiple services, each requiring multiple commits, and each commit is compiled, Docker is used to achieve concurrent builds due to limited compilation resources. Each Docker environment includes the SDK for the code deployment system and pulls code from a code hosting system (Gongfeng) to store various codebases for the big data system. For example, if the big data system includes a backend service, sub-service 1, sub-service 2, and sub-service 3, the build environment needs to pull code from these four services. During the build process, the system checks which of these codebases have changed; if so, a new build is required. This ensures rapid builds even with limited resources.

[0060] If the first task node is a node used for compilation, and the second task node is a node used for testing, then the second task node can complete its task for the code to be released by pulling the corresponding image from the image repository to the test machine, pulling the artifact package of the code to be released from the target repository to the test machine, running the code to be released according to the image, testing the code to be released, and storing the test results in the log repository machine.

[0061] For example, see Figure 6 As shown, the code release system's backend triggers the deployment and testing process of the test environment through scheduling. Since Docker can package a series of components required for a code to run normally into an image, the code can be run based on this image during execution. Therefore, in this embodiment, the corresponding image can be pulled from the image repository to the test machine, and the artifact package of the code to be released can be pulled from the target repository (e.g., the Ceph repository) to the test machine. The code to be released can then be run based on this image to test the code, and the test results can be stored in the log repository machine.

[0062] The test machine can be a virtual environment built on a physical device, thereby isolating the code to be released for different business types (e.g., Figure 6 Test machines 1, ..., N are used to implement concurrent testing of multiple services.

[0063] The various sub-services involved in a big data system require separate environments for testing each change. Concurrent deployment to multiple environments allows testers to easily perform tests or automate test case execution, thus accelerating testing efficiency. Through a specific strategy, corresponding images are concurrently pulled from the image repository to start multiple deployment environments, while artifact packages are pulled from the Ceph repository for deployment in the test environments. The test results are then reported.

[0064] If the first task node is for testing and the second task node is for permission review, then the second task node completes its task for the code to be released by determining whether the code meets the release requirements based on preset evaluation indicators. These preset evaluation indicators include at least the test pass rate. If the code meets the release requirements and is deemed approved, it can be released to the server. Through release review, the security and robustness of the entire product are ensured while iterating rapidly.

[0065] For example, if the preset evaluation metric is the test pass rate, and a test pass rate of 98% is considered to meet the release requirements, then when the test pass rate is determined to be 98% or higher, the review is approved and the code to be released can be published to the server.

[0066] Preset evaluation indicators may also include code standardization; that is, if the code standardization of the code to be released meets the release requirements, then the code to be released is deemed to have passed the review.

[0067] In addition, manual review by auditors can be incorporated. Release review serves as an authorization check for the entire code release process. Auditors include product managers, development team leaders, directors, etc., and can be flexibly configured according to business needs. Auditors can manually evaluate the processing of each preceding task node to determine whether a release should proceed.

[0068] Once it is determined that the code to be released will be published to the corresponding server, concurrent release scheduling can be performed through Zookeeper (a software that provides consistency services for distributed applications). The corresponding artifact package is pulled from the Ceph repository and published to the corresponding server. The release result is then fed back to the front end of the code release system, for example, by sending code release success notifications to multiple task nodes.

[0069] In some cases, product upgrades (such as releasing new features) may encounter problems. To obtain user feedback as early as possible, improve product functionality and quality, involve users in product testing, strengthen user interaction, and reduce the number of users affected by the upgrade, a canary release approach can be adopted. A canary release involves allowing a portion of users to continue using feature A while another portion starts using feature B (e.g., the feature represented by the code to be released). If users have no objections to feature B, the scope is gradually expanded until all users are migrated to feature B.

[0070] In this scenario, one possible way to deploy the code to the corresponding server is to select a target server from multiple servers according to a preset ratio, and then deploy the code to the target server, thereby achieving canary deployment (i.e., batch deployment).

[0071] Since the servers are deployed in multiple locations, say locations A, B, and C, a canary rollout needs to be performed on servers in each location. See [link / reference needed]. Figure 7 As shown, for example, 100 servers are selected from servers in location A as target servers, and the code to be released is deployed to these 100 servers; 50 servers are selected from servers in location B as target servers, and the code to be released is deployed to these 50 servers; 150 servers are selected from servers in location C as target servers, and the code to be released is deployed to these 150 servers.

[0072] When selecting target servers from multiple servers according to a preset ratio (e.g., percentage), the number of target servers may be non-integer. If there is less than one target server, the result is rounded up. For example, if there are 150 servers in location A and the preset ratio is 15%, the product of 150 and 15% is 22.5. Since 22.5 is not an integer, there will be less than one target server. Therefore, the result is rounded up to select 23 servers as target servers.

[0073] In this embodiment, a grayscale interval time can also be set, which is the time interval between grayscale releases. For example, after a grayscale release is completed, a grayscale release is performed again when the grayscale interval time is reached.

[0074] As can be seen from the above technical solution, an iterative pipeline comprising multiple task nodes is pre-constructed. When code release is required, in response to a trigger operation by the first user, multiple task nodes in the iterative pipeline are triggered to process the code to be released sequentially. During the sequential processing of the code to be released by multiple task nodes, the task progress of multiple task nodes is collected. If the task progress is monitored and the first task node completes its task for the code to be released, the processed code to be released is submitted to the second task node so that the second task node can complete its task for the code to be released. The second task node is the next task node in the iterative pipeline after the first task node, until each task node completes its task for the code to be released, thereby releasing the code to be released to the corresponding server. This method, through the concept of a pipeline, collects the task progress of each task node in real time, triggers task nodes to execute tasks in a timely manner, thereby enabling information sharing between the R&D departments corresponding to different task nodes, improving communication efficiency, and shortening the release iteration cycle from development and testing to operation and maintenance.

[0075] Deploying code using a DevOps-based code release system enables rapid iteration, significantly improving development efficiency. The iterative pipeline design reduces information asymmetry between departments, enhances user experience, and shortens the code release cycle, for example, allowing releases to increase from once a week to multiple iterations per day. Furthermore, the added release review process before release ensures the security and stability of the entire system.

[0076] Next, the code deployment method provided in this application embodiment will be introduced in conjunction with practical application scenarios. With rapidly changing user needs, the frequency of product function changes is also gradually increasing. Shortening the product development, testing, and maintenance lifecycle, improving R&D efficiency, and ensuring quality are currently key technical challenges in market competition. Therefore, this application embodiment provides a code deployment method to achieve rapid iteration of product functions. This method can be implemented based on the system architecture shown in Figure 8, which includes a front-end 801 of the code deployment system, a back-end 802 of the code deployment system, a back-end scheduling system (not shown in Figure 8), a parallel multi-service construction module 803, a multi-service parallel testing environment module 804, a release review module 805, and an online canary release module 806, among other components.

[0077] See Figure 9 The method includes:

[0078] S901, a code deployment system built on DevOps.

[0079] S902. Trigger multiple task nodes in the iterative pipeline at the front end of the code release system to process the code to be released sequentially.

[0080] S903. Based on the business type, build multiple build machines, use the build machines to package the code to be released to obtain the artifact package, and store the artifact package in the target repository.

[0081] The steps in S903 can be implemented based on the parallel multi-service building block shown in Figure 803. For details, please refer to... Figure 5 The description of the corresponding embodiments will not be repeated here.

[0082] S904. Pull the corresponding image from the image repository to the test machine, pull the artifact package of the code to be released from the target repository to the test machine, run the code to be released according to the image, test the code to be released, and store the test results in the log repository machine.

[0083] The steps in S904 can be implemented based on the multi-service parallel test environment module shown in Figure 8 (804). For details, please refer to... Figure 6 The description of the corresponding embodiments will not be repeated here.

[0084] S905. Determine whether the code to be released meets the release requirements based on the preset evaluation indicators. The preset evaluation indicators include at least the test pass rate.

[0085] Step S905 can be implemented based on the release review module shown in Figure 805. For details, please refer to the description of release review in the previous embodiments, which will not be repeated here.

[0086] S906. If the code to be released meets the release requirements, the code to be released will be released to the server in a canary manner.

[0087] Step S906 can be implemented based on the online grayscale release module shown in Figure 806. For details, please refer to the description of grayscale release in the previous embodiment, which will not be repeated here.

[0088] based on Figure 2 In accordance with the code deployment method provided in the corresponding embodiments, this application also provides a code deployment apparatus, see below. Figure 10 The device 1000 constructs an iterative pipeline comprising multiple task nodes, and includes a startup unit 1001, a collection unit 1002, and a release unit 1003.

[0089] The startup unit 1001 is used to respond to the triggering operation of the first user and trigger multiple task nodes in the iterative pipeline to process the code to be released in sequence.

[0090] The collection unit 1002 is used to collect the task progress of the multiple task nodes during the process of the multiple task nodes processing the code to be released in sequence.

[0091] The publishing unit 1003 is configured to, if the task progress is monitored and the first task node among the plurality of task nodes completes the task for the code to be published, submit the processed code to be published to the second task node, so that the second task node completes its task for the code to be published until the code to be published is published to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline.

[0092] In one possible implementation, the device further includes a display unit:

[0093] The display unit is used to respond to a query request from a second user and display the task progress status to the second user.

[0094] In one possible implementation, if the first task node is a node for submitting code and the second task node is a node for code review, the device further includes a prompting unit:

[0095] The prompting unit is used to send a code modification prompt to the first task node if the inspection result obtained by the second task node on the code to be released indicates that the code to be released fails.

[0096] In one possible implementation, if the first task node is a node used for compilation, the first task node completes the task for the code to be released in the following ways:

[0097] Multiple build machines are built based on business type;

[0098] The code to be released is packaged using the build machine to obtain an artifact package, and the artifact package is stored in the target repository.

[0099] In one possible implementation, if the second task node is a node used for testing, the second task node completes its task for the code to be released in the following ways:

[0100] Pull the corresponding image from the image repository to the test machine;

[0101] Pull the artifact package of the code to be released from the target repository onto the test machine;

[0102] Run the code to be released based on the image, test the code to be released, and store the test results in the log repository machine.

[0103] In one possible implementation, if the first task node is a node for testing and the second task node is a node for release review, the second task node completes its task for the code to be released in the following ways:

[0104] Whether the code to be released meets the release requirements is determined according to preset evaluation indicators, and the preset evaluation indicators include at least the test pass rate;

[0105] If the code to be released meets the release requirements, the code to be released is deemed to have passed the review.

[0106] In one possible implementation, the publishing unit 1003 is used for:

[0107] Select the target server from multiple servers according to a preset ratio;

[0108] The code to be published is published to the target server.

[0109] This application also provides an electronic device for code distribution, which can be a terminal, taking a smartphone as an example:

[0110] Figure 11 This is a block diagram illustrating a portion of the structure of a smartphone related to the terminal device provided in the embodiments of this application. (Reference) Figure 11 The smartphone includes components such as: a radio frequency (RF) circuit 1110, a memory 1120, an input unit 1130, a display unit 1140, a sensor 1150, an audio circuit 1160, a wireless fidelity (WiFi) module 1170, a processor 1180, and a power supply 1190. The input unit 1130 may include a touch panel 1131 and other input devices 1132, the display unit 1140 may include a display panel 1141, and the audio circuit 1160 may include a speaker 1161 and a microphone 1162. Those skilled in the art will understand that... Figure 11 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0111] The memory 1120 can be used to store software programs and modules. The processor 1180 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1120. The memory 1120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0112] The processor 1180 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1120 and calling data stored in the memory 1120. Optionally, the processor 1180 may include one or more processing units; preferably, the processor 1180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1180.

[0113] In this embodiment, the processor 1180 in the terminal can perform the following steps;

[0114] In response to the first user's trigger operation, multiple task nodes in the iteration pipeline are triggered to process the code to be released in sequence;

[0115] During the process of the multiple task nodes processing the code to be released in sequence, the task progress of the multiple task nodes is collected.

[0116] If, based on the task progress, the first task node among the plurality of task nodes completes its task for the code to be released, it submits the processed code to be released to the second task node, so that the second task node completes its task for the code to be released until the code to be released is released to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline.

[0117] The electronic device may also include a server; embodiments of this application also provide a server, please refer to [link to relevant documentation]. Figure 12 As shown, Figure 12 This is a structural diagram of a server 1200 provided in an embodiment of this application. The server 1200 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 1222 (e.g., one or more processors) and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and storage media 1230 can be temporary or persistent storage. The program stored in the storage media 1230 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1222 may be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0118] Server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, and / or one or more operating systems 1241, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0119] In this embodiment, the central processing unit 1222 in the server 1200 can perform the following steps:

[0120] In response to the first user's trigger operation, multiple task nodes in the iteration pipeline are triggered to process the code to be released in sequence;

[0121] During the process of the multiple task nodes processing the code to be released in sequence, the task progress of the multiple task nodes is collected.

[0122] If, based on the task progress, the first task node among the plurality of task nodes completes its task for the code to be released, it submits the processed code to be released to the second task node, so that the second task node completes its task for the code to be released until the code to be released is released to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline.

[0123] According to one aspect of this application, a computer-readable storage medium is provided for storing program code for executing the code distribution methods described in the foregoing embodiments.

[0124] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0125] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0126] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0127] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0128] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0129] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A code release method characterized by, An iterative pipeline comprising multiple task nodes is constructed to enable information sharing between departments corresponding to different task nodes; the method includes: In response to the first user's trigger operation, multiple task nodes in the iteration pipeline are triggered to process the code to be released in sequence; During the process of the multiple task nodes processing the code to be released in sequence, the task progress of the multiple task nodes is collected. In response to the query request from the second user, the task progress is displayed to the second user; If, based on the task progress, the first task node among the multiple task nodes completes its task for the code to be released, it submits the processed code to the second task node and sends a prompt to the corresponding user through the second task node, thereby triggering the second task node to execute and complete its task for the code to be released in a timely manner, until the code to be released is released to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline. After the code to be published is published to the corresponding server, a code publication success notification is sent to each of the multiple task nodes.

2. The method of claim 1, wherein, If the first task node is a node for submitting code, and the second task node is a node for code review, the method further includes: If the second task node's inspection result indicates that the code to be released fails, it sends a code modification prompt to the first task node.

3. The method of claim 1, wherein, If the first task node is a node used for compilation, the first task node completes the task for the code to be released in the following ways: Multiple build machines are built based on business type; The code to be released is packaged using the build machine to obtain an artifact package, and the artifact package is stored in the target repository.

4. The method of claim 3, wherein, If the second task node is a node used for testing, the second task node completes its task for the code to be released in the following ways: Pull the corresponding image from the image repository to the test machine; Pull the artifact package of the code to be released from the target repository onto the test machine; Run the code to be released based on the image, test the code to be released, and store the test results in the log repository machine.

5. The method of claim 1, wherein, If the first task node is a node used for testing, and the second task node is a node used for release review, the second task node completes its task for the code to be released in the following ways: Whether the code to be released meets the release requirements is determined according to preset evaluation indicators, and the preset evaluation indicators include at least the test pass rate; If the code to be released meets the release requirements, the code to be released is deemed to have passed the review.

6. The method according to any one of claims 1 to 5, characterized in that, The step of publishing the code to be published to the corresponding server includes: Select the target server from multiple servers according to a preset ratio; The code to be published is published to the target server.

7. A code issuing apparatus characterized by comprising: An iterative pipeline comprising multiple task nodes is constructed to enable information sharing among departments corresponding to different task nodes; the device includes a startup unit, a collection unit, a publishing unit, and a display unit. The startup unit is used to respond to the triggering operation of the first user and trigger multiple task nodes in the iterative pipeline to process the code to be released in sequence. The collection unit is used to collect the task progress information of the multiple task nodes during the process of the multiple task nodes processing the code to be released in sequence. The display unit is used to respond to the query request of the second user and display the task progress status to the second user; The publishing unit is configured to, if it detects that the first task node among the plurality of task nodes has completed its task for the code to be published based on the task progress, submit the processed code to be published to the second task node, and issue a prompt to the corresponding user through the second task node to trigger the second task node to execute and complete its task for the code to be published in a timely manner, until the code to be published is published to the corresponding server; the second task node is the next task node after the first task node in the iterative pipeline; The device is further configured to send a code release success notification to each of the multiple task nodes after the code to be released is published to the corresponding server.

8. The apparatus of claim 7, wherein, If the first task node is a node for submitting code, and the second task node is a node for code review, the device further includes: If the second task node's inspection result indicates that the code to be released fails, a code modification prompt is sent to the first task node.

9. The apparatus of claim 7, wherein, If the first task node is a node used for compilation, the first task node completes the task for the code to be released in the following ways: Multiple build machines are built based on business type; The code to be released is packaged using the build machine to obtain an artifact package, and the artifact package is stored in the target repository.

10. The apparatus of claim 9, wherein, If the second task node is a node used for testing, the second task node completes its task for the code to be released in the following ways: Pull the corresponding image from the image repository to the test machine; Pull the artifact package of the code to be released from the target repository onto the test machine; Run the code to be released based on the image, test the code to be released, and store the test results in the log repository machine.

11. The apparatus of claim 7, wherein, If the first task node is a node used for testing, and the second task node is a node used for release review, the second task node completes its task for the code to be released in the following ways: Whether the code to be released meets the release requirements is determined according to preset evaluation indicators, and the preset evaluation indicators include at least the test pass rate; If the code to be released meets the release requirements, the code to be released is deemed to have passed the review.

12. The device of any one of claims 7-11, wherein, The step of publishing the code to be published to the corresponding server includes: Select the target server from multiple servers according to a preset ratio; The code to be published is published to the target server.

13. An electronic device for code release, comprising: The electronic device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the method of any one of claims 1-7 according to the instructions in the program code.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store program code for performing the method of any one of claims 1-7.

15. A computer program product, characterised in that, The method includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions to cause the computer device to perform the method of any one of claims 1-7.

Images