A blockchain system continuous delivery method and device based on GitOps

Abstract

The embodiment of this specification discloses a method and device for continuous delivery of a blockchain system based on GitOps, wherein the method initializes the blockchain configuration in a declarative manner, and the blockchain configuration includes at least a chain-level configuration and a node configuration; submits the chain-level configuration to a first Git repository and the node configuration to a second Git repository; when updating the blockchain configuration, it includes: pulling the latest chain-level configuration from the first Git repository, updating the chain-level configuration, and submitting the updated chain-level configuration to the first Git repository; sensing the chain-level configuration change in the first Git repository, pulling the chain-level configuration from the first Git repository, updating the local node configuration, and submitting the node configuration to the second Git repository; sensing the node configuration change in the second Git repository, pulling the node configuration from the second Git repository, and updating the local blockchain application system operating environment. The present invention performs continuous delivery through GitOps, uses the Git repository to manage configuration updates, and improves the efficiency of automatically delivering changes to the blockchain application system operating environment.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, and in particular to a method, device, electronic device and storage medium for continuous delivery of a blockchain system based on GitOps. Background Art

[0002] Blockchain configuration involves multiple participants in the blockchain. Due to the decentralized nature of the blockchain, each node and its participants will generate a large amount of information interaction during the operation of the blockchain, and will also involve corresponding modifications to the blockchain configuration. Blockchain configuration management is a scenario of multi-party collaboration. Using Git to manage blockchain configuration information can effectively solve the problems of information transmission, synchronization, and authentication in the process of multiple participants collaborating to generate blockchain configuration information. However, this solution only generates or updates the configuration files of each node in the blockchain system. As for the deployment of nodes or the configuration upgrade of nodes after new participants join, manual work is still required. Due to the multi-party collaboration characteristics of the blockchain system, participants may continue to join and exit after the online operation, resulting in constant changes in the configuration of nodes. Manual configuration upgrades are prone to errors and take a long time. If the node configuration update deployment cannot be completed in time when the configuration changes, the node configuration will be outdated or wrong, which may cause security risks to the entire blockchain system. Summary of the invention

[0003] The purpose of the embodiments of this specification is to provide a GitOps-based blockchain system continuous delivery method, device, electronic device and storage medium to address the above problems.

[0004] To solve the above technical problems, the embodiments of this specification are implemented as follows:

[0005] In the first aspect, a continuous delivery method for a blockchain system based on GitOps is proposed, which initializes a blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration; submits the chain-level configuration to a first Git repository and the node configuration to a second Git repository; when a first participant updates the blockchain configuration, it includes:

[0006] The first participant pulls the latest chain-level configuration from the first Git repository, updates the chain-level configuration, and submits the updated chain-level configuration to the first Git repository;

[0007] The second participant perceives the change of the chain-level configuration in the first Git repository, pulls the updated chain-level configuration from the first Git repository, updates the local node configuration, and submits the updated node configuration to the second Git repository;

[0008] The application deployment system senses the change of the node configuration in the second Git repository, pulls the updated node configuration from the second Git repository, and updates the corresponding operating environment of the local blockchain application.

[0009] Secondly, a continuous delivery device for a blockchain system based on GitOps is proposed, including:

[0010] A blockchain configuration initialization module, used to initialize the blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration;

[0011] A blockchain configuration sub-warehouse management module, used to submit the chain-level configuration to the first Git warehouse and the node configuration to the second Git warehouse;

[0012] A chain-level configuration update module, configured to pull the latest chain-level configuration from the first Git repository, update the chain-level configuration, and submit the updated chain-level configuration to the first Git repository when the first participant updates the blockchain configuration;

[0013] A node configuration update module, used for the second participant to perceive the change of the chain-level configuration in the first Git repository, pull the updated chain-level configuration from the first Git repository, update the local node configuration, and submit the updated node configuration to the second Git repository;

