Software automatic publishing method and system based on Jenkins and project management software

Abstract

The application discloses a software automatic publishing method based on Jenkins and project management software in the field of software automatic publishing, and comprises the following steps: based on a Jenkins pipeline script, triggering Jenkins to automatically poll the submission information of the code of a git warehouse, so as to capture a software version number keyword to be published; Jenkins and project management software perform API communication, automatically acquire requirements and bugs associated with the software version number to be published, and backup to a specified path; Jenkins and office software API communication read the requirements and bugs from the specified path, and automatically publish software push notification related persons; meanwhile, according to the software version number keyword to be published, the project software to which the software version belongs is judged. The scheme can automatically capture the specific software version submission information of the code of the git warehouse, that is, the automatic publishing of the software version can be completed, the work efficiency is greatly improved, meanwhile, the problem of incomplete publishing information caused by manual mechanical operation is avoided, and the work failure is obviously reduced.

Description

Technical Field

[0001] This invention relates to the field of automated software deployment, specifically a method and system for automated software deployment based on Jenkins and project management software. Background Technology

[0002] Once software has completed unit testing, interface testing, integration testing, and system testing, it is ready for official deployment. Before deployment, a software release is required to notify relevant personnel of the detailed requirements fulfilled and specific bugs fixed. At this point, testers need to manually query the specific requirements and bugs resolved for each software. When different projects contain multiple software components, each component must have its requirements and bug information manually checked before sending emails to relevant personnel. This routine operation is inefficient and prone to incomplete release information. If the software iterates rapidly and requires frequent releases, testers performing the releases will spend a significant amount of time performing mechanical release tasks, greatly reducing work efficiency. Therefore, current technology lacks a solution for efficiently automating software releases. Summary of the Invention

[0003] The purpose of this invention is to overcome the problems existing in the prior art and provide a method and system for automatic software deployment based on Jenkins and project management software. To achieve the above objective, this invention provides the following technical solution:

[0004] The first aspect of this invention provides a method for automatic software deployment based on Jenkins and project management software, comprising the following steps:

[0005] Based on the Jenkins pipeline script, Jenkins is triggered to automatically poll the commit information of the Git repository code in order to capture the version number keyword of the software to be released;

[0006] Jenkins communicates with project management software via API to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path.

[0007] Jenkins communicates with the office software API to read the requirements and bugs from the specified path and automatically publishes the software to push notifications to relevant personnel. At the same time, it determines the project software to which the software version belongs based on the keyword of the software version number to be published, and temporarily stores the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path. When Jenkins polls for the project software commit information of the Git repository code, it traverses the text data under the project software and pushes the text data to relevant personnel through the office software.

[0008] Preferably, the step of triggering Jenkins to automatically poll the commit information of the Git repository code based on the Jenkins pipeline script to capture the keyword of the software version number to be released includes the following process:

[0009] S11. Based on Jenkins, use Webhook to poll the commit information of the Git repository code in real time until the keyword "product1_v1.1.1" of the software version number to be released is captured;

[0010] S12. Extract the keyword "product1_v1.1.1" of the software version number to be released and create a storage folder in the specified path.

[0011] Preferably, the Jenkins communicates with the project management software via API to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path, including the following process:

[0012] S21. Based on Jenkins, send a POST request to the project management software via HttpRequest to obtain the project management software's Tokens;

[0013] S22. Determine the Tokens retrieval result returned by the httpRequest. If the returned content is invalid, return to step S21; if the returned content is valid, continue to the next step.

[0014] S23. Based on “Product 1_v1.1.1” in step S11, extract the software keyword “Product 1”;

[0015] S24. Obtain the ID of the software to which "Product 1" belongs through the project management software;

[0016] S25. Traverse the software plan list under the corresponding software according to the software ID;

[0017] S26. Match “Product 1_v1.1.1” in step S11 with the software plan list in step S25 to find the software plan ID corresponding to “Product 1_v1.1.1”;

