Perl, SVN and crontab-based continuous integrated construction configuration management method

Abstract

The invention provides a continuous integration construction configuration management method based on Perl, SVN and crontab, and belongs to the technical field of communication software, automatic continuous integration of codes in the software development process is achieved based on Perl, SVN and crontab tools, when branch code changes are monitored in a polling mode and application rules are met, main line code obtaining and branch code pre-merging are triggered, merge conflicts are solved, and the problem that the branch code changes in the prior art is solved. A simulation tool is started, after task execution is completed, related personnel are immediately informed of task execution logs and results in a mail mode, and the research and development closed-loop testing and configuration management process of software continuous integration is achieved. Repeated self-test operation time of developers and branch merging time of configuration management engineers are reduced, problems introduced by manual operation are avoided, the problems are found efficiently and quickly, code integrity is ensured, and working efficiency of the developers and the configuration management engineers is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of communication software, and particularly to a continuous integration and build configuration management method based on Perl, SVN, and crontab. Background Art

[0002] With the increasing emphasis of end customers on product quality and the increasingly fierce industry competition, while requiring products to continuously improve quality, the time to market needs to be shortened in order to seize the market and gain the upper hand. In the software R & D process, in order to quickly respond to user needs, cope with frequent requirement changes, and improve software quality, developers need to continuously update code, conduct code reviews, self-test, apply to merge into the main line, and assist configuration management personnel to resolve merge conflicts and other repetitive tasks, so as to discover problems as early as possible.

[0003] The following problems exist in the prior art:

[0004] 1) Each developer needs to build a self-test environment on their local machine;

[0005] 2) Manually operate use cases to traverse and query execution results;

[0006] 3) The code modification upload is incomplete;

[0007] 4) The self-test version is inconsistent with the code library;

[0008] 5) No code self-test is performed, introducing new problems;

[0009] 6) The configuration management engineer manually merges the code, which is laborious, time-consuming, and error-prone;

[0010] 7) When merging the code into the main line, resolving code conflicts is inefficient and error-prone;

[0011] 8) The branch code is not merged in a timely manner, affecting the work of others;

[0012] 9) The work of developers is easily interrupted (assisting configuration management personnel to resolve merge conflicts);

[0013] 10) It is impossible to frequently submit incomplete modifications;

[0014] 11) The task is forced to be interrupted, and local code modifications are easily lost and difficult to continue. Summary of the Invention

[0015] To solve the above technical problems, the present invention provides a continuous integration build configuration management method based on Perl, SVN, and crontab, which can not only closely monitor the correctness of the code repository, but also automatically complete the preset self-test tasks and merge tasks without unattended operation, complete the repetitive self-test process and merge work, improve efficiency; by identifying and fixing problems in the R & D process faster, improve code quality and ensure the stability of the main line of the code repository.

[0016] The technical solution of the present invention is:

[0017] A continuous integration build configuration management method based on Perl, SVN, and crontab, which realizes the automatic continuous integration of code in the software development process based on perl, SVN, and crontab tools. When the branch code change is detected by polling and meets the application rules, it triggers the acquisition of the main line code, pre-merging of the branch code, resolution of merge conflicts, starts the simulation tool, and immediately notifies the relevant personnel of the task execution log and results in the form of an email after the task is completed, realizing the closed-loop test and configuration management process of software continuous integration.

[0018] Furthermore,

[0019] By adopting a specific directory structure, stipulating the SVN usage rules, writing perl scripts, configuring the Linux environment, using crontab to set up a timed task to execute the perl script to poll and monitor the changes of the personal branch code. If the code is updated and the latest commit log meets the established rules for the branch to be applied to the main line, all information except the version information in the working area is cleared, automatically triggering the acquisition of the main line code and pre-merging of the branch code, automatically resolving merge conflicts other than non-tree conflicts, judging the application scenario based on the information provided by the R & D branch, obtaining the corresponding simulation test list, starting the simulation test, collecting and analyzing the task execution log, judging whether to submit the pre-merged branch code and branch deletion and reconstruction according to the analysis results, uploading the execution log, and notifying the relevant personnel of the task execution results by email, forming a closed-loop configuration management process, and realizing the continuous integration of code.

