JP7804520B2 - Template deployment system and template deployment method - Google Patents

Description

The present invention relates to a template deployment system and a template deployment method using the same.

In the development of cloud-native applications (hereafter referred to as "apps") that are based on the cloud, the use of templates is accelerating the construction of infrastructure (hereafter referred to as "infrastructure") and middleware. In app development, combining and deploying templates based on infrastructure or system requirements reduces 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.

Patent Document 1 discloses an information processing system that automates the conversion of order sheets containing system requirements and application requirements for cloud services into code, as well as the deployment and testing of resources.

Japanese Patent Application Laid-Open No. 2021-157612

When combining and deploying multiple templates according to your requirements, the deployment of one template will affect the deployment of other templates that reference it. This is called a dependency.

The information processing system disclosed in Patent Document 1 is equipped with a determination control unit that deploys resources to the 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 while taking the dependency relationships into consideration.

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. The system includes a database that stores a state definition table that defines multiple 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 met after the template is deployed, and a template deployment unit that deploys the series of templates into the deployment environment. In the template definition table, the preconditions and postconditions are defined as logical expressions for the states defined in the state definition table. 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 met, and if the test is successful, it deploys the template into the deployment environment.

This invention makes it possible to deploy templates based on dependencies while maintaining loose coupling between templates.

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.

FIG. 1 is a block diagram illustrating an example of a main configuration of a template deployment system. FIG. 1 is a block diagram showing a main configuration of an information processing device. FIG. 1 is a diagram for explaining an approach to the problem in the present invention. FIG. 1 is a diagram for explaining an approach to the problem in the present invention. FIG. 10 is a diagram showing the flow of template deployment processing via a user interface. FIG. 10 is a diagram illustrating a processing flow of an infrastructure requirement definition unit. FIG. 10 is a diagram showing a processing flow of a template search unit. FIG. 10 is a diagram showing a processing flow of a template validation unit. FIG. 10 is a diagram illustrating a processing flow of a template deployment unit. FIG. 10 is a diagram illustrating a deployment process. FIG. 10 is a diagram illustrating a deployment process. FIG. 10 is a diagram for explaining a test process. FIG. 10 is a diagram for explaining a test process. 10 is an example of a data structure of an infrastructure requirement definition table. 10 is an example of a data structure of a template definition table. 10 is an example of a precondition expression or a postcondition expression. 10 is an example of a data structure of an infrastructure state definition table. 1 is an example of a data structure of a project file.

The approach of the present invention will be explained using an example. Suppose a user is considering an infrastructure construction (project) to create a relational database (RDB) on the cloud and collect RDB metrics (e.g., CPU utilization, memory utilization, etc.). In this case, as shown in Figure 2A, templates are required: a high-availability container infrastructure template that allocates and monitors IT resources to the execution environment ("container") built on the OS (host OS) of the physical machine in the cloud; an RDB template that creates the 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 the RDB template. Furthermore, the RDB Exporter template that outputs metrics from the RDB must also be compatible with the redundant RDB. Previously, users had to thoroughly understand the infrastructure state that would be created by each template, select the appropriate template based on dependencies, and then deploy it.

In contrast, in this 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 meets 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 state expressions, the test can be performed using a test script written in a language such as Python or Go.

Furthermore, in the example of Figure 2B, the infrastructure state "Redundant RDBs template deployed" is one of the preconditions for the RDB Exporter (multiple) templates. In this way, by defining the preconditions and postconditions that the template must satisfy in advance as logical expressions for the possible states of the project, selecting a 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.

An alternative approach to the present invention would be to hard-code conditional branching based on dependencies into templates. However, this approach is undesirable because it would result in tightly coupled templates, making maintenance and recombination of templates difficult.

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

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

Specifically, the user environment 200 is realized by an information processing device whose main components are a processor (CPU) 401, memory 402, storage device 403, input/output device 404, communication device 405, and bus 406, as shown in FIG. 1B. The processor 401 functions as a functional unit that provides specified functions by executing processes in accordance with programs loaded into 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 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.