[0018] S27. If no match is found, return to step S26; if a match is found, continue to the next step.

[0019] S28. Based on the software plan ID successfully matched in step S27, obtain the requirements and bug data associated with the corresponding software plan;

[0020] S29. Write the acquired requirements and bug data into text data;

[0021] S210. If the text data writing fails, return to step S29; if the text data writing succeeds, continue to the next step.

[0022] S211. Copy the successfully written text data to the storage folder described in step S12;

[0023] S212. If text data copying fails, return to step S211; if text data copying succeeds, continue to the next step.

[0024] Preferably, the Jenkins communicates with the office software API, reads the requirements and bugs from the specified path, and automatically publishes software push notifications to relevant parties, including the following process:

[0025] S31. Read the text data from step S29.

[0026] S32. Determine the return result of the read text data. If the returned content is invalid, proceed to step S31; if the returned content is valid, proceed to step S33.

[0027] S33. Write the read data into a string variable and define a specific publishing format;

[0028] S34. Based on the office software settings, implement a custom robot that is accessed via Webhook, obtains and sends POST requests to the office software, and realizes communication between Jenkins and the office software API;

[0029] S35. Determine the return result of the POST request. If the returned content is invalid, return to step S34; if the returned content is valid, proceed to step S36.

[0030] S36. Notify relevant personnel of the returned results via office software;

[0031] S37. Determine the return result of the notification. If the return fails, return to step S36.

[0032] Preferably, the process of determining the project software to which the software version belongs based on the keyword of the software version number to be released, and temporarily storing the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path, and when Jenkins polls for the project software commit information of the Git repository code, it iterates through the text data under the project software and pushes the text data to relevant personnel through office software, including the following process:

[0033] S41. Based on the software version keyword "product1_v1.1.1" captured in step S11, determine whether the project software to which "product1" belongs is pick-and-place machine project software or non-pick-and-place machine project software.

[0034] S42. If the software belongs to the pick-and-place machine project, the text data is also stored in the pick-and-place machine camera software folder; if the software belongs to a non-pick-and-place machine project, the text data is also stored in the non-pick-and-place machine camera software folder.

[0035] S43. When the pick and place machine project software keyword is captured in step S11, extract the pick and place machine project software keyword variable.

[0036] S44. Create a pick-and-place machine project software folder in the specified path based on the pick-and-place machine project software keyword variable;

[0037] S45. Traverse the text data already stored in the pick-and-place machine project software folder;

[0038] S46. Determine the return result of traversing the text data in step S45. If the returned content is invalid, return to step S45; if the returned content is valid, execute step S47.

[0039] S47. Write the read data into a string variable and define a specific publishing format;

[0040] S48. Push notifications to relevant people using Markdown message notification types;

[0041] S49. Determine the return result of the notification. If the return fails, return to step S48; if the return succeeds, execute step S410.

[0042] S410. When the non-pick-and-place machine project software keyword is captured in step S11, the non-pick-and-place machine project software keyword variable is extracted, and steps S44-S49 are executed similarly.

[0043] A second aspect of the present invention provides an automated software release system based on Jenkins and project management software, comprising:

[0044] The keyword capture module is used to trigger Jenkins to automatically poll the commit information of the Git repository based on the Jenkins pipeline script in order to capture the keyword of the software version number to be released;

[0045] The requirement identification module is used for API communication between Jenkins and project management software to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path.

[0046] The automatic software release module is used for Jenkins to communicate with the office software API, read the requirements and bugs from the specified path, and automatically release the software and push notifications to relevant personnel. At the same time, it determines the project software to which the software version belongs based on the keyword of the software version number to be released, and temporarily stores the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path. When Jenkins polls for the project software commit information of the Git repository code, it traverses the text data under the project software and pushes the text data to relevant personnel through the office software.

[0047] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0048] A fourth aspect of the present invention provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device performs the above-described method.