[0020] Still further,

[0021] When the branch modification is eager to be merged into the main line, the above process supports all branch owners to manually trigger the execution of the perl script to complete.

[0022] Still further,

[0023] The specific steps are as follows:

[0024] 1) The developer submits and modifies the personal branch code;

[0025] 2) When the crontab - set periodic time is reached or triggered manually by the developer, the perl script starts to execute;

[0026] 3) Determine whether there are other branch tasks currently being executed. If so, exit the task and inform all branch members by email; if not, obtain the latest log information of the branch and check whether it contains the word "merge";

[0027] 4) If it does not contain the word "merge", exit the task; if it contains the word "merge", check whether the branch has pulled all the modifications of the current main line;

[0028] 5) If not pulled, terminate the task and notify all branch members by email; if already pulled, clear all information in the working area except version.txt, update the version information in version.txt, obtain the main - line code, pull the modifications of the branch, automatically resolve conflicts, determine the application scenario based on the log information, obtain the corresponding simulation test list, and start the simulation test;

[0029] 6) If the simulation fails, upload the log according to the application scenario and inform all branch members by email; if the simulation is successful, obtain the latest revision number of the current main line and compare it with the branch revision number;

[0030] 7) If the main - line revision number is newer than the branch revision number, send an email message to the code submitter and terminate the submission task; if the main - line revision number is older than the branch revision number, then perform the code submission;

[0031] 8) After the code submission is completed, delete the R & D branch, recreate the R & D personal branch based on the main line, and notify the code submitter and relevant developers by email.

[0032] Furthermore,

[0033] Save the version number information of the current task being executed by the branch for subsequent judgment of whether there are code updates in the branch.

[0034] When starting to execute the task, generate branch information of the task being executed in the public directory, and delete the information when the task ends.

[0035] When the branch code applies to be merged into the main line, the latest commit log information contains the agreed information; first, take the latest modification pulled from the main line as a single commit to the personal branch, and submit it separately from the personal modification.

[0036] When the perl script is executed, after determining that the branch meets the conditions for applying to be merged into the main line, clear all information in the local working area except version.txt, and re - obtain the code to avoid being interfered by the previous result.

[0037] When the simulation test is successful and modifications are submitted to the main line, the log information must include all modification information of the branch based on the Base, which is convenient for viewing the modification points of the corresponding branch of the current version and rolling back the code;

[0038] ④ Obtain all the modification log information involved in the developer's branch this time;

[0039] ⑤ Submit the log information of the developer's branch as the modification point of the main line;

[0040] ⑥ Quickly locate and jump to the corresponding modification through the detailed change points.

[0041] Compare the revision numbers of the main line and the branch to be merged in to ensure that the developers have viewed the modification points of the current latest main line, avoid function failures caused by semantic conflicts, and ensure the continuous stability of the main line.

[0042] The beneficial effects of the present invention are

[0043] 1) The SVN revision number is for the entire code repository. The revision number obtained for any change in the code repository is unique and increases sequentially in order. For software developed through team collaboration, the revision numbers must be compared before merging the branch into the main line to avoid function failures caused by semantic conflicts and ensure the stability of the main line;

[0044] 2) Using the SVN configuration management tool, adopting the directory structure of the main line and the developer's personal branch instead of the traditional main line and version branch structure is beneficial for:

[0045] ① Developers can submit modifications frequently to avoid losing local modifications;

[0046] ② Not affected by space, existing modifications can be obtained at any time;

[0047] ③ Not coexisting with others' modifications, which is beneficial for developers to debug the modification points;

[0048] ④ During the debugging process, it is beneficial for code rollback and problem troubleshooting;

[0049] ⑤ Multiple personal branches can be owned for parallel development work without mutual influence. When the task is paused and then restarted, the existing work progress can be quickly known through the clean history record.

