Template deployment system and template deployment method

Abstract

To enable deployment of a template based on a dependency relation while maintaining a loose coupling between templates.SOLUTION: A plurality of kinds of states that can be taken by a project are defined in a state definition table 130, and a precondition showing a state in which a template can be deployed and a postcondition showing a state that must be satisfied after deployment of the template are defined in a template definition table 120. The precondition and the postcondition in the template definition table are defined as a logical expression of a state defined in the state definition table, are tested as to whether they satisfy a precondition and a postcondition defined in a template to be deployed when a series of templates are successively deployed from the head, and the template is deployed in a deployment environment in a case where the test ends normally.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] The present invention relates to a template deployment system and a template deployment method using the same. [Background technology]

[0002] In the development of cloud-native applications (hereafter referred to as "apps") that are based on the cloud, the use of templates to rapidly build infrastructure (hereafter referred to as "infrastructure") and middleware is becoming more common. In app development, combining and deploying templates that meet infrastructure or system requirements can reduce the burden on on-site system engineers who are not familiar with cloud-native technology, and by accumulating on-site knowledge as templates, it can also be applied to other projects.

[0003] Patent Document 1 discloses an information processing system that automates the conversion of an order sheet describing system requirements and application requirements for a cloud service into code, the deployment of resources, and the testing of resources. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-157612 Summary of the Invention [Problem to be solved by the invention]

[0005] When combining and deploying multiple templates according to requirements, the deployment of one template affects the deployment of other templates that reference it, which is called dependency.

[0006] The information processing system disclosed in Patent Document 1 includes a determination control unit that deploys resources on a cloud based on code and executes tests on the resources to determine whether the resources can be used. However, the determination control unit in Patent Document 1 does not determine the dependency relationships between templates, so the user must select the templates to deploy taking the dependency relationships into consideration. [Means for solving the problem]

[0007] A template deployment system that is one embodiment of the present invention is a template deployment system that deploys a series of templates selected according to a project into a deployment environment, and includes a database that stores a state definition table that defines multiple types of states that a project can be in, and a template definition table that defines preconditions that indicate states in which a template can be deployed and postconditions that indicate states that must be satisfied after the template is deployed, and a template deployment unit that deploys the series of templates into the deployment environment, wherein the preconditions and postconditions in the template definition table are defined as logical expressions for the states defined in the state definition table, and as the template deployment unit deploys the series of templates in order from the top, it tests whether the preconditions and postconditions defined in the template to be deployed are satisfied, and if the test is successful, it deploys the template into the deployment environment. [Effects of the Invention]

[0008] According to the present invention, it is possible to deploy templates based on dependency relationships while maintaining loose coupling between the templates.

[0009] The details of at least one implementation of the subject matter disclosed herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the disclosed subject matter will become apparent from the following disclosure, drawings, and claims. [Brief explanation of the drawings]

[0010] [Figure 1A] FIG. 1 is a block diagram illustrating an example of a main configuration of a template deployment system. [Figure 1B] FIG. 1 is a block diagram showing a main configuration of an information processing device. [Figure 2A] FIG. 1 is a diagram for explaining an approach to the problem in the present invention. [Figure 2B] FIG. 1 is a diagram for explaining an approach to the problem in the present invention. [Figure 3] FIG. 10 is a diagram showing the flow of template deployment processing via a user interface. [Figure 4] FIG. 10 is a diagram illustrating a processing flow of an infrastructure requirement definition unit. [Figure 5] FIG. 10 is a diagram showing a processing flow of a template search unit. [Figure 6] FIG. 10 is a diagram showing a processing flow of a template validation unit. [Figure 7] FIG. 10 is a diagram illustrating a processing flow of a template deployment unit. [Figure 8A] FIG. 10 is a diagram illustrating a deployment process. [Figure 8B] FIG. 10 is a diagram illustrating a deployment process. [Figure 9A] FIG. 10 is a diagram for explaining a test process. [Figure 9B] FIG. 10 is a diagram for explaining a test process. [Figure 10] 10 is an example of a data structure of an infrastructure requirement definition table. [Figure 11A] 10 is an example of a data structure of a template definition table. [Figure 11B] 10 is an example of a precondition expression or a postcondition expression. [Figure 12] 10 is an example of a data structure of an infrastructure state definition table. [Figure 13] 1 is an example of a data structure of a project file. DETAILED DESCRIPTION OF THE INVENTION

[0011] The approach of the present invention will be described using an example. Assume that a user is considering an infrastructure construction (project) for creating a relational database (RDB) on the cloud and collecting RDB metrics (e.g., CPU usage, memory usage, etc.). In this case, as shown in FIG. 2A, templates are required: a high-availability container infrastructure template that allocates and monitors IT resources to an execution environment ("container") built on the operating system (host OS) of a physical machine in the cloud; an RDB template that creates an RDB; and a metrics collection template that collects metrics from the container. However, for example, if the RDB is created in multiple availability zones (AZ) rather than in a single one, and redundancy is achieved through remote data centers, a redundant RDB template must be used instead of an RDB template. Furthermore, the RDB Exporter template that outputs metrics from the RDB must also be compatible with the redundant RDB. Conventionally, users had to thoroughly understand the infrastructure state created by each template, select an appropriate template based on dependencies, and then deploy the template.

[0012] In contrast, in the present invention, for each template, preconditions, which are the conditions under which the template can be deployed, and postconditions, which must be met after the template is deployed, are defined using logical expressions for the project's possible states. For example, in the example of Figure 2B, deploying the redundant RDBs template requires two infrastructure conditions: "the high-availability container infrastructure template is deployed" and "multiple availability zones." Therefore, the redundant RDBs template is tested to ensure that it satisfies the preconditions, and if successful, the redundant RDBs template is deployed. In addition, after the redundant RDBs template is deployed, the postconditions are tested. Because the preconditions and postconditions are defined using logical expressions for the states, the test can be performed using a test script written in a language such as Python or Go.

[0013] Furthermore, in the example of Figure 2B, the infrastructure state "redundant RDBs template is deployed" is one of the preconditions for the RDB Exporter (multiple) template. In this way, by defining the preconditions and postconditions that a template must satisfy as logical expressions for the possible states of a project, selecting the permutation of templates that satisfy the preconditions and postconditions, and deploying them sequentially, users can build infrastructure using templates without being aware of the dependencies between templates.

[0014] A different approach from the present invention is to hard-code conditional branching based on dependencies into templates. However, this approach is undesirable because it results in tightly coupling templates and makes maintenance and recombination of templates difficult.

[0015] An embodiment of the present invention will be described below with reference to the drawings. The templates in the embodiment are IaC (Infrastructure as Code) that code the construction of IT resources. In this case, the project requirements and the preconditions and postconditions of the template, which will be described later, are expressed as logical expressions of the possible states of the project, i.e., the infrastructure state. The template is not limited to IaC and may be, for example, a coded version of the construction of middleware, and is not limited to the IaC of the present embodiment. In this case, the project requirements and the preconditions and postconditions of the template are expressed as logical expressions of the possible states of the project according to the content coded in the template.

[0016] 1A is a block diagram showing an example of the main configuration of a template deployment system. In this embodiment, a shared database 100, a user environment (server) 200, and a deployment environment (cloud) 300 are connected to each other via a network so that they can communicate with each other.

[0017] Specifically, the user environment 200 is realized by an information processing device including, as shown in FIG. 1B, a processor (CPU) 401, a memory 402, a storage device 403, an input / output device 404, a communication device 405, and a bus 406 as its main components. The processor 401 functions as a functional unit that provides a predetermined function by executing processing in accordance with a program loaded into the memory 402. For example, the processor 401 functions as the infrastructure requirements definition unit 220 by executing an infrastructure requirements definition program. The same applies to other programs. The storage device 403 stores data and programs used by the functional units. The input / output device 404 includes input devices such as a keyboard and a pointing device, and an output device such as a display. The communication device 405 enables communication with other information processing devices via a network. These are connected to each other via the bus 406 so that they can communicate with each other.