[0014] The blockchain application system operating environment update module is used for the application deployment system to perceive the changes in the node configuration in the second Git repository, pull the updated node configuration from the second Git repository, and update the corresponding operating environment of the local blockchain application.

[0015] In a third aspect, an electronic device is provided, comprising: a processor; and

[0016] A memory arranged to store computer executable instructions which, when executed, cause the processor to perform the method of the first aspect.

[0017] In a fourth aspect, a computer-readable storage medium is proposed, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including multiple application programs, the electronic device executes the method described in the first aspect.

[0018] This specification can achieve at least the following technical effects:

[0019] The present invention uses GitOps to achieve continuous delivery of blockchain systems. By initializing the blockchain system configuration in a declarative manner, the problem of inconsistent configuration caused by the traditional way of transmitting configuration change actions is avoided; the separate storage of chain-level and node configurations ensures the traceability and auditability of configuration changes and the security of private configuration information; it automatically realizes the process from configuration change to the final update of the actual operating environment configuration, thereby improving the efficiency of blockchain system configuration changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of this specification 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 some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0021] Figure 1 This is one of the schematic diagrams of the continuous delivery method of the blockchain system based on GitOps provided in the embodiments of this specification.

[0022] Figure 2 The second schematic diagram of the continuous delivery method of the blockchain system based on GitOps provided in the embodiment of this specification.

[0023] Figure 3 The third schematic diagram of the continuous delivery method of the blockchain system based on GitOps provided in the embodiment of this specification.

[0024] Figure 4 The fourth schematic diagram of the continuous delivery method of the blockchain system based on GitOps provided in the embodiment of this specification.

[0025] Figure 5 Schematic diagram of the continuous delivery method of the blockchain system based on GitOps provided in the embodiment of this specification.

[0026] Figure 6 This is one of the schematic diagrams of a continuous delivery device for a blockchain system based on GitOps provided in an embodiment of this specification.

[0027] Figure 7 The second schematic diagram of the continuous delivery device of the blockchain system based on GitOps provided in the embodiment of this specification.

[0028] Figure 8 A schematic diagram of the structure of an electronic device provided for one embodiment of the present specification. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0030] The following is a detailed description of a GitOps-based blockchain system continuous delivery solution involved in this specification through a specific example.

[0031] Key Terms

[0032] Git: is an open source distributed version control system that can effectively and quickly handle version management of projects from very small to very large. The biggest difference between distributed and centralized systems is that developers can submit to local, and each developer can copy a complete Git repository on the local machine by cloning (git clone). GitHub is a website for developers to open source their own code, and also provides paid functions for private repositories, and the version control software it uses is Git. Similarly, GitLab is an open source project for warehouse management systems, using Git as a code management tool and a web service built on this basis. The basic Git workflow is: modify files in the workspace; selectively stage the changes you want to submit next time, so that only the changed parts are added to the staging area; submit updates, find the files in the staging area, and permanently store the snapshot in the Git directory. If a specific version of the file is saved in the Git directory, it is in the submitted state. If the file has been modified and put into the staging area, it is in the staged state. If changes have been made since the last checkout but have not been put into the staging area, it is in the modified state.

[0033] GitOps: A development and operations practice that uses Git to manage infrastructure and application configuration. It is a fast and secure method for developers or operations personnel to maintain and update complex applications running in Kubernetes or other declarative orchestration frameworks. There are four principles for its use: (1) Describe the entire system in a declarative way, that is, you only need to declare the target state that the system wants to achieve, and the tool will drive the system to approach the target state. The declaration means that the system state is guaranteed by a set of facts rather than a set of instructions, which is convenient for maintenance. After the declaration information is stored in Git, the system state has a unique source of truth, and applications can be easily deployed and rolled back. When a disaster occurs, the cluster infrastructure can also be reliably and quickly reproduced. (2) The target state of the system is versioned through Git, that is, by storing the target state of the system in a system with version control capabilities and using it as the only source of truth, everything can be derived and driven from it. Change requests for the target state are initiated through PR, and the state changes are clearly presented. (3) Changes to the target state will be automatically applied to the system after approval. That is, once the declared state is saved in Git, any changes to the state can be automatically applied to the system, which can greatly improve the speed of product delivery. GitOps uses a pull mode to update the system state, separating what to do from how to do it, which can more effectively divide the security boundaries of the system. (4) Drive convergence and report deviations. That is, GitOps contains an operational feedback and control loop that will continuously compare the actual state of the system with the target state in Git. If the state has not converged within the expected time, an alarm will be triggered and the difference will be reported. This loop enables the system to have self-healing capabilities.