[0049] Beneficial effects: The technical solution of this invention can automatically capture the commit information of a specific software version of the Git repository code, thereby completing the automated release of that software version, which greatly improves work efficiency, avoids the problem of incomplete release information caused by manual mechanical operation, and significantly reduces work errors. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the automated software release process based on Jenkins and project management software, according to an embodiment of the present invention. Detailed Implementation

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

[0052] The first aspect of this invention provides a method for automatic software deployment based on Jenkins and project management software, such as... Figure 1 As shown, it includes the following steps:

[0053] S1. Based on the Jenkins pipeline script, trigger Jenkins to automatically poll the commit information of the Git repository code in order to capture the version number keyword of the software to be released;

[0054] S2. Jenkins communicates with the project management software via API to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to the specified path.

[0055] S3. Jenkins communicates with the office software API to read the requirements and bugs from the specified path and automatically publishes the software and pushes notifications to relevant personnel. S4. At the same time, it determines the project software to which the software version belongs based on the keyword of the software version number to be published, and temporarily stores the completed requirements and resolved bugs corresponding to the software version in the corresponding project software path. When Jenkins polls for the project software commit information of the git repository code, it iterates through the text data under the project software and pushes the text data to relevant personnel through the office software.

[0056] In step S1, based on the Jenkins pipeline script, Jenkins is triggered to automatically poll the commit information of the Git repository code in order to capture the version number keyword of the software to be released. The specific implementation is as follows:

[0057] Step 1.1: Jenkins uses Webhook to poll the commit information of the Git repository code; because of the polling function, it can monitor the information of each commit to Git in real time and realize automated detection.

[0058] Step 1.2: Capture the keyword of the software version number to be released. If no keyword is captured, continue to step 1.1.

[0059] Because of the keyword capture feature, the information polled in Git in step 1.1 can be filtered. When a commit message containing the keyword is captured, step 1.3 is executed; otherwise, step 1.1 is continued. This efficiently utilizes Jenkins server resources and saves time.

[0060] Step 1.3: When the keyword of the software version number to be released is captured, such as the keyword "product1_v1.1.1", use regular expressions to extract the keyword variable;

[0061] Because a function for extracting keyword variables using regular expressions was implemented, the required keyword variables can be extracted from the submission information in step 1.2. These keywords can be used to create folders named after the keywords for archiving software, facilitating future software traceability and maintenance. They can also be used to obtain ZenTao data with the same name as the keywords (in this embodiment of the invention, the project management software is "ZenTao" software as an example, and the office software is "DingTalk" software as an example).

[0062] Step 1.4: Based on the keyword variable, create a "Product1_v1.1.1" folder in the specified path for backup;

[0063] Because the function to create folders named with keywords at specified paths was implemented, the keyword variable obtained in step 1.3 was combined with the URL link of the network external storage path to form a path, thus enabling the creation of variables named with keywords under the specified path. This allows folder creation across local computers, enabling others with access to the network external storage path to view files and access data.

[0064] Step 1.5: After the "Product 1_v1.1.1" folder is successfully created, proceed to step 2.1;

[0065] Because a function to check successful folder creation is implemented, the Jenlins pipeline script checks for successful folder creation in step 1.4 by creating a folder named with a keyword. Only when creation is successful is the data copy function related to that keyword executed; otherwise, it is not executed. This prevents data from being copied to an abnormal path or causing the Jenlins pipeline script to fail due to a non-existent folder. It also stores the text data from step 2.12 for future data tracing within the software.

[0066] The solution in step S1 automatically retrieves keywords based on git commit information and automatically creates folders named after those keywords, saving time and costs.

[0067] In step S2, Jenkins communicates with the project management software via API to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path. The specific implementation is as follows:

[0068] Step 2.1: Jenkins sends a POST request to the ZenTao software via HttpRequest to obtain the ZenTao software's Tokens;

[0069] Because the function of obtaining ZenTao software Tokens was implemented, it can be used in subsequent steps 2.2-2.8 to obtain ZenTao data with names related to the keywords in step 1.3.

[0070] Step 2.2: Determine if Token acquisition fails. If acquisition fails, return to step 2.1; if acquisition succeeds, proceed to step 2.3.

[0071] Because a function was implemented to determine the validity of tokens, it can be used for potential problem analysis and troubleshooting. By printing out the token acquisition results, it is easier to quickly locate and analyze the problem when retrieving ZenTao data fails in the future.

[0072] Step 2.3: Using the keyword "product1_v1.1.1" captured in Step 1.3, further extract the keyword "product1";

[0073] Because of the added keyword extraction function, the extracted keywords can be used to obtain the keyword ID, which can then be used to retrieve the version plan list mentioned in step 2.5.

[0074] Step 2.4: Obtain the ID of "Product 1" to which the keyword "Product 1" belongs through ZenTao;

[0075] Because the function to obtain further extracted keyword IDs has been implemented, the further extracted keywords can be used to obtain the corresponding IDs. Only by successfully obtaining the IDs can one access the list of all version plans included under the software product mentioned in step 2.5.

[0076] Step 2.5: Traverse the software plan list under "Product 1" based on the ID of "Product 1";

[0077] Because the function of traversing the software version plan list was implemented, the keywords extracted in step 1.3 were matched to obtain the software plan ID with the same name as the keyword, which was used in step 2.9 to obtain the software release requirements and bug data contained in the keyword.

[0078] Step 2.6: Match the keyword "Product 1_v1.1.1" captured in Step 1.3 with the software plan list obtained in Step 2.5 to find the software plan ID corresponding to "Product 1_v1.1.1".

[0079] Because a matching function has been implemented, we can obtain the software plan ID with the same name as the keyword, which can be used in step 2.9 to obtain the software release requirements and bug data contained in the keyword.

[0080] Step 2.7: If no match is found, return to step 2.6; if a match is found, proceed to step 2.8.

[0081] Since the matching result was successful, it can be used for potential problem analysis and troubleshooting. Printing out the matching result will facilitate quick location and analysis when retrieving ZenTao data fails in the future.

[0082] Step 2.8: Based on the software plan ID successfully matched in Step 2.7, obtain the requirements and bug data associated with the software plan "Product 1_v1.1.1".

[0083] Because the requirements and bugs related to keyword acquisition have been addressed, this data can be written to text data and stored in the folder created in step 1.5 for archiving and tracing; and used in step 3.6 to push the data to DingTalk.

[0084] Step 2.9: Write the obtained requirements and bug reports into text data;

[0085] Because a text writing function has been implemented, this data can be written to a text file and stored in the folder created in step 1.5 for archiving and traceability. It will also be used in step 3.3 to read and push the data to DingTalk; and in step 4.6 to integrate it into the project software release information.

[0086] Step 2.10: If the text data writing fails, return to step 2.9; if the text data writing succeeds, proceed to step 2.11.

[0087] Because of the text write result judgment function, it can be used for potential problem analysis and troubleshooting. By printing out the write results, it is easy to quickly locate and analyze the problem if no text data is found in the folder in step 1.5.

[0088] Step 2.11: Copy the successfully written text data to the specified folder mentioned in Step 1.4;

[0089] Because a copy function is implemented, the successfully written text data can be copied to the specified folder described in step 1.4.

[0090] Step 2.12: If the text data copy fails, return to step 2.11; if the text data copy succeeds, proceed to step 3.1.

[0091] Because a copy result judgment function was implemented, it is used to analyze and troubleshoot when the copy result is successful. Step 3.1 is executed only when the copy is successful; otherwise, step 2.11 is executed.

[0092] Step S2 enables the automatic acquisition of ZenTao software data based on the keywords in step S1, greatly improving work efficiency and avoiding problems caused by manual operation each time.