[0050] 3) It is not necessary to immediately merge the personal branch into the main line for every modification submission. Therefore, by restricting the log information, the incorporation of incomplete functions can be avoided;

[0051] 4) Before merging the branch code into the main line, developers must first pull the latest modifications from the main line to their personal branches, resolve conflicts, and avoid leaving conflicts to be resolved when merging into the main line. This provides a guarantee for the automatic merging of branch code into the main line, and at the same time enables developers to understand others' modifications earlier, avoid semantic conflicts, and efficiently resolve conflict issues;

[0052] 5) Use perl scripts, svn, and crontab scheduled tasks to achieve continuous integration of the software, facilitating real-time adjustment and update of perl scripts as needed to add functions, and achieving continuous improvement;

[0053] 6) Adopt the perl+svn+crontab structure, which is easy to rebuild the environment repeatedly and is of high quality and efficiency. Description of the Drawings

[0054] Figure 1 is a schematic diagram of the automated continuous integration configuration management process;

[0055] Figure 2 is a schematic diagram of the work flow of the continuous integration build configuration management party;

[0056] Figure 3 is a schematic diagram of a specific SVN directory structure. Detailed Implementation Manner

[0057] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0058] The present invention provides a continuous integration build configuration management method based on Perl, SVN, and crontab, mainly using perl+SVN+crontab to form a continuous integration system. SVN is an open-source source code management tool that saves source code and change records, provides log information for branch applications to the main line, and adopts a specific directory structure; tasks such as detecting whether the branch code is modified, whether it meets the rules for applying to the main line, obtaining the main line code, pre-merging the branch code, conflict resolution, simulation testing, result analysis, whether to submit the pre-merged code, deleting and reconstructing the branch, and emailing the result notification are encapsulated in perl scripts; scheduled tasks are set through the crontab tool so that the tasks can be executed periodically. Use the csh environment of the Linux system to create an alias for the execution of perl tasks, so that when developers are eager to merge branch modifications into the main line, they can manually trigger the task execution without waiting.

[0059] The implementation process of the continuous integration build configuration management method is as follows Figure 2 , which mainly includes branch code submission, periodic execution of perl scripts by crontab, judging whether there is a branch executing tasks, monitoring changes in the repository branches, code acquisition, conflict resolution, simulation testing, code submission, branch deletion and reconstruction, and feedback of task execution results. Preliminary preparations:

[0060] 1) Set up an SVN server, create a code repository, with the directory structure of Trunk, Branches, and Tag;

[0061] All branches mentioned in this method are the personal branches of developers, rather than software version branches, which is beneficial for:

[0062] ① Developers can frequently submit code modifications without worrying about affecting others' work;

[0063] ② Frequent code modifications can narrow down the scope of problem troubleshooting, which is beneficial for troubleshooting and positioning problems and improving the efficiency of problem troubleshooting;

[0064] ③ Developers do not need to manually execute unit tests, and the crontab scheduled task periodically executes perl scripts to complete branch modification detection, simulation testing, etc. and feedback the results;

[0065] ④ It is easy for developers to view personal modification information without interference information;

[0066] ⑤ It is easy to roll back the code and discard existing modification points;

[0067] ⑥ Developers can choose when to pull which modification points of the main line by themselves, avoiding irrelevant modifications in the personal branches of developers and affecting debugging.

[0068] 2) Under Branches, create personal branches for developers A, B, C... respectively, which are readable but not writable by others;

[0069] 3) Formulate the rules for branches to apply to the main line:

[0070] ① The latest commit log information of the branch contains the word "merge";

[0071] ② The branch has pulled all the modifications of the current main line (to facilitate timely and efficient conflict resolution).

[0072] 4) Developers A, B, C... respectively code, write test cases, and submit them to their respective personal branches in the source code management library SVN. SVN will record information such as the current submitted version and modification time. For subsequent new functional modules or changes to existing modules, the source code will be continuously incorporated into SVN for management on this basis;