As each functional unit, the user interface 210, infrastructure requirements definition unit 220, template search unit 230, template validation unit 240, and template deployment unit 250, is executed, a project file 260 is created and stored in the storage device 403. The user selects a template sequence by executing each functional unit 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.

The shared database 100 stores the infrastructure requirements definition table 110, template definition table 120, and infrastructure status definition table 130 used in the above process. Details of these tables will be described later.

The user interacts with the deployment system via the user interface 210, performing tasks from configuring infrastructure requirements to deploying the template. This process is shown in Figure 3. The template deployment process of this embodiment will be explained below with reference to Figure 3.

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 Figure 4.

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

Figure 10 shows an example of the data structure of the infrastructure requirements definition table 110. Requirement ID 111 stores an ID that uniquely identifies the 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 represented by the logical OR (combination) of two infrastructure states, "NewProject" and "ResourceQuota".

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

Returning to the explanation of Figure 4, the user selects one or more infrastructure requirements they wish 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 list format ([requirement ID, ...]) in the user-selected requirements 261. The infrastructure requirements of the infrastructure to be constructed by the user are represented by a logical expression of the infrastructure state obtained by taking the logical sum of the infrastructure requirement conditional expressions of the listed infrastructure requirements.

Now that the infrastructure requirement conditional expression (hereinafter referred to as the target infrastructure requirement conditional expression) for the infrastructure the user will build in the project has been obtained, 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 Figure 3, the deployment system searches for a series of templates, i.e., deployment patterns, that can obtain the target infrastructure requirement conditional expression (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 deployment patterns is performed by the template search unit 230.

Figure 11A shows an example of the data structure of the template definition table 120. Template ID 121 stores an ID that uniquely identifies the 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 indicating the state in which the template can be deployed (pre-state), and post-condition expression 127 stores a condition expression indicating the state that must be met after deployment (post-state).

In Figure 11A, the pre-condition expression 126 and post-condition expression 127 are given the same names as the infrastructure state ID (see Figure 12). This means that the condition is that the infrastructure state indicated by the infrastructure state ID is met, and the specific test content is specified in detail. For example, if "ResourceQuota" is referenced as a pre-condition expression or post-condition expression, a group of logical expressions like those shown in Figure 11B is defined. Each logical expression specifies a condition for a test parameter.

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 expression from the project file 260 (S11), and searches for required template options from the template pre-condition expression 126 and post-condition expression 127 defined in the template definition table 120 (S12). The target infrastructure requirement conditional expression is expressed as a logical expression for the infrastructure state. On the other hand, the template post-condition expression contains information about the system state that must be satisfied after the template is deployed, so templates whose logical expression for the infrastructure state included in the template post-condition expression satisfies the target infrastructure requirement conditional expression are extracted as candidates.

The search process (S12) will be explained with reference to the example in Figure 3. In this example, the target infrastructure requirement condition expression is logical expression 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 comprehensively extracted.

In this case, Template 3 and Template 4 are extracted as templates whose post-condition expression satisfies the logical OR 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," the pre-state of Template 3, and Template 2 is extracted whose post-condition expression satisfies "Infrastructure State D," 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 in other cases, 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.

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 data structure of the project file 260 shown in Figure 13, the deployment pattern selected by the user is stored in list format ([template ID, ...]) in the deployment pattern 262. Note that in this example, information on whether validation and deployment were successful is also stored, as will be described later.

Next, parameters (parameters defined by the user for the template in the input definition 124 in Figure 11A) are set for the template that makes up the selected deployment pattern, and consistency is checked.

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 discrepancy, 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 met. If all parameters for each template that makes up the deployment pattern can be set without contradiction, the validation results in notifying the user that deployment is possible (S25).

In the example of Figure 3, the template validation unit 240 accepts parameter input from the user (213a) and returns the results of checking 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).

The above process determines the parameters to be set by the user for the deployment pattern and each template that makes up the deployment pattern, so the templates that make up the deployment pattern are deployed. Figure 3 shows the user issuing a deployment instruction (215) for the deployment pattern 273 in which the parameters for each template have been set.