[0018] During the process of executing each of the functional units, the user interface 210, the infrastructure requirement definition unit 220, the template search unit 230, the template validation unit 240, and the template deployment unit 250, a project file 260 is created and stored in the storage device 403. The user selects a permutation of templates by executing each of the functional units in the user environment 200, and builds infrastructure by sequentially deploying the selected templates to the deployment environment (cloud) 300. Details of each functional unit and the project file 260 will be described later.

[0019] The shared database 100 stores an infrastructure requirement definition table 110, a template definition table 120, and an infrastructure status definition table 130, which are used in the above process. These tables will also be described in detail later.

[0020] The user interacts with the deployment system via the user interface 210 to execute processes from setting infrastructure requirements to deploying the template. This flow is shown in Fig. 3. The template deployment process of this embodiment will be described below with reference to Fig. 3.

[0021] First, the requirements for the infrastructure to be constructed are specified (211). In this embodiment, since the project is infrastructure construction, the project requirements are defined by the infrastructure requirements. The infrastructure requirements are specified by the infrastructure requirements definition unit 220. The processing flow of the infrastructure requirements definition unit 220 is shown in FIG.

[0022] The infrastructure requirement definition unit 220 reads the infrastructure requirement definition table 110 from the shared database 100, and presents the requirement names and requirement details to the user by displaying them on the display, which is the input / output device 404 of the user environment 200 (S01).

[0023] 10 shows an example of the data structure of the infrastructure requirements definition table 110. Requirement ID 111 stores an ID that uniquely identifies an infrastructure requirement (project requirement), requirement name 112 stores a name that outlines the infrastructure requirement, infrastructure requirement details 113 stores detailed content of the infrastructure requirement, and infrastructure requirement conditional expression 114 stores an expression of the infrastructure requirement using a logical expression for the infrastructure state. Regarding infrastructure requirement conditional expression 114, for example, requirement R01 is to create an infrastructure state called "NewProject." In this case, this is a single infrastructure state, but requirement R02 is to create an infrastructure state that is expressed as a logical OR (combination) of two infrastructure states, "NewProject" and "ResourceQuota."

[0024] The infrastructure states used in the logical expression of the infrastructure requirement condition formula 114 are defined in an infrastructure state definition table 130. Fig. 12 shows an example of the data structure of the infrastructure state definition table 130. An ID that uniquely identifies an infrastructure state is stored in infrastructure state ID 131, a definition of the infrastructure state is stored in state description 132, definitions of parameters that the infrastructure state has (referred to as "state parameters") are stored in state parameter definition 133, and definitions of test parameters used to test the template are stored in test parameter definition 134.

[0025] Returning to the explanation of Figure 4, the user selects one or more infrastructure requirements that the user wishes to achieve from the presented infrastructure requirements (S02). The infrastructure requirements definition unit 220 combines infrastructure requirement conditional expressions corresponding to the selected infrastructure requirements (S03), and outputs the infrastructure requirements selected by the user and the combined conditional expressions to the project file 260 (S04). In the example data structure of the project file 260 shown in Figure 13, the requirement IDs of the infrastructure requirements selected by the user are stored in a list format ([requirement ID,...]) in the user-selected requirements 261. The infrastructure requirements of the infrastructure to be built by the user are expressed as a logical expression of the infrastructure state obtained by taking the logical sum of the infrastructure requirement conditional expressions of the listed infrastructure requirements.

[0026] Now that the infrastructure requirement conditional expression (hereinafter referred to as the target infrastructure requirement conditional expression) for the infrastructure to be constructed in the project has been obtained by the user, a deployment pattern can be selected. A deployment pattern is a list of templates that realize the target infrastructure requirement conditional expression. For this reason, as shown in FIG. 3, the deployment system searches for a series of templates that can obtain the target infrastructure requirement conditional expression, i.e., a deployment pattern (212), and presents one or more deployment pattern candidates to the user (212a), from which the user selects one deployment pattern (212b). The search and selection of a deployment pattern are performed by the template search unit 230.