[0034] Continuous integration (CI) is the process of integrating code into the main trunk. Each integration is verified through automated building, including compilation, release, and automated testing, so as to find integration errors as soon as possible. Continuous integration emphasizes that after developers submit new code, they should immediately build and (unit) test it. Based on the test results, it can be determined whether the new code and the original code can be correctly integrated together. Its benefits are: (1) Quickly discover errors. Every time an update is completed, it is integrated into the main trunk, so errors can be discovered quickly and located more easily. (2) Prevent branches from deviating significantly from the main trunk. If integration is not done frequently and the main trunk is constantly updated, it will make future integration more difficult or even impossible.

[0035] Continuous Delivery (CD): The goal of continuous delivery is to produce software in a short cycle and ensure that the software can be reliably released at any time. The goal is to continuously produce software that can be reliably released. Continuous delivery depends on continuous integration. During the continuous integration process, an integrated system that has passed all test cases and can be correctly released can be regarded as the result of continuous delivery. The meaning of continuous delivery is very similar to DevOps.

[0036] Embodiment 1

[0037] Reference Figure 1 As shown in FIG, a schematic diagram of a continuous delivery method of a blockchain system based on GitOps according to an embodiment of the present invention is shown. Figure 1 As shown in the figure, when Git is used for blockchain system configuration management, the blockchain system configuration parameters are stored in the Git repository. When a blockchain participant proposes to modify the configuration parameters, the original blockchain configuration file needs to be pulled out from the Git repository and saved as a copy to the local blockchain participant. After the participant updates the configuration file and submits the new configuration file to the Git repository, other blockchain participants pull the updated configuration and send it to the corresponding blockchain node.

[0038] Embodiments of the present invention Figure 2 The schematic diagram shown in the figure further details the working process of the continuous delivery method of the blockchain system based on GitOps. Based on the Git repository, GitOps is used as a continuous delivery method. Its core idea is to store the configuration and deployment of the application system in the Git repository in a declarative way. Then, Git is used as the core of the delivery pipeline. Developers only need to submit modifications to the Git repository and use Git to accelerate and simplify application deployment and operation and maintenance tasks. Through GitOps, when Git is used to submit configuration changes to the application system, the automated delivery pipeline will apply these changes to the actual system. This fully utilizes the many advantages of GitOps in the continuous delivery pipeline: (1) Automatically ensure that the configuration of the actual application system is consistent with that in the Git repository; (2) Faster deployment time and recovery time; (3) Stable and reproducible rollback. Git stores historical configuration information, and can switch back to the historical version at any time if there is a problem. At the same time, considering the decentralized nature of blockchain, the chain-level configuration of blockchain needs to be public, at least among the participants of the blockchain, so that multiple participants can modify the chain-level configuration. However, there is a lot of private information in the node configuration, and publicizing it will cause security risks. Therefore, it is necessary to further optimize the Git repository setting plan. Figure 3 The figure shows a continuous delivery method of a blockchain system based on GitOps of the present invention, comprising:

[0039] Step 301: Initialize the blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least chain-level configuration and node configuration.