[0073] 5) Complete the writing of the Perl script (including: judging whether there is a task being executed, code acquisition, pre-merge of branches, conflict resolution, recording version information, simulation testing, etc.), and complete the relevant environment configuration;

[0074] 6) Use the crontab tool to create a scheduled task to periodically execute the Perl script;

[0075] 7) Complete the Linux environment configuration to facilitate developers to manually execute the Perl script.

[0076] The specific steps of the implementation process of the continuous integration build configuration management method are as follows:

[0077] 1) Developers submit modifications to their personal branch code;

[0078] 2) When the cycle time set by crontab is reached or developers manually trigger, the Perl script starts to execute;

[0079] 3) Judge whether there are other branch tasks being executed currently. If so, exit the task and notify all branch owners by email; if not, obtain the latest log information of the branch and judge whether it contains the word "merge";

[0080] 4) If it does not contain the word "merge", exit the task; if it contains the word "merge", judge whether the branch has pulled all the modifications of the current main line;

[0081] 5) If not pulled, terminate the task and notify all branch owners by email; if already pulled, clear all information in the working area except version.txt, update the version information in version.txt, obtain the main line code, pull the modifications of the branch, automatically resolve conflicts, judge the application scenario based on the log information, obtain the corresponding simulation test list, and start the simulation test;

[0082] 6) If the simulation fails, upload the log according to the application scenario and notify all branch owners by email; if the simulation is successful, obtain the latest revision number of the current main line and compare it with the branch revision number;

[0083] 7) If the main line revision number is newer than the branch revision number, send an email message to the code submitter and terminate the submission task. If the main line revision number is older than the branch revision number, perform the code submission;

[0084] 8) After the code submission is completed, delete the R & D branch, recreate the R & D personal branch based on the main line, and notify the code submitter and relevant developers by email.

[0085] Key points:

[0086] 1) Save the version number information of the current task executed by the branch to facilitate subsequent judgment of whether there is an update to the branch code;

[0087] 2) When starting to execute a task, branch information of the executing task is generated in the public directory and deleted when the task ends;

[0088] 3) When applying to merge branch code into the main line, the latest commit log information must contain the agreed information, such as: merge;

[0089] ① When applying to merge branch code into the main line, the developer must first submit the latest modification pulled from the main line as a single commit to the personal branch, which must be submitted separately from the personal modifications, facilitating quick problem location in case of failed simulation testing; and facilitating rollback of code modification points.

[0090] 4) When the perl script is executed, after determining that the branch meets the conditions for applying to merge into the main line, all information in the local working area except version.txt is cleared, and the code is retrieved again to avoid being interfered by the previous result;

[0091] 5) When the simulation test is successful and the modification is submitted to the main line, the log information must contain all modification information of the branch based on Base, facilitating viewing of the branch modification points corresponding to the current version and code rollback;

[0092] a) Obtain all modification log information involved in the developer's branch this time;

[0093] b) Submit the log information of the developer's branch as the modification point of the main line to facilitate others to understand the more detailed change points;

[0094] c) Through the detailed change points, it can help quickly locate and jump to the corresponding modification.

[0095] 6) Compare the revision numbers of the main line and the branch to be merged to ensure that the developer has viewed the modification points of the current latest main line, avoid function failures caused by semantic conflicts, and ensure the continuous stability of the main line;

[0096] 7) After the branch is successfully merged, delete the developer's branch and recreate a branch based on the main line, which is beneficial for:

[0097] a) When the developer pulls the modification points of the main line, narrow the selection range;

[0098] b) Avoid repeated pulling of the developer's own modifications when the personal branch pulls modifications from the main line;

[0099] c) When performing the pull, shorten the svn calculation time and improve the execution efficiency.

[0100] The above are only the preferred embodiments of the present invention, which are only used to illustrate the technical solutions of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are all included in the protection scope of the present invention.

Claims