[0093] In step S3, Jenkins communicates with the office software API, reads the requirements and bugs from the specified path, and automatically publishes the software to push notifications to relevant personnel. The specific implementation is as follows:

[0094] Step 3.1: Read the text data written in Step 2.9;

[0095] Because a reading function was implemented to read text data for further processing, the final text was pushed to DingTalk.

[0096] Step 3.2: Determine the return result of the text data reading. If the returned content is invalid, return to step 3.1; if the returned content is valid, proceed to step 3.3.

[0097] Because a function to judge the text reading results was implemented, it facilitates quick location and analysis of potential text data reading failures in the future.

[0098] Step 3.3: Write the read data into a string variable and define a specific publishing format;

[0099] Because of the defined publishing format function, customized solutions can be implemented according to different needs.

[0100] Step 3.4: Configure the custom robot accessed via Webhook through DingTalk, obtain the URL of the Webhook, and send a POST request to the DingTalk software through Jenkins;

[0101] By making a push POST request, communication between Jenkins and DingTalk was achieved.

[0102] Step 3.5: Determine the return result of the POST request. If the returned content is invalid, return to step 3.4; if the returned content is valid, proceed to step 3.6.

[0103] Because a function to check the return result of a POST request was implemented, it is used for troubleshooting and analysis of potential issues with subsequent requests. If the returned content is invalid, return to step 3.4; if the returned content is valid, proceed to step 3.6.

[0104] Step 3.6: Push the notification to the DingTalk group via Markdown message type to notify relevant people;

[0105] Because the function of pushing data to DingTalk was implemented, the characteristic publishing format defined in step 3.3 was realized, and the function of pushing data to DingTalk was achieved.

[0106] Step 3.7: Determine the return result of the notification. If the return result is unsuccessful, return to step 3.6; if the return result is successful, proceed to step 4.1.

[0107] The notification result evaluation function is implemented for analyzing and troubleshooting issues caused by unsuccessful push notifications. If the result returns failure, return to step 3.6; if the result returns success, proceed to step 4.1.

[0108] Step S3 enables the automatic reading of the ZenTao data obtained in step S2, its personalized formatting, and automatic push notifications to DingTalk. This fully automated process significantly reduces labor costs.

[0109] In step S4, the project software to which the software version belongs is determined based on the keyword of the software version number to be released. The completed requirements and resolved bug data corresponding to the software version are temporarily stored in the corresponding project software path. When Jenkins polls for the project software commit information of the Git repository code, it iterates through the text data under the project software and pushes the text data to relevant personnel through office software. The specific implementation is as follows:

[0110] Step 4.1: Determine whether the keyword "product1_v1.1.1" captured in step 1.3 belongs to the pick and place machine project software or the non-pick and place machine project software.

[0111] Because a keyword detection function was implemented, the keywords captured in step 1.3 were used to determine which project software the keyword belonged to. These keywords were then stored separately in the corresponding project software folder mentioned in step 4.2 or step 4.3, and used to read data in step 4.6, integrate it into the specific publishing format mentioned in step 4.8, and push it to DingTalk in step 4.8.

[0112] Step 4.2: If "Product 1_v1.1.1" belongs to the pick and place machine project software, store the text data in the pick and place machine camera software folder at the same time;

[0113] Because of the storage function, the text data is not only stored in the folder named by the keyword in step 1.5, but also in the pick-and-place machine project software folder, for use in step 4.6 to traverse the data in that folder.

[0114] Step 4.3: If "Product 1_v1.1.1" belongs to the non-pick-and-place machine project software, store the text data in the non-pick-and-place machine camera software folder at the same time.

[0115] Because of the storage function, the text data is not only stored in the folder named by the keyword in step 1.5, but also in the non-pickup machine project software folder, for use in step 4.6 to traverse the data in that folder.

[0116] Step 4.4: When the pick-and-place machine project software keywords are captured in step 1.1, extract the pick-and-place machine project software keyword variables;