[0040] Optionally, the declaratively initializing the blockchain configuration includes initializing a corresponding data structure according to the blockchain configuration, wherein the data structure includes at least a data structure corresponding to the chain level configuration and a data structure corresponding to the node configuration. Figure 4 As shown in the figure, it is the corresponding blockchain configuration data structure in a declarative manner. Among them, the data structure of the chain-level configuration corresponds to the chain-level configuration elements disclosed by the blockchain one by one; the data structure of the node configuration corresponds to the configuration elements such as the Baokuou microservice port, listening port, certificate, log level, kms password, etc.

[0041] Step 302: Submit the chain configuration to the first Git repository and the node configuration to the second Git repository.

[0042] Optionally, the first Git repository is used to store public configuration information, and the second Git repository is used to store private configuration information. Chain-level configuration information only contains information that can be made public, such as account addresses, etc., which can be placed in the first Git repository; while private information such as private keys are stored in the node configuration and placed in the second Git repository owned by the participating parties.

[0043] Step 303: When the first participant updates the blockchain configuration, the first participant pulls the latest chain-level configuration from the first Git repository, updates the chain-level configuration, and submits the updated chain-level configuration to the first Git repository.

[0044] Optionally, the first participant submits the updated chain-level configuration to the first Git repository, including: initiating a review of the updated chain-level configuration, and merging it into the first Git repository main branch after the blockchain participant reviews the chain-level configuration modification. The review described here can utilize the PR method. PR can be considered as a distributed code review and merge tool, and is one of the most commonly used tools for git. Taking GitHub as an example, the basic operations of PR include: for project developers, first Fork the project and turn it into a project under the project developer's GitHub; then clone the project to the local using the command line and create a new branch; associate the remote repository; after modifying the project, submit the changes to the project that the remote project developer has just forked; submit the changes in the project developer's forked project to the main developer's project through PR to complete PR.

[0045] Step 304: The second participant perceives the change of the chain-level configuration in the first Git repository, pulls the updated chain-level configuration from the first Git repository, updates the local node configuration, and submits the updated node configuration to the second Git repository.

[0046] Optionally, the second participant perceives the change of the chain-level configuration in the first Git repository by using a publish-subscribe method, including a WebHook method. Webhook is very similar to the publish / subscribe model in asynchronous programming, where one end triggers an event and the other end listens for execution. The principle is a URL that receives http post (or get, put, delete). An API that implements Webhook sends a message to the configured URL when an event occurs. Unlike the request-response method, using Webhook can receive changes in real time.

[0047] Step 305: The application deployment system senses the change of the node configuration in the second Git repository, pulls the updated node configuration from the second Git repository, and updates the corresponding operating environment of the local blockchain application.

[0048] Taking the addition of a node to a blockchain system as an example, the following is a specific embodiment: the new blockchain participant first applies for access rights to the public Git repository that stores chain-level configuration information, namely the first Git repository; pulls the current latest chain-level configuration to the local as a copy, and then submits the configuration information of the added blockchain node to the copy of the chain-level configuration file, and then submits the updated chain-level configuration in PR mode; when the added node information is approved by the PR review, it is merged into the trunk of the first Git repository configuration; the existing nodes of the blockchain perceive the changes in the first Git repository storing the chain-level configuration through the Webhook method, pull the latest chain-level configuration, and then update the local node configuration file through the local configuration tool, that is, access the second Git repository, and submit it to the second Git repository storing the node configuration; the application deployment system also perceives the changes in the second Git repository storing the node configuration through the Webhook method, stops the existing node application, pulls the latest node configuration, restarts the node application, and completes the entire configuration change.

[0049] like Figure 5 As shown, in another embodiment, a continuous delivery method for a blockchain system based on GitOps is provided, further comprising:

[0050] Step 306: When an exception occurs when updating the operating environment of the local blockchain application, the historical configurations in the first Git repository and the second Git repository are respectively called to restore the operating environment of the local blockchain application.

[0051] Embodiment 2