Figure 7 shows the processing flow of the template deployment unit 250, which deploys the templates that make up the deployment pattern. The template deployment unit 250 receives a deployment execution instruction from the user (S31), and then executes the following repeated process from the beginning to the end of each template that makes up the deployment pattern (S32).

Here, we will provide an overview of the deployment and testing processes.

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 during the deployment process of template A in this case.

Deployment processing for template A is performed by a deploy script 501 defined in the template definition table 120 (see Figure 1). The input conversion unit 502 references the input definition 124 (see Figure 11A) for template A and inputs to the deploy script 501 a parameter 511 set by the user, a state parameter 512 for infrastructure status X, and a state parameter 513 for infrastructure status Y. Parameter 511 was set during the template validation processing, and state parameters 512 and 513 are defined in the infrastructure status 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 (see Figure 11A) for template A and assigns the parameters output from the deploy script 501 to a state parameter 521 for infrastructure status P and a state parameter 522 for infrastructure status Q. The definitions of state parameters 521 and 522 are also defined in the infrastructure status definition table 130.

Figure 9A shows that the postcondition of template A includes infrastructure state K, and that infrastructure state K is included in the precondition of template B. Figure 9B shows the input and output for testing the postcondition of template A or the precondition of template B in this case.

When testing the post-condition of template A, the test parameter conversion unit 602 references the post-condition expression 127 of template A (see Figures 11A and 11B) to identify the test content. In this case, since a test of infrastructure state K is included, the test parameter conversion unit 602 references the test parameter definition 134 for infrastructure state K (see Figure 12), extracts test parameter 613 from the post-state of template A, and inputs it together with state parameter 614 into the test script 601. State parameter 614 is the state parameter of infrastructure state K defined in the infrastructure state definition table 130.

Similarly, in the test process for the preconditions of template B, the test parameter conversion unit 602 references the precondition expression 126 of template B (see Figures 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 references the test parameter definition 134 for infrastructure state K (see Figure 12), extracts test parameter 613 from the precondition of template B, and inputs it together with state parameter 614 into the test script 601. State parameter 614 is a state parameter for infrastructure state K defined in the infrastructure state definition table 130.

Returning to the explanation of Figure 7, the repetitive process (S32) is performed sequentially from the beginning to the end of the deployment pattern sequence. First, the template deployment unit 250 executes the infrastructure state test script defined as the precondition (S41). The precondition that the template must satisfy is defined in precondition expression 126 (see Figure 11A). It is determined whether the test completed successfully (S42). If the test completed unsuccessfully, the precondition expression is not satisfied, and the deployment is aborted (S43). If the test completed successfully, the template is deployed (S44). This updates the state parameters of the template's poststate. Next, the infrastructure state test script defined as the postcondition is executed (S45). The postcondition that the template must satisfy is defined in postcondition expression 127 (see Figure 11A). It is determined whether the test completed successfully (S46). If the test completed successfully, the deployment was completed successfully (S47), and the process moves on to processing the next template.

If the deployment of all templates that make up the deployment pattern is completed successfully, 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 the next template, but instead stores the deployment and test results in the project file 260 and notifies the user (S33). Note that if the post-condition test ends abnormally, a rollback script should be executed to return the template to its state before deployment (S48).

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

(Variation 1)
A template may be updated or deleted. In this case, the template search unit 230 searches for templates that need to be reviewed among the deployment patterns based on the relationships between pre-states and post-states between the templates, and presents the templates 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.

(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 of 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.

The present invention is not limited to the above-described embodiments, and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are 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, and it is also possible 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.

The above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits. The above-mentioned configurations, functions, etc. may also be realized in software by a processor interpreting and executing programs that realize the respective functions. Information such as programs, tables, and files that realize the respective functions can be stored in storage devices such as memory, hard disk drives, and solid-state drives (SSDs), or in computer-readable non-volatile data storage media such as IC cards, SD cards, and DVDs.

100: Shared database, 110: Infrastructure requirements 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 requirements definition section, 230: Template search section, 240: Template validation deployment unit, 250: template deployment unit, 260: project file, 261: user-selected requirements, 262: deployment pattern, 263: infrastructure state, 270: logical formula, 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 (14)

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.