[0117] Because a keyword extraction function was implemented, similar to the function in step 1.1, the keyword "pick-and-place machine project software" was extracted for use in step 4.5 to create a folder and store data.

[0118] Step 4.5: Based on the software keyword variable of the pick-and-place machine project, create the pick-and-place machine project software folder in the specified path;

[0119] Because the function of creating folders named with keywords at specified paths was implemented, similar to the method in step 1.4, the keyword "Pick-and-Send Machine Project Software" obtained in step 4.4 was combined with the URL link of the network external storage path to form a path. This enabled the creation of variables named "Pick-and-Send Machine Project Software" under the specified path. This allows the creation of folders across local computers, enabling others with network external storage access to view files and access data.

[0120] Step 4.6: Traverse the text data stored in the pick-and-place machine project software folder;

[0121] Because the function of traversing text data has been implemented, the text data in the folder can be integrated and used for personalization in step 4.8.

[0122] Step 4.7: Determine the return result of the text data. If the returned content is invalid, return to step 4.6; if the returned content is valid, proceed to step 4.8.

[0123] Because a function to judge the results of text data reading has been implemented, it can be used to analyze and troubleshoot problems when text data reading fails.

[0124] Step 4.8: Write the read data into a string variable, define a specific publishing format, and push it to the DingTalk group through a Markdown message notification type to notify relevant people;

[0125] Because of the push notification feature, custom-formatted data can be pushed to DingTalk to notify relevant people.

[0126] Step 4.10: Determine the return result of the notification. If the return fails, return to step 4.9; if the return succeeds, execute step 4.11.

[0127] Because a notification result return function was implemented, it can be used for analysis and troubleshooting when a notification fails.

[0128] Step 4.11: When the non-pick-and-place machine project software keyword is captured in step 1.1, extract the non-pick-and-place machine project software keyword variable; similarly, the non-pick-and-place machine project software executes steps 4.5-4.10 (the subsequent processing logic of the pick-and-place machine project software and the non-pick-and-place machine camera software is the same, and the keywords are used to distinguish them at the beginning).

[0129] Step S4 enables the automatic retrieval of keywords such as "patch machine project software" or "non-patch machine project software" based on Git commit information, automatic traversal of text data, personalized customization, and automatic push notifications to DingTalk.

[0130] This invention provides a technical solution for automated deployment based on Jenkins and project management software, comprising: writing a Jenkins pipeline script to poll git repository code commit information through Jenkins to obtain a specific software version number; upon detecting the specific software version number, communicating with the project management software via API through Jenkins to obtain the requirements and bugs associated with that software version in the ZenTao software, writing the completed requirements and resolved bugs data of that software version into a text file, and backing it up to a specified path; communicating with DingTalk via API through Jenkins to read the completed requirements and resolved bugs data of that software version, and pushing it to the DingTalk group as a Markdown message notification to notify relevant personnel; simultaneously determining which project software the software version belongs to, temporarily storing the completed requirements and resolved bugs data of that software version in the corresponding project software path, and when Jenkins detects the project software commit information of the git repository code, iterating through the text data under that project software and pushing it to the DingTalk group as a command text notification via a Markdown message notification to notify relevant personnel. This solution can automatically capture commit information for specific software versions of Git repository code, thereby completing the automated release of that software version. This greatly improves work efficiency and avoids the problem of incomplete release information caused by manual mechanical operations, significantly reducing work errors.

[0131] Based on the same inventive concept, a second aspect of the present invention provides an automated software release system based on Jenkins and project management software, comprising:

[0132] The keyword capture module is used to trigger Jenkins to automatically poll the commit information of the Git repository based on the Jenkins pipeline script in order to capture the keyword of the software version number to be released;

[0133] The requirement identification module is used for API communication between Jenkins and project management software to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path.

[0134] The automatic software release module is used for Jenkins to communicate with the office software API, read the requirements and bugs from the specified path, and automatically release the software and push notifications to relevant personnel. At the same time, it determines the project software to which the software version belongs based on the keyword of the software version number to be released, and temporarily stores the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path. When Jenkins polls for the project software commit information of the Git repository code, it traverses the text data under the project software and pushes the text data to relevant personnel through the office software.

[0135] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the above-described automatic software release method based on Jenkins and project management software.

[0136] A fourth aspect of the present invention provides an electronic device, the electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the above-described automatic software release method based on Jenkins and project management software.

[0137] Although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

[0138] Therefore, the above description is only a preferred embodiment of this application and is not intended to limit the scope of this application; that is, all equivalent modifications made in accordance with the scope of the claims of this application shall be within the protection scope of the claims of this application.

Claims

1. A method for automated software deployment based on Jenkins and project management software, characterized in that, Includes the following steps: Based on the Jenkins pipeline script, Jenkins is triggered to automatically poll the commit information of the Git repository code in order to capture the version number keyword of the software to be released; Jenkins communicates with the project management software via API to automatically obtain the requirements and bugs associated with the version number of the software to be released, writes the requirements and bugs into text data and backs them up to a specified path. Jenkins communicates with the office software API to read the requirements and bugs from the specified path and automatically publishes the software to push notifications to relevant personnel. At the same time, it determines the project software to which the software version belongs based on the keyword of the software version number to be published, and temporarily stores the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path. When Jenkins polls for the project software commit information of the Git repository code, it traverses the text data under the project software and pushes the text data to relevant personnel through the office software. The Jenkins interface communicates with the office software API, reads the requirements and bugs from the specified path, and automatically publishes the software, pushing notifications to relevant personnel. The process includes the following: S31. Read text data. S32. Determine the return result of the read text data. If the returned content is invalid, proceed to step S31; if the returned content is valid, proceed to step S33. S33. Write the read data into a string variable and define a specific publishing format; S34. Based on the office software settings, implement a custom robot that is accessed via Webhook, obtains and sends POST requests to the office software, and realizes communication between Jenkins and the office software API; S35. Determine the return result of the POST request. If the returned content is invalid, return to step S34. If the returned content is valid, proceed to step S36; S36. Notify relevant personnel of the returned results via office software; S37. Determine the return result of the notification. If the return fails, return to step S36.

2. The method according to claim 1, characterized in that, The Jenkins pipeline script triggers Jenkins to automatically poll the commit information of the Git repository in order to capture the keyword of the software version number to be released. The process includes the following: S11. Based on Jenkins, use Webhook to poll the commit information of the Git repository in real time until the keyword "product1_v1.1.1" of the software version number to be released is captured; S12. Extract the keyword "product1_v1.1.1" of the software version number to be released and create a storage folder in the specified path.

3. The method according to claim 2, characterized in that, The Jenkins API communicates with the project management software to automatically obtain the requirements and bugs associated with the version number of the software to be released and back them up to a specified path, including the following processes: S21. Based on Jenkins, send a POST request to the project management software via HttpRequest to obtain the project management software's Tokens; S22. Determine the Tokens retrieval result returned by the httpRequest. If the returned content is invalid, return to step S21; if the returned content is valid, continue to the next step. S23. Based on "Product1_v1.1.1" in step S11, extract the software keyword "Product1"; S24. Obtain the ID of the software to which "Product 1" belongs through the project management software; S25. Traverse the software plan list under the corresponding software according to the software ID; S26. Match "Product 1_v1.1.1" in step S11 with the software plan list in step S25 to find the software plan ID corresponding to "Product 1_v1.1.1"; S27. If no match is found, return to step S26; if a match is found, continue to the next step. S28. Based on the software plan ID successfully matched in step S27, obtain the requirements and bug data associated with the corresponding software plan; S29. Write the acquired requirements and bug data into text data; S210. If the text data writing fails, return to step S29; if the text data writing succeeds, continue to the next step. S211. Copy the successfully written text data to the storage folder described in step S12; S212. If text data copying fails, return to step S211; if text data copying succeeds, continue to the next step.