[0052] Figure 6 This is a schematic diagram of a continuous delivery device 600 for a blockchain system based on GitOps provided by an embodiment of this specification. Figure 6In one embodiment, a continuous delivery device for a blockchain system based on GitOps includes:

[0053] A blockchain configuration initialization module 601 is used to initialize the blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration;

[0054] The blockchain configuration sub-warehouse management module 602 is used to submit the chain-level configuration to the first Git warehouse and the node configuration to the second Git warehouse;

[0055] A chain-level configuration update module 603 is used to pull the latest chain-level configuration from the first Git repository, update the chain-level configuration, and submit the updated chain-level configuration to the first Git repository when the first participant updates the blockchain configuration;

[0056] A node configuration update module 604 is used for the second participant to perceive the change of the chain-level configuration in the first Git repository, pull the updated chain-level configuration from the first Git repository, update the local node configuration, and submit the updated node configuration to the second Git repository;

[0057] The blockchain application system operating environment update module 605 is used for the application deployment system to perceive the changes in the node configuration in the second Git repository, pull the updated node configuration from the second Git repository, and update the corresponding operating environment of the local blockchain application.

[0058] like Figure 7 As shown, in another embodiment, a GitOps-based blockchain system continuous delivery device 600 further includes:

[0059] The system recovery module 606 is used to call the historical configurations in the first Git repository and the second Git repository to restore the operating environment of the local blockchain application when an exception occurs when updating the operating environment of the local blockchain application.

[0060] It should be understood that the GitOps-based blockchain system continuous delivery device of the embodiment of this specification can also execute Figures 1 to 5 A method for executing a continuous delivery device (or equipment) of a blockchain system based on GitOps, and realizing a continuous delivery device (or equipment) of a blockchain system based on GitOps in Figures 1 to 5 The functions of the example shown will not be described in detail here.

[0061] Embodiment 3

[0062] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 8At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0063] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0064] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0065] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a shared resource access control device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0066] Initialize a blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration; submit the chain-level configuration to a first Git repository and the node configuration to a second Git repository; when the first participant updates the blockchain configuration, it includes:

[0067] The first participant pulls the latest chain-level configuration from the first Git repository, updates the chain-level configuration, and submits the updated chain-level configuration to the first Git repository;

[0068] The second participant perceives the change of the chain-level configuration in the first Git repository, pulls the updated chain-level configuration from the first Git repository, updates the local node configuration, and submits the updated node configuration to the second Git repository;

[0069] The application deployment system senses the change of the node configuration in the second Git repository, pulls the updated node configuration from the second Git repository, and updates the corresponding operating environment of the local blockchain application.

[0070] The above is as in this manual Figures 1 to 5 The embodiment shown discloses a method for continuous delivery of a blockchain system based on GitOps, which can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in software form. The above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiments of this specification can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in a decoding processor. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0071] Of course, in addition to software implementation, the electronic device of the embodiments of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0072] Embodiment 4

[0073] The embodiment of the present specification also provides a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figures 1 to 5The method of the embodiment shown is specifically used to perform the following method:

[0074] Initialize a blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration; submit the chain-level configuration to a first Git repository and the node configuration to a second Git repository; when the first participant updates the blockchain configuration, it includes:

[0075] The first participant pulls the latest chain-level configuration from the first Git repository, updates the chain-level configuration, and submits the updated chain-level configuration to the first Git repository;

[0076] The second participant perceives the change of the chain-level configuration in the first Git repository, pulls the updated chain-level configuration from the first Git repository, updates the local node configuration, and submits the updated node configuration to the second Git repository;

[0077] The application deployment system senses the change of the node configuration in the second Git repository, pulls the updated node configuration from the second Git repository, and updates the corresponding operating environment of the local blockchain application.

[0078] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the protection scope of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

