Continuous integration and continuous delivery method, device, electronic device and storage medium
By automatically creating and merging codes and dynamically managing the development and testing environment, the problems of low efficiency and frequent errors in the existing technology are solved, and efficient continuous integration and continuous delivery are achieved.
Patent Information
- Application Number
- CN202011408167.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-12-03
- Publication Date
- 2024-12-17
- Estimated Expiration
- 2040-12-03
AI Technical Summary
In the prior art, software research and development requires manual creation and initialization of development and testing environments, resulting in low efficiency and error proneness, and difficulty in cross-department collaboration, affecting the efficiency of continuous integration and continuous delivery.
By obtaining development code, automatically creating a test environment, and combining development code and test code in the test environment to determine the code to be released, dynamically produce and destroy the environment, avoid manually creating tasks, and achieve automated configuration and deployment.
Improve the efficiency of continuous integration and continuous delivery, ensure the quality of release packages, avoid manual errors, simplify cross-departmental collaboration, and shorten the application time for testing environments.
Smart Images

Figure CN112506525B_ABST
Abstract
Description
Technical Field
[0001] One or more embodiments of the present application relate to the field of computer software development technology, and in particular, to a continuous integration and continuous delivery method, device, electronic device and storage medium. Background Art
[0002] In the prior art, before software development, it is necessary to apply for a development and testing environment from the data center. After obtaining the environment, it is necessary to initialize the environment. During the development and testing process, Jenkins tasks for building and deploying are manually created. After software development is completed, programs, scripts, documents, etc. are manually made into version release packages and delivered to the deployment team in the data center. However, the development and testing environment needs to be applied for across departments, which is inefficient, and needs to be manually created and initialized, which makes software development prone to errors. Summary of the invention
[0003] In view of this, the purpose of one or more embodiments of the present application is to propose a continuous integration and continuous delivery method, device, electronic device and storage medium to solve at least one of the above-mentioned problems existing in the prior art.
[0004] Based on the above objectives, one or more embodiments of the present application provide a continuous integration and continuous delivery method, including:
[0005] Get the development code;
[0006] Pushing the development code to a test environment to obtain a test code;
[0007] Merging the development code and the test code to determine a code to be released;
[0008] Release a release package built according to the code to be released.
[0009] Optionally, the test environment includes: a build application and a test application; the build application is used to automatically generate build tasks; and the test application is used to test the test code.
[0010] Optionally, the pushing of the development code to a test environment to obtain a test code may also include:
[0011] building a development application based on the development code;
[0012] Determining whether the developed application can run normally;
[0013] If not, a build log is obtained according to the development application, and the development code is updated according to the build log.
[0014] Optionally, the step of pushing the development code to a test environment to obtain a test code further includes:
[0015] Building the application to be tested according to the building task and the test code;
[0016] The application to be tested is tested using the test application.
[0017] Optionally, the publishing of a release package constructed according to the code to be published further includes:
[0018] Determine whether the application to be tested is deployed in the container cloud;
[0019] If so, a container image is built according to the application to be tested, and the container image is pushed to a pre-built image repository.
[0020] Optionally, the publishing a release package constructed according to the code to be published further includes:
[0021] Destroy the test environment and the build task.
[0022] Optionally, the merging the development code and the test code to determine the code to be released specifically includes:
[0023] Automatically comparing the development code and the test code to see if there are any differences;
[0024] If not, the development code and the test code are merged to determine the code to be released.
[0025] Based on the same inventive concept, one or more embodiments of the present application further propose a continuous integration and continuous delivery device, including:
[0026] an acquisition module, configured to acquire development code;
[0027] A push module, configured to push the development code to a test environment to obtain a test code;
[0028] A merging module, configured to merge the development code and the test code to determine a code to be released;
[0029] The publishing module is configured to publish a publishing package built according to the code to be published.
[0030] Based on the same inventive concept, one or more embodiments in the present application also propose an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the continuous integration and continuous delivery method described in any one of the above items is implemented.
[0031] Based on the same inventive concept, one or more embodiments in the present application also propose a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute any one of the continuous integration and continuous delivery methods described above.
[0032] From the above, it can be seen that a continuous integration and continuous delivery method provided by one or more embodiments of the present application includes: obtaining development code; pushing the development code to a test environment to obtain test code; merging the development code and the test code to determine the code to be released; and releasing a release package built according to the code to be released. The method provided in the present application can dynamically produce and destroy development and testing environments, avoid cross-departmental collaboration, and improve the efficiency of continuous integration and continuous delivery. Test code, code to be released, and release packages do not need to be created manually, and can be automatically configured, which improves the efficiency of creation and deployment, ensures the quality of release packages in continuous delivery, and avoids the problem of errors that are easily caused by manual creation of tasks or codes. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] In order to more clearly illustrate one or more embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only one or more embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0034] Figure 1 A flowchart of a continuous integration and continuous delivery method in one or more embodiments of the present application;
[0035] Figure 2 A schematic diagram of the structure of a continuous integration and continuous delivery device in one or more embodiments of the present application;
[0036] Figure 3 It is a schematic diagram of the structure of an electronic device in one or more embodiments of the present application. DETAILED DESCRIPTION
[0037] In order to make the objectives, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.
[0038] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in one or more embodiments of the present application should be understood by people with ordinary skills in the field to which the present disclosure belongs. The "first", "second" and similar words used in one or more embodiments of the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "include" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.
[0039] The applicant found through research that in the prior art, with the development of the company's business, the tasks of software development have increased year by year. In the process of software development, a development and test environment is required. After obtaining the test environment, the test environment needs to be initialized; in the process of software development and testing, manually creating build and deploy Jenkins tasks requires continuous integration and continuous deployment; after the software development is completed, the program, script, document, etc. are made into a version release package and delivered to the deployment team of the data center. Because the development and testing environment requires cross-departmental application, the efficiency is low, and because it needs to be manually initialized after obtaining the environment, it is prone to errors and takes a lot of time; when creating a build and deployment task, there are a large number of parameters that need to be adjusted, which is difficult. As the number of environments and Jenkins tasks increases, it will become more difficult to maintain. For this reason, the continuous integration and continuous delivery method provided by this application automatically creates a test environment after obtaining the development code, and obtains the test code in the test environment. The code to be released is determined by merging the development code and the test code, and a release package containing database scripts, configuration scripts, documents and the code to be released is built according to the code to be released. According to the delivery specification, it is placed in the corresponding directory to complete the packaging and released to complete the delivery.
[0040] refer to Figure 1 Therefore, one or more embodiments of the present application provide a continuous integration and continuous delivery method, which specifically includes the following steps:
[0041] S101: Get the development code.
[0042] In this embodiment, it is necessary to obtain the development code to be developed written by the developer. For example, the development code can be the code written by the developer, and after the developer writes the code, the code written by the developer is directly obtained as the development code. In some optional implementations, after the software developer completes the writing of the code, the code can be uniformly sent to the receiving server, and the development code can be directly obtained through the receiving server.
[0043] It is understandable that when the development code needs to be stored in a research and development code database with a higher security level, the database administrator's information, such as the administrator ID, can be obtained first, the research and development code database can be accessed through the administrator information, and then the development code can be obtained from it.
[0044] In some optional implementations, after receiving a research and development task, the user develops a version plan and determines the version number. The user selects an application and enters the version number. Then, based on the user's selection, a corresponding code branch is automatically created in the code repository, and the code branch is named according to a unified specification. The version number in the code file on the code branch is then modified and automatically changed to the version number of this research and development.
[0045] S102: Push the development code to a test environment to obtain a test code.
[0046] In this embodiment, the development code is pushed to a pre-built test environment to obtain the test code. It should be explained that with the complexity and micro-service of applications, a single application is often difficult to complete a business, so users can choose to deploy multiple applications to the same test environment. Some of these applications are developed according to the needs of this task, and some do not need to be developed but are indispensable support programs for completing business functions.
[0047] In some optional implementations, after the test environment is built, at least the following two applications are included in the test environment: a build application and a test application; the build application is obtained by obtaining the configuration of the build application from a database, and automatically generating Jenkins tasks for building and deploying. Jenkins is an open source continuous integration and continuous deployment software, and the build application is used to automatically generate build tasks; the test application is obtained by directly obtaining historical archived application images and deploying them in a development and test environment, and the test application is used to test the test code in the test environment.
[0048] It is understandable that after the deployment of the R&D test environment is completed, the user can view the test environment information, including the IP addresses of each application, and the success or failure of the test environment construction. After the test environment is created, if it is found that the parameters selected during creation are incorrect, the test environment can be modified, including but not limited to adding, modifying and deleting applications in the test environment, adjusting the version of the application, and modifying the test environment will modify the build tasks generated before building the application. If the test environment fails to build, the cause of the build failure can be found based on the test environment information, and the test environment can be rebuilt based on the test environment information.
[0049] It should be noted that before pushing the development code to the test environment to obtain the test code, it is necessary to build a development application based on the development code and update it in the test environment, and then judge the development application to determine whether it can run normally; if the development application can run normally, the development application is built successfully and you can continue to execute subsequent steps; if the development application cannot run normally, obtain the build log based on the development application, update the development code based on the build log, and the user can jump to the Jenkins interface to view the build log, analyze the reasons for the failure of the development application build, and update the development code used to build the development application.
[0050] In some optional implementations, after the user completes the development of the development application, the user pushes the development code from the development branch to the test branch in the test environment. After the development code of the development branch is pushed to the test branch, according to the production deployment, after the development code is pushed to the test environment and the test code has been obtained, the application to be tested is built according to the build task and the test code, and the application is tested using the test application. Specifically, according to the production deployment, some applications to be tested are deployed on the container cloud, and some are deployed on virtual machines. According to the virtual machine address entered by the user and the configuration information of the application in the database, a Jenkins task for the push environment is automatically created and executed, and the test code in the test branch is built as the application to be tested, and it is deployed to the test environment. After that, the tester can use the test application in the test environment to test the results of this development, that is, the application to be tested.
[0051] S103: Merge the development code and the test code to determine a code to be released.
[0052] In this embodiment, the development code and the test code are merged to determine the code to be released. Specifically, after the application to be tested passes the test, a release instruction can be submitted. In the process of submitting the release instruction, the development code and the test code need to be merged, and the difference between the development code of the development branch and the test code of the test branch needs to be automatically compared to ensure that all the development codes in the development branch have been tested. Determine whether there are differences between the development code and the test code. If there are differences, update the development code again; if there are no differences, merge the development code and the test code, and merge the development branch and the test branch into the trunk branch, so that the code to be released in the trunk branch is consistent with the application running in the production environment.
[0053] It should be noted that whether the development code and the test code need to be merged to determine the code to be released can be determined in response to the user's confirmation operation. For example, if the development code is more than the test code, then in response to the user's instruction to confirm that the excess code needs to be released, the development code and the test code are merged to determine the code to be released. If the excess code is submitted in error, then in response to the user's instruction to confirm that the excess code does not need to be released, the development code and the test code are not merged.
[0054] S104: publishing a publishing package constructed according to the code to be published.
[0055] In this embodiment, a release package is built according to the code to be released, and the release package is released to complete the task of continuous delivery. Specifically, a release baseline of the code to be released will be created in the code repository, and an application creation task will be built to build a release application for release. At the same time, database scripts and configuration scripts are downloaded, placed in the corresponding directory according to the delivery specifications, and packaged to obtain a release package.
[0056] In some optional implementations, before releasing a release package built based on the code to be released, it is necessary to determine whether the application to be tested is deployed in the container cloud. If not, it is directly packaged through step S104 to obtain a release package; if so, it is necessary to create a task of building a container image using the build application while creating the release package, and push the container image to a pre-built image repository. The container image in the image repository can be used in the next continuous integration and continuous delivery task, such as selecting a test application in a test environment from the image repository.
[0057] In some optional implementations, after the R&D task is completed, that is, after the release package built according to the code to be released is released, the development and test environment created this time will be completely destroyed, and the build task created in the test environment will also be deleted, and the resources used to build the test environment and the build task will be recycled for use in subsequent R&D tasks. The destruction operation can also be timed according to the project scale, and the test environment and the build task will be destroyed at a preset time after the R&D task is completed.
[0058] As can be seen from the above, a continuous integration and continuous delivery method provided by one or more embodiments of the present application includes: obtaining development code; pushing the development code to a test environment to obtain test code; merging the development code and the test code to determine the code to be released; and releasing a release package built according to the code to be released. The method provided by the present application can dynamically produce and destroy the development and test environment, avoid cross-departmental collaboration, and improve the efficiency of continuous integration and continuous delivery. Test code, code to be released, and release packages do not need to be created manually, and can be automatically configured, which improves the efficiency of creating deployment, ensures the quality of release packages in continuous delivery, and avoids the problem of errors caused by manually creating tasks or codes. Moreover, most of the information of the environment is automatically configured, and only a small part requires user selection and entry, which greatly improves the efficiency of creating deployment. The application and deployment of the test environment that originally required several weeks can be completed in just a few minutes. Moreover, in the process of software code development, the required Jenkins tasks for continuous integration are uniformly generated according to the template, which ensures the quality of continuous integration, improves efficiency, and avoids problems such as incomplete changes and changes caused by manual changes of various parameters by users each time. The resulting release package is automatically generated using a program according to the delivery specifications, ensuring the quality of the release package while improving efficiency.
[0059] The above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0060] Based on the same inventive concept, one or more embodiments of the present application also propose a continuous integration and continuous delivery device, referring to Figure 2 , the continuous integration and continuous delivery apparatus comprises:
[0061] an acquisition module, configured to acquire development code;
[0062] A push module, configured to push the development code to a test environment to obtain a test code;
[0063] A merging module, configured to merge the development code and the test code to determine a code to be released;
[0064] The publishing module is configured to publish a publishing package built according to the code to be published.
[0065] In some optional implementations, the test environment includes: a build application and a test application; the build application is used to automatically generate build tasks; and the test application is used to test the test code.
[0066] In some optional implementations, the pushing of the development code to the test environment to obtain the test code also includes:
[0067] building a development application based on the development code;
[0068] Determining whether the developed application can run normally;
[0069] If not, a build log is obtained according to the development application, and the development code is updated according to the build log.
[0070] In some optional implementations, the pushing of the development code to a test environment to obtain a test code further includes:
[0071] Building the application to be tested according to the building task and the test code;
[0072] The application to be tested is tested using the test application.
[0073] In some optional implementations, the step of publishing a release package constructed according to the code to be released further includes:
[0074] Determine whether the application to be tested is deployed in the container cloud;
[0075] If so, a container image is built according to the application to be tested, and the container image is pushed to a pre-built image repository.
[0076] In some optional implementations, the publishing a publishing package constructed according to the to-be-published code further includes:
[0077] Destroy the test environment and the build task.
[0078] In some optional implementations, the merging the development code and the test code to determine the code to be released specifically includes:
[0079] Automatically comparing the development code and the test code to see if there are any differences;
[0080] If not, the development code and the test code are merged to determine the code to be released.
[0081] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more embodiments of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware.
[0082] The apparatus of the above-mentioned embodiment is used to implement the corresponding method in the above-mentioned embodiment, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.
[0083] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, one or more embodiments of this specification also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the continuous integration and continuous delivery method described in any of the above embodiments is implemented.
[0084] Figure 3 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 310, a memory 320, an input / output interface 330, a communication interface 340, and a bus 350. The processor 310, the memory 320, the input / output interface 330, and the communication interface 340 are connected to each other in communication within the device through the bus 350.
[0085] The processor 310 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.
[0086] The memory 320 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 320 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 320 and are called and executed by the processor 310.
[0087] The input / output interface 330 is used to connect the input / output module to realize information input and output. The input / output module can be configured as a component in the device (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.
[0088] The communication interface 340 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).
[0089] The bus 350 comprises a pathway that transmits information between the various components of the device (eg, the processor 310 , the memory 320 , the input / output interface 330 , and the communication interface 340 ).
[0090] It should be noted that, although the above device only shows the processor 310, the memory 320, the input / output interface 330, the communication interface 340 and the bus 350, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.
[0091] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, one or more embodiments of the present specification also provide a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the continuous integration and continuous delivery method described in any of the above embodiments.
[0092] The non-transitory computer-readable storage media of this embodiment include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.
[0093] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the continuous integration and continuous delivery method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.
[0094] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present disclosure (including the claims) is limited to these examples. Based on the concept of the present disclosure, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.
[0095] One or more embodiments in this application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments in this application should be included in the scope of protection of this disclosure.
Claims
1. A continuous integration and continuous delivery method, characterized in that: include: Get the development code; Pushing the development code to a test environment to obtain a test code; Merging the development code and the test code to determine a code to be released; Release a release package built according to the code to be released; The test environment includes: a build application and a test application; the build application is used to automatically generate a build task; the test application is used to test the test code; wherein the test application is obtained by obtaining a historical archived application image and deploying the application image in the test environment, and the build application is obtained by obtaining the configuration of the build application from a database and automatically generating a Jenkins task for building and deploying.
2. The continuous integration and continuous delivery method according to claim 1, characterized in that: The pushing of the development code to the test environment to obtain the test code also includes: building a development application based on the development code; Determining whether the developed application can run normally; If not, a build log is obtained according to the development application, and the development code is updated according to the build log.
3. The continuous integration and continuous delivery method according to claim 1, characterized in that: The step of pushing the development code to the test environment to obtain the test code further includes: Building the application to be tested according to the building task and the test code; The application to be tested is tested using the test application.
4. The continuous integration and continuous delivery method according to claim 3, characterized in that: The publishing package constructed according to the to-be-published code may also include: Determine whether the application to be tested is deployed in the container cloud; If so, a container image is built according to the application to be tested, and the container image is pushed to a pre-built image repository.
5. The continuous integration and continuous delivery method according to claim 1, characterized in that: The publishing package constructed according to the code to be published further includes: Destroy the test environment and the build task.
6. The continuous integration and continuous delivery method according to claim 5, characterized in that: The merging of the development code and the test code to determine the code to be released specifically includes: Automatically comparing the development code and the test code to see if there are any differences; If not, the development code and the test code are merged to determine the code to be released.
7. A continuous integration and continuous delivery device, characterized in that: include: an acquisition module, configured to acquire development code; A push module, configured to push the development code to a test environment to obtain a test code; A merging module, configured to merge the development code and the test code to determine a code to be released; A publishing module, configured to publish a publishing package built according to the code to be published; The test environment includes: a build application and a test application; the build application is used to automatically generate a build task; the test application is used to test the test code; wherein the test application is obtained by obtaining a historical archived application image and deploying the application image in the test environment, and the build application is obtained by obtaining the configuration of the build application from a database and automatically generating a Jenkins task for building and deploying.
8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 6 is implemented.
9. A non-transitory computer-readable storage medium, characterized in that: The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to cause the computer to execute any one of claims 1 to 6.