[0027] 11A shows an example of the data structure of template definition table 120. Template ID 121 stores an ID that uniquely identifies a template, template name 122 stores the name of the template, template details 123 stores a description of the template, input definition 124 stores definitions of parameters input to the template, output definition 125 stores definitions of parameters output from the template, pre-condition expression 126 stores a condition expression that indicates a state in which the template can be deployed (pre-state), and post-condition expression 127 stores a condition expression that indicates a state that must be satisfied after deployment (post-state).

[0028] 11A, the precondition expression 126 and the postcondition expression 127 have the same names as the infrastructure state IDs (see FIG. 12). This means that the condition is that the infrastructure state indicated by the infrastructure state ID is established, and the specific test content is specified in detail. For example, when "ResourceQuota" is referenced as the precondition expression or the postcondition expression, a group of logical expressions as shown in FIG. 11B is defined. Each logical expression specifies a condition for a test parameter.

[0029] The processing flow of the template search unit 230 is shown in Figure 5. The template search unit 230 reads the target infrastructure requirement conditional expressions from the project file 260 (S11), and searches for required template options from the template pre-condition expressions 126 and post-condition expressions 127 defined in the template definition table 120 (S12). The target infrastructure requirement conditional expressions are expressed as logical expressions of the infrastructure state. On the other hand, the post-condition expressions of the template contain information about the system state that must be satisfied after the template is deployed, so templates whose logical expressions of the infrastructure state included in the post-condition expressions of the template satisfy the target infrastructure requirement conditional expressions are extracted as candidates.

[0030] The search process (S12) will be described with reference to the example in Fig. 3. In this example, the target infrastructure requirement condition formula is logical formula 270 (the logical sum of "infrastructure state A" and "infrastructure state B"). The deployment pattern to be searched for is a permutation of templates starting from "infrastructure state E" obtained by executing template 0 (not shown) with no prior state, and ending with the logical sum of "infrastructure state A" and "infrastructure state B". If there are multiple possibilities for the intermediate infrastructure states on the way from "infrastructure state E" to "infrastructure state A" and "infrastructure state B", they are extracted comprehensively.

[0031] In this case, Template 3 and Template 4 are extracted as templates whose post-condition expression satisfies the logical sum of "Infrastructure State A" and "Infrastructure State B" (S13). Next, Template 1 and Template 1' are extracted whose post-condition expression satisfies "Infrastructure State C," which is the pre-state of Template 3, and Template 2 is extracted whose post-condition expression satisfies "Infrastructure State D," which is the pre-state of Template 4 (S14). Figure 3 shows a simple example in which the pre-state of Template 1, Template 1', and Template 2 is "Infrastructure State E," but if not, the process is repeated until the pre-state of the extracted template becomes "Infrastructure State E." As a result, deployment pattern candidate 271 is obtained.

[0032] Returning to the explanation of Figure 5, the user selects one deployment pattern from the deployment pattern candidates presented by the system (S15) and stores the selected deployment pattern in the project file 260 (S16). In the example of Figure 3, the template search unit 230 presents deployment pattern candidates 271 to the user (212a), and the user selects one deployment pattern 272 from the candidates (212b). In the example of the data structure of the project file 260 shown in Figure 13, the deployment pattern selected by the user is stored in the deployment pattern 262 in a list format ([template ID,...]). Note that in this example, whether validation and deployment were successful is also stored as information, as will be described later.

[0033] Next, parameters (parameters defined by the user for the template in the input definition 124 in FIG. 11A) are set for the template that constitutes the selected deploy pattern, and consistency is checked.

[0034] The processing flow of the template validation unit 240 is shown in Figure 6. The template validation unit 240 reads the selected deployment pattern from the project file 260 (S21), and the user inputs the required parameters for each template that makes up the deployment pattern (S22). The template validation unit 240 checks the consistency of the input parameters (S23), and if there is a mismatch, prompts the user to re-input the parameters (S24). For example, if the input parameters do not satisfy the preconditions of other templates that reference that template, consistency is not satisfied. If all parameters of each template that makes up the deployment pattern can be set without contradiction, the validation results indicate that deployment is possible, and the user is notified (S25).