[0079] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0080] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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, 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. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0081] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0082] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. A continuous delivery method for a blockchain system based on GitOps, characterized in that: Initialize blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least chain-level configuration and node configuration; Submitting the chain level configuration to the first Git repository and the node configuration to the second Git repository; When the first participant updates the blockchain configuration, it includes: The first participant pulls the latest chain-level configuration from the first Git repository, updates the chain-level configuration, and submits the updated chain-level configuration to the first Git repository; The second participant perceives the change of the chain-level configuration in the first Git repository, pulls the updated chain-level configuration from the first Git repository, updates the local node configuration, and submits the updated node configuration to the second Git repository; The application deployment system senses the change of the node configuration in the second Git repository, pulls the updated node configuration from the second Git repository, and updates the corresponding operating environment of the local blockchain application; Among them, the declarative initialization of the blockchain configuration includes initializing the corresponding data structure according to the blockchain configuration, and the data structure at least includes a data structure corresponding to the chain level configuration and a data structure corresponding to the node configuration.

2. The method according to claim 1, characterized in that The first Git repository is used to store public configuration information, and the second Git repository is used to store private configuration information.

3. The method according to claim 1, characterized in that The first participant submits the updated chain-level configuration to the first Git repository, including: initiating a review of the updated chain-level configuration, and merging it into the main branch of the first Git repository after the blockchain participant reviews the chain-level configuration modification.

4. The method according to claim 1, characterized in that: The second participant perceives the change of the chain-level configuration in the first Git repository by adopting a publish-subscribe method, including a WebHook method.

5. The method according to claim 1, characterized in that It also includes calling the historical configurations in the first Git repository and the second Git repository to restore the operating environment of the local blockchain application when an exception occurs when updating the operating environment of the local blockchain application.

6. A continuous delivery device for a blockchain system based on GitOps, characterized in that: include: A blockchain configuration initialization module, used to initialize the blockchain configuration in a declarative manner, wherein the blockchain configuration includes at least a chain-level configuration and a node configuration; A blockchain configuration sub-warehouse management module, used to submit the chain-level configuration to the first Git warehouse and the node configuration to the second Git warehouse; A chain-level configuration update module, configured to pull the latest chain-level configuration from the first Git repository, update the chain-level configuration, and submit the updated chain-level configuration to the first Git repository when the first participant updates the blockchain configuration; A node configuration update module, used for the second participant to perceive the change of the chain-level configuration in the first Git repository, pull the updated chain-level configuration from the first Git repository, update the local node configuration, and submit the updated node configuration to the second Git repository; The blockchain application system operating environment update module is used for the application deployment system to perceive the changes in the node configuration in the second Git repository, pull the updated node configuration from the second Git repository, and update the corresponding operating environment of the local blockchain application; wherein, The blockchain configuration initialization module includes initializing a corresponding data structure according to the blockchain configuration, and the data structure at least includes a data structure corresponding to the chain level configuration and a data structure corresponding to the node configuration.

7. The device according to claim 6, characterized in that The first Git repository is used to store public configuration information, and the second Git repository is used to store private configuration information.

8. The device according to claim 6, characterized in that The first participant in the chain-level configuration update module submits the updated chain-level configuration to the first Git repository, including: initiating a review of the updated chain-level configuration, and merging it into the main branch of the first Git repository after the blockchain participant reviews the chain-level configuration modification.

9. The device according to claim 6, characterized in that The second participant in the node configuration update module perceives the change of the chain-level configuration in the first Git repository by adopting a publish-subscribe method, including a WebHook method.

10. The device according to claim 6, characterized in that It also includes a system recovery module, which is used to call the historical configurations in the first Git repository and the second Git repository to restore the operating environment of the local blockchain application when an exception occurs when updating the operating environment of the local blockchain application.

11. An electronic device, characterized in that: include: processor; as well as A memory arranged to store computer executable instructions which, when executed, cause the processor to perform the method of any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores one or more programs, which, when executed by an electronic device including a plurality of application programs, cause the electronic device to execute the method according to any one of claims 1 to 5.

Images