Pattern - Preflight Validation of Configuration Information
If you have all the configuration information, and knowledge of how that information is interpreted, it is possible to do preflight validation, a check that everything is valid before you actually commence a deployment.
Features
- The runtime takes the input configuration and checks that it is valid against its rules.
Advantages
- Avoids having to deploy a configuration before its invalidity is discovered.
- Guarantees that only valid configurations are deployed.
- If the rules are extensible, allows for organisation-specific policies to be applied to validate the configuration.
- Allows for a rapid iterative cycle of configuration refinement.
Disadvantages
- Requires the runtime to understand the semantics of all operations prior to deployment.
- Alternatively: restricts preflight to that subset of the configuration that can be validated pre-deployment.
SmartFrog support
SmartFrog has a parse-time validation, in which the syntax of all included .sf files are checked, their presence on the classpath, and the ability of non-LAZY links to be resolved. Components that have had schemas defined in their template are validated against the schema.
What SmartFrog does not do and it is important to recognize this, is check that any LAZY links can be resolved. This is because it is not an error for LAZY references to not resolve, prior to deployment.
Furthermore, there is no validation of the actual actions of a component. A component that creates a database does not verify in preflight whether the target directory is present, or if the specific database product is installed. These are checks that are left until deploy time. At that point in time the failures will be detected and raised with the container, which may choose to roll back the deployment.
Preflight Validation in Build Tools
Preflight validation is used in Make to verify that all the required artifacts exist, or can be
created through a sequence of supplied rules. Often-times, people ask for an equivalent for Ant, but this is not possible as the outputs of every task cannot be predicted -indeed, there is no requirement that the outputs of every task are new files in the local filesystem. This allows for complex operations: XSL transformations, XML to code generation, but does place more emphasis on iterative development. Microsoft's MSBuild requires each task to list its input and outputs, both as local files. This helps in preflight and IDE integration, at the expense of flexibility.