[0035] 3, the template validation unit 240 accepts parameter input from the user (213a) and returns the results of checking the consistency with the constraints (213b). Note that if the user determines during this process that the deployment pattern selected does not satisfy the non-functional requirements, it is advisable to allow the user to reselect from the deployment pattern candidates (214).

[0036] Through the above process, the parameters set by the user for the deploy pattern and each template that constitutes the deploy pattern have been determined, and the templates that constitute the deploy pattern are then deployed. Fig. 3 shows how the user issues a deployment instruction (215) for the deploy pattern 273 in which the parameters of each template have been set.

[0037] The processing flow of the template deployment unit 250 that deploys the templates that make up the deployment pattern is shown in Fig. 7. The template deployment unit 250 receives a deployment execution instruction from the user (S31), and executes the following repeated processing from the beginning to the end of each template that makes up the deployment pattern (S32).

[0038] Here, an overview of the deployment process and test process will be explained.

[0039] Figure 8A shows template A whose pre-state is the logical sum of infrastructure state X and infrastructure state Y, and whose post-state is the logical sum of infrastructure state P and infrastructure state Q. Figure 8B shows the input and output of the deployment process for template A in this case.

[0040] The deployment process for template A is performed by a deploy script 501 defined in the template definition table 120 (see FIG. 1). The input conversion unit 502 references the input definition 124 for template A (see FIG. 11A) and inputs a parameter 511 set by the user, a state parameter 512 for infrastructure state X, and a state parameter 513 for infrastructure state Y to the deploy script 501. The parameter 511 was set during the template validation process, and the state parameters 512 and 513 are defined in the infrastructure state definition table 130 and are parameters output from the template deployed before template A. When the deploy script 501 deploys template A, the output conversion unit 503 references the output definition 125 for template A (see FIG. 11A) and assigns the parameters output from the deploy script 501 to a state parameter 521 for infrastructure state P and a state parameter 522 for infrastructure state Q. The definitions of the state parameters 521 and 522 are also defined in the infrastructure state definition table 130.

[0041] FIG. 9A shows that the postcondition of template A includes infrastructure state K, and infrastructure state K is included in the precondition of template B. FIG. 9B shows the input and output of the test of the postcondition of template A or the test of the precondition of template B in this case.

[0042] In the test process for the post-condition of template A, the test parameter conversion unit 602 refers to the post-condition formula 127 (see FIGS. 11A and 11B) of template A to identify the test content. In this case, since a test of infrastructure state K is included, the test parameter conversion unit 602 refers to the test parameter definition 134 for infrastructure state K (see FIG. 12), extracts test parameters 613 from the post-state of template A, and inputs them together with state parameters 614 to the test script 601. The state parameters 614 are state parameters of infrastructure state K defined in the infrastructure state definition table 130.

[0043] Similarly, in the test process for the preconditions of template B, the test parameter conversion unit 602 refers to the precondition formula 126 of template B (see FIGS. 11A and 11B) to identify the test content. In this case, since a test for infrastructure state K is included, the test parameter conversion unit 602 refers to the test parameter definition 134 for infrastructure state K (see FIG. 12), extracts test parameters 613 from the preconditions of template B, and inputs them together with state parameters 614 to the test script 601. The state parameters 614 are state parameters for infrastructure state K defined in the infrastructure state definition table 130.

[0044] Returning to the explanation of FIG. 7, the repetitive process (S32) is performed sequentially from the beginning to the end of the sequence of deployment patterns. First, the template deployment unit 250 executes a test script for the infrastructure state defined as a precondition (S41). The precondition that the template must satisfy is defined in a precondition expression 126 (see FIG. 11A). It is determined whether the test has ended normally (S42). If the test has ended normally, the precondition expression is not satisfied, so the deployment is interrupted (S43). If the test has ended normally, the template is deployed (S44). This updates the state parameters of the poststate of the template. Next, the test script for the infrastructure state defined as a postcondition is executed (S45). The postcondition that the template must satisfy is defined in a postcondition expression 127 (see FIG. 11A). It is determined whether the test has ended normally (S46). If the test has ended normally, the deployment has been completed normally (S47), so the process moves to processing of the next template.