1. A continuous integration construction configuration management method based on Perl, SVN and crontab, characterized in that: Based on perl, SVN and crontab tools, automatic continuous integration of code is realized in the software development process. When polling monitors branch code changes and meets the application rules, the mainline code acquisition, branch code pre-merge, merge conflict resolution, and simulation tool are triggered. When the task is completed, the task execution log and results are immediately notified to relevant personnel in the form of emails, realizing the R&D closed-loop testing and configuration management process of continuous software integration.

2. The method according to claim 1, characterized in that By setting the directory structure, agreeing on SVN usage rules, writing perl scripts, configuring the Linux environment, and using crontab to set up a scheduled task to execute the perl script to poll and monitor changes in personal branch code, if the code is updated and the latest submission log meets the established rules for branch application to the main line, all information in the workspace except the version information will be cleared, and the mainline code acquisition and branch code pre-merge will be automatically triggered. Merge conflicts other than non-tree conflicts will be automatically resolved. Based on the information provided by the R&D branch, the application scenario is determined, the corresponding simulation test list is obtained, the simulation test is started, the task execution log is collected and analyzed, and based on the analysis results, it is determined whether to submit the pre-merged branch code and branch deletion and reconstruction, upload the execution log, and notify the relevant personnel of the task execution results by email, forming a closed loop of the configuration management process and realizing continuous integration of code.

3. The method according to claim 2, characterized in that When branch modifications are eager to be merged into the main line, the above process supports the branch owner to manually trigger the execution of the perl script to complete it.

4. The method according to claim 3, characterized in that The specific steps are as follows: 1) Developers submit modifications to their personal branch code; 2) When the cycle time set by crontab is reached or the developer manually triggers it, the perl script starts executing; 3) Determine whether there are other branch tasks currently being executed. If so, exit the task and notify the branch owner by email; if not, obtain the latest branch log information to determine whether it contains the word merge; 4) If the word "merge" is not included, exit the task; if the word "merge" is included, determine whether the branch has pulled all the changes of the current main line; 5) If the data is not pulled, the task is terminated and the branch owner is notified by email; If it has been pulled, clear all information in the workspace except version.txt, update the version information in version.txt, obtain the mainline code, pull the branch changes, automatically resolve conflicts, determine the application scenario based on the log information, obtain the corresponding simulation test list, and start the simulation test; 6) If the simulation fails, upload the log according to the application scenario and notify the branch owner by email; if the simulation succeeds, obtain the latest revision number of the current main line and compare it with the branch revision number; 7) If the mainline revision number is newer than the branch revision number, send an email to the code submitter and terminate the submission task. If the mainline revision number is older than the branch revision number, submit the code; 8) After the code is submitted, delete the R&D branch, re-create the R&D personal branch based on the main line, and notify the code submitter and related developers by email.

5. The method according to claim 4, characterized in that Save the version number information of the branch's currently executed task to facilitate subsequent determination of whether the branch code has been updated.

6. The method according to claim 4, characterized in that When a task starts to be executed, the branch information of the task being executed is generated in the public directory, and when the task ends, its information is deleted.

7. The method according to claim 4, characterized in that When applying to merge branch code into the main line, the latest submission log information contains the agreed information; first submit the latest changes of the pulled main line as a single submission to the personal branch, and submit it separately from the personal changes.

8. The method according to claim 4, characterized in that When the perl script is executed, if it is determined that the branch meets the conditions for applying to enter the main line, all information except version.txt in the local workspace will be cleared, and the code will be retrieved again to avoid interference from the previous results.

9. The method according to claim 4, characterized in that When the simulation test is successful and the changes are submitted to the main line, the log information must include all the modification information of the branch based on the Base, so as to facilitate the viewing of the branch modification points and code rollback corresponding to the current version; ① Get all modification log information involved in the developer branch this time; ②Submit the developer branch log information as the modification point of the main line; ③ Through detailed change points, quickly locate and jump to corresponding modifications.

10. The method according to claim 4, characterized in that Compare the revision numbers of the main line with those of the branch to be merged to ensure that developers have reviewed the modification points of the latest main line, avoid functional failures due to semantic conflicts, and ensure the continued stability of the main line.

Images