4. The method according to claim 3, characterized in that, The process involves determining the project software to which the software version belongs based on the keyword of the software version number to be released, and temporarily storing the completed requirements and resolved bug data corresponding to the software version in the corresponding project software path. When Jenkins polls for project software commit information in the Git repository, it iterates through the text data under that project software and pushes the text data to relevant personnel via office software. The process includes the following: S41. Based on the software version keyword "product1_v1.1.1" captured in step S11, determine whether the project software to which "product1" belongs is pick-and-place machine project software or non-pick-and-place machine project software. S42. If the software belongs to the pick-and-place machine project, the text data is also stored in the pick-and-place machine camera software folder; if the software belongs to a non-pick-and-place machine project, the text data is also stored in the non-pick-and-place machine camera software folder. S43. When the pick and place machine project software keyword is captured in step S11, extract the pick and place machine project software keyword variable. S44. Create a pick-and-place machine project software folder in the specified path based on the pick-and-place machine project software keyword variable; S45. Traverse the text data already stored in the pick-and-place machine project software folder; S46. Determine the return result of traversing the text data in step S45. If the returned content is invalid, return to step S45; if the returned content is valid, execute step S47. S47. Write the read data into a string variable and define a specific publishing format; S48. Push notifications to relevant people using Markdown message notification types; S49. Determine the return result of the notification. If the return fails, return to step S48; if the return succeeds, execute step S410. S410. When the non-pickup machine project software keyword is captured in step S11, the non-pickup machine project software keyword variable is extracted, and a non-pickup machine project software folder is created in the specified path according to the non-pickup machine project software keyword variable. S411, Traverse the text data already stored in the software folder for non-pickup machine projects; S412. Determine the return result of traversing the text data in step S411. If the returned content is invalid, return to step S411; if the returned content is valid, execute step S413. S413. Write the read data into a string variable and define a specific publishing format; S414. Push notifications to relevant people using Markdown message notification types; S415. Determine the return result of the notification. If the return fails, return to step S414. If a success message is returned, the automatic software deployment has been successfully completed.

5. An automated software release system based on Jenkins and project management software, characterized in that, include: The keyword capture module is used to trigger Jenkins to automatically poll the commit information of the Git repository based on the Jenkins pipeline script in order to capture the keyword of the software version number to be released; The requirement identification module is used for API communication between Jenkins and project management software to automatically obtain the requirements and bugs associated with the version number of the software to be released, write the requirements and bugs into text data and back them up to a specified path. The automatic software release module is used for Jenkins to communicate with the office software API. It reads the requirements and bugs from the specified path, automatically releases the software, and pushes notifications to relevant personnel. Simultaneously, it determines the project software to which the software version belongs based on the keyword of the software version number to be released, and temporarily stores the completed requirements and resolved bugs corresponding to the software version in the corresponding project software path. When Jenkins polls for project software commit information in the Git repository, it iterates through the text data under that project software and pushes the text data to relevant personnel via the office software. The process includes the following: S31. Read text data. S32. Determine the return result of the read text data. If the returned content is invalid, proceed to step S31; if the returned content is valid, proceed to step S33. S33. Write the read data into a string variable and define a specific publishing format; S34. Based on the office software settings, implement a custom robot that is accessed via Webhook, obtains and sends POST requests to the office software, and realizes communication between Jenkins and the office software API; S35. Determine the return result of the POST request. If the returned content is invalid, return to step S34. If the returned content is valid, proceed to step S36; S36. Notify relevant personnel of the returned results via office software; S37. Determine the return result of the notification. If the return fails, return to step S36.

6. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method according to any one of claims 1-4.

7. An electronic device, the electronic device comprising: One or more processors; And a memory for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the method according to any one of claims 1-4.

Images