[0045] If the deployment of all templates constituting the deployment pattern is completed normally, or if the deployment is interrupted (S43) or fails due to the post-condition test ending abnormally (S49), the process does not proceed to processing of the next template, but stores the results of the deployment and test in the project file 260 and notifies the user (S33). Note that if the post-condition test ends abnormally, it is advisable to execute a rollback script and return the template to the state it was in before deployment (S48).

[0046] 13 shows the project file 260 after the deployment process is completed. The deployment pattern 262 of the project file 260 holds result information (true / false) indicating whether validation and deployment were successful for each template. The project file 260 also holds the infrastructure state after the deployment process is completed as infrastructure state 263.

[0047] (Variation 1) A template may be updated or deleted. In this case, the template search unit 230 searches for a deployment pattern template that needs to be reviewed based on the relationship between the pre-states and post-states between the templates, and presents the template to the user. For example, if template 3 of the deployment pattern 272 (see FIG. 3 ) is updated to template 3', depending on the update content, deployment of template 3' may fail if template 1 remains. For this reason, templates that need to be reviewed among the deployment patterns and whose post-conditions include the infrastructure state included in the pre-conditions of the updated or deleted template are extracted and presented to the user. The user can easily handle template updates and deletions by having the template search unit 230 extract deployment pattern candidates for the presented deployment pattern portion.

[0048] (Variation 2) It may also be possible to create multiple new projects. To do this, the template deployment unit 250 simply assigns a unique ID to each template based on the input parameters. This makes it possible to manage deployments to multiple identical IT resources. Similarly, by assigning a unique ID to the infrastructure status based on the unique ID of the template to be deployed, multiple infrastructure statuses can be managed.

[0049] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0050] The above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a storage device such as a memory, a hard disk drive, or a solid-state drive (SSD), or in a computer-readable non-volatile data storage medium such as an IC card, an SD card, or a DVD. [Explanation of symbols]

[0051] 100: Shared database, 110: Infrastructure requirement definition table, 111: Requirement ID, 112: Requirement name, 113: Infrastructure requirement details, 114: Infrastructure requirement condition expression, 120: Template definition table, 121: Template ID, 122: Template name, 123: Template details, 124: Input definition, 125: Output definition, 126: Pre-condition expression, 127: Post-condition expression, 130: Infrastructure state definition table, 131: Infrastructure state ID, 132: State description, 133: State parameter definition, 134: Test parameter definition, 200: User environment (server), 210: User interface, 220: Infrastructure requirement definition part, 230: Template search part, 240: Template validation deployment unit, 250: template deployment unit, 260: project file, 261: user-selected requirements, 262: deployment pattern, 263: infrastructure state, 270: logical expression, 271: deployment pattern candidate, 272, 273: deployment pattern, 300: deployment environment (cloud), 401: processor (CPU), 402: memory, 403: storage device, 404: input / output device, 405: communication device, 406: bus, 501: deployment script, 502: input conversion unit, 503: output conversion unit, 511: parameters, 512, 513, 521, 522: state parameters, 601: test script, 602: test parameter conversion unit, 613: test parameters, 614: state parameters.

Claims

1. A template deployment system that deploys a series of templates selected according to a project to a deployment environment, a database that stores a state definition table that defines multiple types of states that a project can be in, and a template definition table that defines preconditions that indicate the states in which a template can be deployed and postconditions that indicate the states that must be satisfied after the template is deployed; a template deployment unit that deploys the series of templates to the deployment environment, In the template definition table, preconditions and postconditions are defined as logical expressions of the states defined in the state definition table; The template deployment system is characterized in that, when deploying the series of templates in order from the beginning, the template deployment unit tests whether the preconditions and postconditions defined in the template to be deployed are satisfied, and if the test is completed successfully, deploys the template to the deployment environment.

2. In claim 1, In the state definition table, state parameters, test scripts for performing the tests, and test parameters are defined for each of the states; the template deployment unit tests whether the template satisfies the preconditions defined in the template by inputting state parameters and test parameters for the state corresponding to the preconditions defined in the template into a test script for the state corresponding to the preconditions defined in the template before deploying the template, and does not deploy the template if the template does not satisfy the preconditions.

3. In claim 2, the template deployment unit, after deploying a template, tests whether the template satisfies the postcondition by inputting state parameters and test parameters of the state corresponding to the postcondition defined in the template into a test script for the state corresponding to the postcondition defined in the template, and does not deploy a next template if the template does not satisfy the postcondition.

4. In claim 1, A requirements definition department that defines project requirements, a template search unit that searches for the series of templates that realize the project requirements defined by the requirements definition unit in the deployment environment, the database stores a requirements definition table defining selectable project requirements; the requirements definition table defines the content of the project requirements by a logical expression of the state; the requirement definition unit creates a target requirement condition obtained as a logical sum of logical expressions of the states corresponding to one or more project requirements selected by a user; The template deployment system is characterized in that the template search unit extracts, as deployment pattern candidates, a series of one or more templates whose final template post-conditions satisfy the target requirement conditions.

5. In claim 4, A template validation unit is provided to validate templates. the template validation unit accepts input of parameters for a template that constitutes a deployment pattern selected by a user from the deployment pattern candidates, and if the parameters input to a template do not satisfy preconditions of other templates that reference the selected template, the template validation unit prompts the user to re-input the parameters.

6. In claim 4, when a template included in the set of templates is updated or deleted, the template search unit extracts, as a template that needs to be reviewed, a template whose post-condition includes the state included in the pre-condition of the updated or deleted template.

7. In claim 4, The template deployment system is characterized in that the template deployment unit assigns a unique ID to each parameter input to the template.

8. A template deployment method for deploying a series of templates selected according to a project to a deployment environment using a template deployment system, comprising: The template deployment system includes: a database that stores a state definition table that defines multiple types of states that a project can be in, and a template definition table that defines preconditions that indicate the states in which a template can be deployed and postconditions that indicate the states that must be satisfied after the template is deployed; a template deployment unit that deploys the set of templates to the deployment environment, In the template definition table, preconditions and postconditions are defined as logical expressions of the states defined in the state definition table; the template deployment unit tests whether preconditions and postconditions defined in the template to be deployed are satisfied when deploying the series of templates in order from the beginning, and deploys the template to the deployment environment if the test is successful.

9. In claim 8, In the state definition table, state parameters, test scripts for performing the tests, and test parameters are defined for each of the states; the template deployment unit tests whether the template satisfies the preconditions defined in the template by inputting state parameters and test parameters for the state corresponding to the preconditions defined in the template into a test script for the state corresponding to the preconditions defined in the template before deploying the template, and does not deploy the template if the template does not satisfy the preconditions.

10. In claim 9, the template deployment unit, after deploying a template, tests whether the template satisfies the postcondition by inputting state parameters and test parameters of the state corresponding to the postcondition defined in the template into a test script for the state corresponding to the postcondition defined in the template, and does not deploy a next template if the template does not satisfy the postcondition.

11. In claim 8, The template deployment system includes: A requirements definition department that defines project requirements, a template search unit that searches for the set of templates that realize the project requirements defined by the requirements definition unit in the deployment environment, the database stores a requirements definition table defining selectable project requirements; the requirements definition table defines the content of the project requirements by a logical expression of the state; the requirement definition unit creates a target requirement condition obtained as a logical sum of logical expressions of the states corresponding to one or more project requirements selected by a user; The template deployment method is characterized in that the template search unit extracts, as deployment pattern candidates, a series of one or more templates whose final template post-condition satisfies the target requirement condition.

12. In claim 11, the template deployment system includes a template validation unit that validates templates; the template validation unit accepts input of parameters for a template that constitutes a deployment pattern selected by a user from the deployment pattern candidates, and if the parameters input to the template do not satisfy preconditions of other templates that reference the template, the template validation unit prompts the user to re-input the parameters.

13. In claim 11, wherein, when a template included in the set of templates is updated or deleted, the template search unit extracts, as a template that needs to be reviewed, a template whose post-condition includes the state included in the pre-condition of the updated or deleted template.

14. In claim 11, The template deployment method is characterized in that the template deployment unit assigns a unique ID to each parameter input to the template.

Images