CN112667282A - Version management method, related device and computer medium - Google Patents
Version management method, related device and computer medium Download PDFInfo
- Publication number
- CN112667282A CN112667282A CN202011627955.1A CN202011627955A CN112667282A CN 112667282 A CN112667282 A CN 112667282A CN 202011627955 A CN202011627955 A CN 202011627955A CN 112667282 A CN112667282 A CN 112667282A
- Authority
- CN
- China
- Prior art keywords
- branch
- binary
- test
- trunk
- trunk branch
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000007726 management method Methods 0.000 title claims abstract description 43
- 238000012360 testing method Methods 0.000 claims abstract description 113
- 238000000034 method Methods 0.000 claims abstract description 38
- 238000003860 storage Methods 0.000 claims abstract description 16
- 229910002056 binary alloy Inorganic materials 0.000 claims abstract description 13
- 230000006870 function Effects 0.000 claims description 55
- 238000004590 computer program Methods 0.000 claims description 5
- 238000003908 quality control method Methods 0.000 abstract description 5
- 238000011161 development Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 9
- 244000141353 Prunus domestica Species 0.000 description 6
- 230000008439 repair process Effects 0.000 description 6
- 238000005457 optimization Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000010354 integration Effects 0.000 description 4
- 238000004519 manufacturing process Methods 0.000 description 4
- 238000004806 packaging method and process Methods 0.000 description 3
- 238000012937 correction Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012806 monitoring device Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000003442 weekly effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The application discloses a version management method, a related device and a computer storage medium, wherein the method comprises the following steps: the first trunk branch of the current version can be obtained; optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch; testing the binary package to obtain a qualified binary package; determining a second trunk branch based on the binary packet qualified by the test; an optimized version is generated based on the second trunk branch. Therefore, the embodiment of the application converts the optimized trunk branch of the current software version into the binary package, and tests the optimized trunk branch by testing the binary package, so that testers do not need to test the binary packages compiled in different environments, and only need to be responsible for the binary package generated by the optimized trunk branch version submitted by developers, thereby not only improving the quality control capability of the version, but also improving the release efficiency of the version.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a version management method, a related apparatus, and a computer medium.
Background
Currently, most companies deploy and distribute corresponding services in different environments (testing environment, pre-release environment, production environment, etc.) and different machine rooms (ali, Tencent, etc.) during the development process of software programs, and the mode adopted is as follows: and pulling the source code of the corresponding version from the source code library, compiling and packaging the source code and publishing the source code on line. Although this mode is simple and reliable, source codes deployed and released in different environments need to be recompiled and packaged, which wastes time and cost and reduces release efficiency.
Disclosure of Invention
The embodiment of the application provides a version management method, a related device and a computer storage medium.
In a first aspect, an embodiment of the present application provides a version management method, where the method includes:
acquiring a first trunk branch of a current version;
optimizing the first trunk branch, and generating a binary system packet based on the optimized first trunk branch;
testing the binary package to obtain a qualified binary package;
determining a second trunk branch based on the test-eligible binary packet;
generating an optimized version based on the second trunk branch.
In a second aspect, an embodiment of the present application provides a version management apparatus, including:
the acquisition module is used for acquiring a first trunk branch of the current version;
a first generation module, configured to optimize the first trunk branch and generate a binary packet based on the optimized first trunk branch;
the obtaining module is used for testing the binary package to obtain a qualified binary package;
a second generation module, configured to determine a second trunk branch based on the test-qualified binary packet;
and the third generation module is used for generating an optimized version based on the second trunk branch.
In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-mentioned method steps.
In a fourth aspect, an embodiment of the present application provides an electronic device, which may include: a processor and a memory;
wherein the memory stores a computer program adapted to be loaded by the processor and to perform the above-mentioned method steps.
The beneficial effects brought by the technical scheme provided by some embodiments of the application at least comprise:
in the embodiment of the application, the first trunk branch of the current version can be obtained; optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch; testing the binary package to obtain a qualified binary package; determining a second trunk branch based on the binary packet qualified by the test; an optimized version is generated based on the second trunk branch. Therefore, in the embodiment of the application, the optimized trunk branch is converted into the binary package by testing the binary package, so that the tester does not need to test the binary package compiled in different environments, and only needs to be responsible for the binary package generated by the optimized trunk branch version submitted by the developer, thereby improving the quality control capability of the version and also improving the release efficiency of the version.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
Fig. 1 is a schematic diagram of an online release flow of a version management method according to an embodiment of the present application;
fig. 2 is a system architecture diagram of a version management method according to an embodiment of the present application;
fig. 3 is a flowchart illustrating a version management method according to an embodiment of the present application;
fig. 4 is a flowchart illustrating a further version management method according to an embodiment of the present application;
fig. 5 is a flowchart illustrating another version management method according to an embodiment of the present application;
fig. 6 is an application scenario diagram of a version management method according to an embodiment of the present application
Fig. 7 is a schematic structural diagram of a version management apparatus according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.
In the description of the present application, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
Fig. 1 exemplarily shows an online publishing flow diagram based on the version management method provided by the embodiment of the present application. The version management method provided by the embodiment of the application can be applied to a server.
Specifically, a may be a development phase, which refers to a phase of writing software codes, that is, a specific process of implementing each system module, and implementation contents include, but are not limited to, requirements of functions, performance, interfaces, and the like of the application software that need to be optimized. B may be a test phase, which is to test each function and repair a bug (bug) therein. C may be a release phase, which means that the function points passing the test are combined to generate an optimized version, and further released online. The method comprises the steps of firstly, enabling the main trunk to be branched, secondly, enabling the main trunk to be a functional branch, and thirdly, enabling the main trunk to be a binary package.
In the development stage and the test stage before the on-line release stage in the prior art, various unexpected situations can occur due to the fact that a plurality of personnel participate in a project and linkage among modules of the project is complex. For example: when two developers modify the same module at the same time, the second developer of the module covers the code of the first developer; the content tested by the tester is inconsistent with the content submitted by the developer; after the test fails, the wrong code can not be recovered to be normal; the developed code is lost and not merged into the backbone branches. These conditions can severely impact the speed of development and testing and also make it difficult to determine the cause of the error.
For the above problems, in the embodiment of the present application, the method and the system for generating the optimized version may be implemented by updating the source codes on the functional branches in the project in real time, generating the corresponding binary packages according to the source codes of the functions, and generating the optimized version only by testing the binary packages by the tester, so that the problems of time cost waste, low release efficiency and the like caused by recompilation and packaging of different environment deployment and release are avoided.
Fig. 2 is a system architecture diagram of a version management method applied to an embodiment of the present application. As shown in fig. 2, the server may be connected to the terminal through a network. The network is used to provide a communication link between the terminal and the server. The network may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. Terminals include, but are not limited to: wearable devices, monitoring devices, handheld devices, personal computers, tablet computers, in-vehicle devices, smart phones, computing devices or other processing devices connected to a wireless modem, and the like. The terminal devices in different networks may be called different names, for example: a monitoring device, a user equipment, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent or user equipment, a cellular telephone, a cordless telephone, a Personal Digital Assistant (PDA), a terminal device in a 5th generation mobile network or a future evolution network, etc. The terminal system is an operating system that can run on the terminal, is a program for managing and controlling terminal hardware and terminal applications, and is an indispensable system application of the terminal. The system comprises but is not limited to Android system, IOS system, Windows Phone (WP) system, Ubuntu mobile version operating system and the like.
It should be understood that the number of terminals, networks, and servers in fig. 2 is merely illustrative. There may be any number of terminals, networks and servers, as desired for the reality. For example, the server may be a server cluster composed of a plurality of servers. The user can use the server to interact with the terminal through the network so as to obtain the optimized version and the like.
Next, the version management method provided in the embodiment of the present application is described with reference to an on-line release flow diagram of the version management method described in fig. 1 and a system architecture diagram described in fig. 2.
In one embodiment, as shown in fig. 3, a flowchart of a version management method is provided. As shown in fig. 3, the version management method may include the steps of:
s301, acquiring a first trunk branch of the current version.
Wherein the first trunk branch is used to represent the current version of the source code, e.g., the master branch of Git (distributed version control system).
Specifically, Git is used as a free and open-source distributed version control system, so that the release and communication of source codes are convenient, developers can clone a complete Git warehouse (including source codes and version information) from a server to own computers, and branches are created according to different development purposes to modify the source codes.
S302, optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch.
The source code mode and the binary package in the first trunk branch are two forms of software packages. The source code (source code) needs to be compiled to generate the binary package (binary code).
Specifically, the source code packet refers to an original program code of a program, and the program can be generated and operated after being compiled on a computer, and the binary packet refers to a program which can be operated immediately after being compiled, and can be used immediately after being downloaded and installed.
It will be appreciated that the source code for generating the binary package may be submitted on its own computer after the developer has completed adding new functionality and/or modifying program vulnerabilities.
S303, testing the binary system packet to obtain the qualified binary system packet.
Before the new version is online operated, bugs possibly existing in an operating program of the new version need to be checked, but binary packages generated by compiling under different environments (such as development, test, pre-release, production and the like) may be different, so that the problems of excessive attention to the version, low release efficiency and the like exist in the detection process.
Therefore, in the test process, the embodiment of the application only needs to be responsible for the binary package generated based on the first trunk branch of the current version, that is, only the binary package is tested, so that the problems that the binary package is inconsistent and the like possibly caused by inconsistent compiling environments are solved.
It can be understood that, in the embodiment of the present application, a fixed code version can be directly released in different environments by compiling only once, for example, assuming that 4 environments for development, test, pre-release and production are compiled and packaged 1000 times per day, and the average time for compiling and packaging is calculated by 3 min/time, the prior art needs 3min 1000 — 50h per day, whereas the embodiment of the present application only needs to compile at the test stage, and takes 3min 250 — 12.5h, that is, the embodiment of the present application can save the waiting time of 3min 750 — 37.5 h).
And S304, determining a second trunk branch based on the binary packet qualified by the test.
Wherein the second trunk branch is used for representing source code for adding new functions and/or modifying the original version vulnerability.
Specifically, the embodiment of the present application may generate the second trunk branch based on the source code corresponding to the binary packet that is qualified in the test.
For example, a developer has repaired a flash back problem that may occur when a program is run in a first trunk branch, and has generated a binary package based on the optimized first trunk branch, and when the binary package passes a test, may generate a second trunk branch based on a source code corresponding to the binary package.
Possibly, if a conflict is found between the test-qualified binary packages from different developers on the second trunk branch, one of the testers may be required to resolve the conflict and then submit the conflict; the publication phase may be entered if there are no conflicts.
Possibly, the embodiment of the present application may mark (tag) on the generated second trunk branch to indicate that all new functions and/or the modified original version of the vulnerability test passes, and may enter the release phase.
And S305, generating an optimized version based on the second trunk branch.
Possibly, the embodiment of the application can not only utilize the binary package to perform version management, but also utilize the Docker mirror image to perform version management.
Wherein, the Docker (application container engine) is an open source application container engine, and uses a client-server architecture mode. Docker may package developer's applications into a portable image and then distribute them to computers that have Linux or Windows operating systems installed. A specific Docker container can be created by Docker mirroring, the container to mirror relationship is similar to the object and class in object-oriented programming.
For example, Docker envisions delivery of an operating environment like shipping, an operating system like a ship, each piece of software based on the operating system like a container, and developers can freely assemble the operating environment through standardized means, and the contents of the container can be customized by the developers. Thus, delivering a version of software is the delivery of a collection of standardized components.
In a specific example, a developer needs to upgrade a use version of the software a, and after creating a project and submitting the project to a remote Git repository, the developer acquires a source code and repairs part of problems about repair flash back, generates a new source code based on a binary package which is repaired and passes a test, and further submits the source code to the remote Git repository to generate an optimized version of the server.
In the embodiment of the application, the first trunk branch of the current version can be obtained; optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch; testing the binary package to obtain a qualified binary package; determining a second trunk branch based on the binary packet qualified by the test; an optimized version is generated based on the second trunk branch. Therefore, in the embodiment of the application, the optimized trunk branch is converted into the binary package by testing the binary package, so that the tester does not need to test the binary package compiled in different environments, and only needs to be responsible for the binary package generated by the optimized trunk branch version submitted by the developer, thereby improving the quality control capability of the version and also improving the release efficiency of the version.
In some embodiments, fig. 4 illustrates a flowchart of a version management method provided in an embodiment of the present application. As shown in fig. 4, the version management method may include at least the following steps:
s401, a first trunk branch of the current version is obtained.
Specifically, S401 is identical to S301, and is not described herein again.
S402, at least one extension branch is separated from the first trunk branch.
The extension branch is used to indicate a branch that a developer pulls out from the first trunk branch in order to develop a new function or repair an original version of the vulnerability, for example, an extension branch B and an extension branch C that branch out from the first trunk branch a.
S403, optimizing the at least one extension branch, and generating at least one binary packet based on the optimized at least one extension branch.
It is understood that the optimization in the embodiment of the present application is to fix bugs and add new functions, for example, a flash back caused by a developer who prunes to fix the module 1 on the extension branch B, and a flash back caused by a developer who opens to fix the module 2 on the extension branch C.
It can be understood that, in the embodiment of the present application, after optimizing each extension branch, a corresponding binary packet is generated, for example, a binary packet B is generated according to the optimized extension branch B, and a binary packet C is generated according to the optimized extension branch C.
S404, testing at least one binary package to obtain at least one binary package qualified by testing.
Specifically, the embodiment of the present application needs to test the optimized binary packages of each extension branch, mark the binary package that passes the test if the test passes, and return the extension branch corresponding to the binary package that fails the test to the relevant developer to modify until the test passes.
S405, determining a second trunk branch based on at least one binary packet qualified by the test.
Possibly, the embodiment of the present application may determine a corresponding plurality of optimized extension branches according to a plurality of test-qualified binary packets.
Specifically, in the embodiment of the present application, a plurality of optimized extension branches may be generated according to source codes corresponding to a plurality of binary packets that are qualified through testing.
Further, a second trunk branch for generating an optimized version is generated from the plurality of optimized extension branches.
And S406, generating an optimized version based on the second trunk branch.
Specifically, S406 is identical to S305, and is not described herein again.
In a specific example, multiple users in a development team of software a use version control software to perform collaborative development, a group length table, a group member table and a sheetlet, the table creates a project and submits the project to a remote Git warehouse, the sheetlet and the sheetlet acquire source codes of items to be optimized from the remote Git warehouse respectively and are recorded as an extension branch B and an extension branch C respectively, the sheetlet repairs flashover caused by a module 1 on the extension branch B, and the sheetlet repairs flashover caused by a module 2 on the extension branch C, and they submit optimized branches to a tester for testing, and submit the branches to the remote Git warehouse after the testing is passed, the sheetlet acquires the optimized branches from the remote warehouse and then performs combination and generates optimized source codes, and further, an optimized version of a server end is generated according to the optimized source codes.
In some embodiments, before optimizing the first trunk branch and generating the binary packet based on the optimized first trunk branch, the embodiments of the present application may further include: and acquiring at least one preset function to be added. For example, functions to be added in the current version are set at the initial stage of the project, and functions such as newly added member word amount PK, composition correction, recording the learning duration of each week and the like can be preset for the english learning software a to be optimized.
In some embodiments, fig. 5 illustrates a flowchart of a version management method provided in an embodiment of the present application. As shown in fig. 5, the version management method may include at least the following steps:
s501, obtaining a first trunk branch of the current version.
Specifically, S501 is identical to S301, and is not described herein again.
S502, at least one extension branch is branched from the first trunk branch.
Specifically, S502 is identical to S402, and is not described herein again.
S503, adding at least one function to be added to at least one extension branch to generate at least one function branch.
Wherein, the function branch is used to indicate an extension branch for adding new function source code, for example, the developer duel adds a new function on the extension branch B-the automatic correction answer sheet generation function branch B1, and the developer duel adds a new function on the extension branch C-the record learning duration generation function branch C1.
S504, generating a binary package of at least one functional branch.
Specifically, the embodiment of the present application generates its corresponding binary package based on each functional branch, for example, generates binary package B1 based on functional branch B1 to which the automatic batch answer sheet function is added, and generates binary package C1 based on functional branch C1 to which the function of recording the weekly learning duration is added.
And S505, testing the binary system packet of the at least one functional branch to obtain the binary system packet of the at least one functional branch qualified by testing.
Specifically, the embodiment of the present application needs to test the binary packages of the functional branches respectively, and if the test passes, the binary packages passing the test are marked, and the functional branches corresponding to the binary packages failing the test are returned to the relevant developers to be modified until the test passes.
S506, determining a second trunk branch based on the binary package of the at least one functional branch qualified by the test.
Preferably, the embodiment of the present application may determine at least one functional branch qualified for test based on a binary packet of the at least one functional branch qualified for test; a second trunk branch is determined based on the at least one test-eligible functional branch.
Specifically, in the embodiment of the present application, the at least one functional branch that is qualified for test may be generated according to the source code corresponding to the binary packet of the at least one functional branch that is qualified for test.
And S507, generating an optimized version based on the second trunk branch.
Specifically, S507 is identical to S305, and is not described herein again.
In one specific example, a plurality of people in a development team of software A use version control software to perform collaborative development, group leader sheets, the method comprises the steps that a member prune and a table are created, a prune creates a project and submits the project to a remote Git warehouse, the prune and the table respectively acquire a source code of a project to be optimized from the remote Git warehouse and respectively record the source code as an extension branch B and an extension branch C, the prune adds an automatic batch-type answer sheet function on the extension branch B to obtain a function branch B1, the table adds a function of recording the weekly learning duration on the extension branch C to obtain a function branch C1, the function branches are newly developed by the user and submitted to a tester for testing, the test is submitted to the remote Git warehouse after passing, the prune acquires different function branches from the remote warehouse and then combines the function branches to generate a source code of a new version, and further, the optimized version of a server side is generated according to the source code of the new version.
In some embodiments, when generating the second trunk branch based on at least one functional branch that passes the test, the embodiments of the present application may specifically include: and combining at least one functional branch qualified in the test with the first trunk branch to generate a second trunk branch.
It can be understood that the developer has no right to directly Merge the source code of the functional branch that is qualified in the test to the trunk branch, and therefore, the developer needs to initiate a Merge Request (Merge Request), and after the system approval is passed, the developer can Merge with the first trunk branch to generate the second trunk branch.
In a specific example, a plurality of persons in a development team of software A use version control software to cooperatively develop, group long twills, group member twills and small tables, create items of the twills and submit to a remote Git warehouse, the twills and the small tables respectively acquire source codes of items to be optimized from the remote Git warehouse, the twills modify the flash back problem of each module on a first main branch, the twills add an automatic batch modification answer sheet function on an extension branch B to obtain a function branch B1, the small tables add a function of recording the study duration per week on the extension branch C to obtain a function branch C1, the small tables respectively submit their own branches to a tester for testing, the test is submitted to the remote Git warehouse after passing, the small tables acquire the function branches developed by the remote warehouse and the small tables and then merge the function branches with the first main branch which is repaired by themselves to generate new version source codes, further, an optimized version of the server side is generated according to the source code of the new version.
In some embodiments, before generating the optimized version based on the second trunk branch, the embodiments of the present application may further include: the binary package and/or the second trunk branch of at least one functional branch qualified in the test are/is stored, so that problems possibly existing in the use process of a user can be repaired in time after subsequent software is released online, for example, software can be flashed off due to a newly added function, and other sub-functions are expanded in a newly added functional module.
As shown in fig. 6, in a specific embodiment, developers in a development team submit respective developed functional branches to Gitlab (Gitlab is an open source project for a warehouse management system, and is an application service built on the basis of Git serving as a code management tool). Triggering Continuous Integration and Continuous delivery processes, wherein Continuous Integration (CI) is a software development practice, and it is expected that members in a development team frequently submit codes to a code warehouse and each submission can be verified through an automated test, so that problems can be exposed and solved as early as possible. Continuous Delivery (CD) is an extension of Continuous integration, and refers to the deployment of software that passes automated testing into a production environment. The essence of the persistent delivery is to deliver each successfully built application update to the user for use. After the continuous integration process is completed, each functional branch is compiled and packaged to generate binary packages, and further, each binary package can be subjected to product management after information such as a version number, a link, and MD5 (a 128-bit hash value generated according to a cryptographic hash function is uniquely marked on the binary package) and the like corresponding to the binary package are marked. In the continuous delivery process of the products, a series of tests need to be performed on the products, for example, an automatic test and a manual test, a binary package in the products passing the tests will be marked with a mark (tag) to indicate that the corresponding new functions are developed, and when all bugs to be repaired and preset new functions completely pass the tests, the bugs and the preset new functions are merged at one time. And after the combination is finished, the products can be released on line. In addition, the product and each binary package generated by compiling may be saved by using an OSS (Open Storage Service). Specifically, the OSS supports storage services of any data type, supports data upload and download at any time and place, and each storage object in the OSS may be composed of a name, a content, and a description, which greatly facilitates the optimization and upgrade of subsequent versions.
Fig. 7 is a schematic structural diagram of a version management apparatus according to an exemplary embodiment of the present application. The version management apparatus may be installed in a device such as a server, and execute the version management method according to any of the embodiments described above. As shown in fig. 7, the version management apparatus may include:
an obtaining module 71, configured to obtain a first trunk branch of a current version;
a first generation module 72, configured to optimize the first trunk branch, and generate a binary packet based on the optimized first trunk branch;
an obtaining module 73, configured to test the binary packet to obtain a qualified binary packet;
a second generating module 74, configured to determine a second trunk branch based on the test-qualified binary packet;
a third generating module 75 for generating an optimized version based on the second trunk branch.
In the embodiment of the application, the first trunk branch of the current version can be obtained; optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch; testing the binary package to obtain a qualified binary package; determining a second trunk branch based on the binary packet qualified by the test; an optimized version is generated based on the second trunk branch. Therefore, in the embodiment of the application, the optimized trunk branch is converted into the binary package by testing the binary package, so that the tester does not need to test the binary package compiled in different environments, and only needs to be responsible for the binary package generated by the optimized trunk branch version submitted by the developer, thereby improving the quality control capability of the version and also improving the release efficiency of the version.
In some possible embodiments, the first generating module 72 includes;
an extension submodule for branching at least one extension branch from the first trunk branch;
the generation submodule is used for optimizing the at least one extension branch and generating at least one binary packet based on the optimized at least one extension branch;
the obtaining module 73 is specifically configured to: testing the at least one binary package to obtain at least one binary package qualified by the test;
the second generating module 74 is specifically configured to: determining the second trunk branch based on the at least one test-eligible binary packet.
In some possible embodiments, before the first generating module 72, the apparatus further includes: the function acquisition module is used for acquiring at least one preset function to be added.
In some possible embodiments, the generating sub-module includes:
a first generating unit, configured to add the at least one function to be added to the at least one extension branch to generate at least one function branch;
a second generating unit for generating a binary packet of the at least one functional branch;
the obtaining module is specifically configured to: testing the binary package of the at least one functional branch to obtain at least one binary package of the functional branch qualified by the test;
the second generation module is specifically configured to: determining the second trunk branch based on a binary package of the at least one test-eligible functional branch.
In some possible embodiments, the first generating unit is specifically configured to:
a determining subunit for determining at least one test-eligible functional branch based on the binary package of the at least one test-eligible functional branch;
a generating subunit, configured to generate the second trunk branch based on the at least one functional branch that passes the test.
In some embodiments, the generating subunit is specifically configured to: and combining the at least one functional branch qualified in the test with the first trunk branch to generate the second trunk branch.
In some embodiments, before the second generating module 74, the apparatus further comprises: and the storage module is used for storing the binary packet of the at least one functional branch qualified in the test and/or the second trunk branch.
It should be noted that, when the version management apparatus provided in the foregoing embodiment executes the version management method, only the division of the functional modules is illustrated, and in practical applications, the above functions may be distributed by different functional modules according to needs, that is, the internal structure of the device may be divided into different functional modules, so as to complete all or part of the functions described above. In addition, the version management apparatus and the version management method provided in the above embodiments belong to the same concept, and details of implementation processes thereof are referred to as method embodiments, which are not described herein again.
The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.
Please refer to fig. 8, which is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure. As shown in fig. 8, the electronic device 80 may include: at least one processor 81, at least one network interface 84, a user interface 83, a memory 85, at least one communication bus 82.
Wherein a communication bus 82 is used to enable the connection communication between these components.
The user interface 83 may include a Display screen (Display) and a Camera (Camera), and the optional user interface 83 may also include a standard wired interface and a wireless interface.
The network interface 84 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others.
The Memory 85 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). Optionally, the memory 85 includes a non-transitory computer-readable medium. The memory 85 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 85 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-described method embodiments, and the like; the storage data area may store data and the like referred to in the above respective method embodiments. The memory 85 may alternatively be at least one memory device located remotely from the processor 81. As shown in fig. 8, the memory 85, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a version management application program.
In the electronic device 80 shown in fig. 8, the user interface 83 is mainly used as an interface for providing input for a user, and acquiring data input by the user; and the processor 81 may be configured to call the version management application stored in the memory 85 and specifically perform the following operations:
acquiring a first trunk branch of a current version;
optimizing the first trunk branch, and generating a binary system packet based on the optimized first trunk branch;
testing the binary package to obtain a qualified binary package;
determining a second trunk branch based on the test-eligible binary packet;
generating an optimized version based on the second trunk branch.
In the embodiment of the application, the first trunk branch of the current version can be obtained; optimizing the first trunk branch of the current version, and generating a binary system packet based on the optimized first trunk branch; testing the binary package to obtain a qualified binary package; determining a second trunk branch based on the binary packet qualified by the test; an optimized version is generated based on the second trunk branch. Therefore, in the embodiment of the application, the optimized trunk branch is converted into the binary package by testing the binary package, so that the tester does not need to test the binary package compiled in different environments, and only needs to be responsible for the binary package generated by the optimized trunk branch version submitted by the developer, thereby improving the quality control capability of the version and also improving the release efficiency of the version.
In a possible embodiment, the processor 81 specifically executes when performing optimization on the first trunk branch and generating a binary packet based on the optimized first trunk branch;
branching at least one extension branch from the first trunk branch;
optimizing the at least one extension branch, and generating at least one binary packet based on the optimized at least one extension branch;
when the processor 81 executes the test on the binary packet to obtain a binary packet that is qualified in the test, the following steps are specifically executed: testing the at least one binary package to obtain at least one binary package qualified by the test;
when the processor 81 determines the second trunk branch based on the test-qualified binary packet, it specifically performs: determining the second trunk branch based on the at least one test-eligible binary packet.
In a possible embodiment, the processor 81 further performs, before performing optimization on the first trunk branch and generating a binary packet based on the optimized first trunk branch: and acquiring at least one preset function to be added.
In a possible embodiment, when the processor 81 performs optimization on the at least one extended branch and generates at least one binary packet based on the optimized at least one extended branch, specifically performs:
adding the at least one function to be added to the at least one extended branch to generate at least one functional branch;
generating a binary package of the at least one functional branch;
when the processor 81 executes the test on the at least one binary packet to obtain at least one binary packet that is qualified in the test, the following steps are specifically executed: testing the binary package of the at least one functional branch to obtain at least one binary package of the functional branch qualified by the test;
when the processor 81 determines the second trunk branch based on the at least one binary packet that passes the test, it specifically performs: determining the second trunk branch based on a binary package of the at least one test-eligible functional branch.
In a possible embodiment, the processor 81, when executing the binary packet determination of the second trunk branch based on the at least one test-qualified functional branch, specifically executes:
determining at least one test-eligible functional branch based on the binary package of the at least one test-eligible functional branch;
generating the second trunk branch based on the at least one functional branch that passes the test.
In a possible embodiment, when executing the generation of the second trunk branch based on the at least one functional branch that passes the test, the processor 81 specifically executes: and combining the at least one functional branch qualified in the test with the first trunk branch to generate the second trunk branch.
In a possible embodiment, the processor 81, before performing generating the optimized version based on the second trunk branch, further performs: and storing the binary packet of the at least one functional branch qualified by test and/or the second trunk branch.
Embodiments of the present application also provide a computer-readable storage medium, which stores instructions that, when executed on a computer or a processor, cause the computer or the processor to perform one or more of the steps in the embodiments shown in fig. 3 to 5. The respective constituent modules of the version management apparatus described above may be stored in the computer-readable storage medium if they are implemented in the form of software functional units and sold or used as independent products.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in or transmitted over a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)), or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and can include the processes of the embodiments of the methods described above when the program is executed. And the aforementioned storage medium includes: various media capable of storing program codes, such as a Read Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, and an optical disk. The technical features in the present examples and embodiments may be arbitrarily combined without conflict.
The above-described embodiments are merely preferred embodiments of the present application, and are not intended to limit the scope of the present application, and various modifications and improvements made to the technical solutions of the present application by those skilled in the art without departing from the design spirit of the present application should fall within the protection scope defined by the claims of the present application.
Claims (10)
1. A version management method, characterized in that the method comprises:
acquiring a first trunk branch of a current version;
optimizing the first trunk branch, and generating a binary system packet based on the optimized first trunk branch;
testing the binary package to obtain a qualified binary package;
determining a second trunk branch based on the test-eligible binary packet;
generating an optimized version based on the second trunk branch.
2. The method of claim 1, wherein said optimizing the first trunk branch, generating binary packets based on the optimized first trunk branch, comprises;
branching at least one extension branch from the first trunk branch;
optimizing the at least one extension branch, and generating at least one binary packet based on the optimized at least one extension branch;
the step of testing the binary package to obtain a qualified binary package includes: testing the at least one binary package to obtain at least one binary package qualified by the test;
said determining a second trunk branch based on said test-eligible binary packets comprises: determining the second trunk branch based on the at least one test-eligible binary packet.
3. The method of claim 2, wherein before optimizing the first trunk branch, the method further comprises, before generating the binary packet based on the optimized first trunk branch: and acquiring at least one preset function to be added.
4. The method of claim 3, wherein the optimizing the at least one extension branch, and generating at least one binary packet based on the optimized at least one extension branch comprises:
adding the at least one function to be added to the at least one extended branch to generate at least one functional branch;
generating a binary package of the at least one functional branch;
the step of testing the at least one binary packet to obtain at least one binary packet qualified in the test includes: testing the binary package of the at least one functional branch to obtain at least one binary package of the functional branch qualified by the test;
said determining said second trunk branch based on said at least one test-eligible binary packet comprises: determining the second trunk branch based on a binary package of the at least one test-eligible functional branch.
5. The method of claim 4, wherein said determining the second trunk branch based on the binary packet of the at least one test-qualified functional branch comprises:
determining at least one test-eligible functional branch based on the binary package of the at least one test-eligible functional branch;
generating the second trunk branch based on the at least one functional branch that passes the test.
6. The method of claim 5, wherein said generating the second trunk branch based on the at least one test-qualified functional branch comprises: and combining the at least one functional branch qualified in the test with the first trunk branch to generate the second trunk branch.
7. The method of claim 6, wherein prior to generating the optimized version based on the second trunk branch, the method further comprises: and storing the binary packet of the at least one functional branch qualified by test and/or the second trunk branch.
8. A version management apparatus, characterized in that the apparatus comprises:
the acquisition module is used for acquiring a first trunk branch of the current version;
a first generation module, configured to optimize the first trunk branch and generate a binary packet based on the optimized first trunk branch;
the obtaining module is used for testing the binary package to obtain a qualified binary package;
a second generation module, configured to determine a second trunk branch based on the test-qualified binary packet;
and the third generation module is used for generating an optimized version based on the second trunk branch.
9. A computer storage medium, characterized in that it stores a plurality of instructions adapted to be loaded by a processor and to perform the method steps according to any of claims 1-7.
10. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps according to any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011627955.1A CN112667282A (en) | 2020-12-30 | 2020-12-30 | Version management method, related device and computer medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011627955.1A CN112667282A (en) | 2020-12-30 | 2020-12-30 | Version management method, related device and computer medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112667282A true CN112667282A (en) | 2021-04-16 |
Family
ID=75412716
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011627955.1A Pending CN112667282A (en) | 2020-12-30 | 2020-12-30 | Version management method, related device and computer medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112667282A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105302716A (en) * | 2014-07-30 | 2016-02-03 | 腾讯科技（深圳）有限公司 | Method and apparatus for test in joint development mode |
| CN110187914A (en) * | 2019-05-23 | 2019-08-30 | 杭州火小二科技有限公司 | Application and development method, system and device |
| CN111352651A (en) * | 2020-03-31 | 2020-06-30 | 中国建设银行股份有限公司 | Code branch management method and device |
-
2020
- 2020-12-30 CN CN202011627955.1A patent/CN112667282A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105302716A (en) * | 2014-07-30 | 2016-02-03 | 腾讯科技（深圳）有限公司 | Method and apparatus for test in joint development mode |
| CN110187914A (en) * | 2019-05-23 | 2019-08-30 | 杭州火小二科技有限公司 | Application and development method, system and device |
| CN111352651A (en) * | 2020-03-31 | 2020-06-30 | 中国建设银行股份有限公司 | Code branch management method and device |
Non-Patent Citations (1)
| Title |
|---|
| 黑子KUROKO: ""Git分支管理及命名规范"", pages 6 - 7, Retrieved from the Internet <URL:《https://blog.csdn.net/fifteen718/article/details/80347550》> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111414172A (en) | Automatic deployment and release system and method for application software | |
| CN110795088B (en) | Front-end engineering project construction method and tool, and computer-readable storage medium | |
| CN110377462B (en) | Interface testing method and device and terminal equipment | |
| CN113687858B (en) | Configuration file checking method and device, electronic equipment and storage medium | |
| CN111444103A (en) | Automatic testing method for Web page and related equipment | |
| CN112732561A (en) | Project deployment method and device, computer equipment and storage medium | |
| CN112015654A (en) | Method and apparatus for testing | |
| CN111459506B (en) | Deep learning platform cluster deployment method and device, medium and electronic equipment | |
| CN113778391A (en) | Page processing method, device and equipment for native application program | |
| CN115469833A (en) | Method and device for implementing dynamic rule engine, electronic equipment and storage medium | |
| CN111767209A (en) | Code testing method, device, storage medium and terminal | |
| CN109032612B (en) | Interface calling method and device of hybrid application and computer readable storage medium | |
| US20200285568A1 (en) | Devices and methods for generating a stream of health-related data | |
| CN108920379B (en) | Method and device for capturing lua code exception | |
| CN112988588B (en) | Client software debugging method and device, storage medium and electronic equipment | |
| CN109032693B (en) | Method and device for loading display information, electronic equipment and readable storage medium | |
| CN113778897A (en) | Automatic test method, device, equipment and storage medium of interface | |
| CN117311782A (en) | Dynamic system branch pulling method and device, server and storage medium | |
| CN110362294A (en) | Development task executes method, apparatus, electronic equipment and storage medium | |
| CN112667282A (en) | Version management method, related device and computer medium | |
| CN114895916A (en) | Code deployment method, device, storage medium and electronic equipment | |
| CN114356346A (en) | Application program deployment method, device, storage medium and electronic equipment | |
| CN114741296A (en) | Unit testing method, unit testing device, electronic equipment and storage medium | |
| CN113312900A (en) | Data verification method and device | |
| US20200349304A1 (en) | Method, apparatus, device, and medium for implementing simulator |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |