Differences

This shows you the differences between two versions of the page.

--- dido:99_annexes:annex-b-terms-and-definitions:i:iac [2026/07/13 12:15] – created nick_dido
+++ dido:99_annexes:annex-b-terms-and-definitions:i:iac [2026/07/24 00:12] (current) – nick_dido
@@ Line 1: / Line 1: @@
 ====== Infrastructure as Code (IaC) ======
-[[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]]
+[[dido:99_annexes:annex-b-terms-and-definitions:start|Go to Terms and Definitions]]
 ===== Discussion =====
-Infrastructure as Code (IaC) represents infrastructure through machine-processable definitions that automated tools use to provision, configure, modify, verify, and remove infrastructure resources.
+Infrastructure as Code (IaC) applies software-engineering and [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration_management|Configuration Management]] practices to the representation and control of [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure|Infrastructure]].
-IaC applies software-engineering and [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration_management|Configuration Management]] practices to infrastructure. These practices may include source control, review, testing, [[dido:99_annexes:annex-b-terms-and-definitions:v:version_pinning|Version Pinning]], automated execution, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], and controlled change.
+IaC represents an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_configuration|Infrastructure Configuration]] as one or more machine-processable [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] that automated tools or workflows process without manual transcription.
-An IaC definition may describe compute, storage, networking, identity, security, monitoring, provider configuration, relationships, and lifecycle behavior.
+Infrastructure as Code can describe:
-Within Crucible, an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] may contain IaC definitions that a deployment process realizes through the selected [[dido:99_annexes:annex-b-terms-and-definitions:p:provider_plugin|Provider Plugin]] and [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_platform|Deployment Platform]].
+  * [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_resource|Infrastructure Resources]]
+  * Configuration values
+  * Relationships among Infrastructure Resources
+  * Required inputs and parameters
+  * Constraints
+  * Dependencies
+  * [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] references
+  * Provider configuration
+  * Security configuration
+  * Monitoring configuration
+  * Lifecycle behavior
+  * Required or observed infrastructure state
+Automated tools use IaC Artifacts to perform or support activities such as:
+  * Provisioning Infrastructure Resources
+  * Configuring Infrastructure Resources
+  * Modifying Infrastructure Resources
+  * Verifying Infrastructure Configuration
+  * Removing Infrastructure Resources
+  * Comparing required and observed infrastructure state
+Infrastructure as Code commonly uses [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control|Version Control]] to identify, retrieve, compare, and manage revisions of IaC Artifacts.
+Infrastructure as Code differs from a manually executed infrastructure procedure:
+  * Infrastructure as Code provides a machine-processable representation of Infrastructure Configuration
+  * A manually executed procedure depends on a person to interpret and perform procedural instructions
+Infrastructure as Code also differs from an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_environment|Infrastructure Environment]]:
+  * Infrastructure as Code represents Infrastructure Configuration
+  * An Infrastructure Environment is the operational or development context described, created, modified, or managed through that configuration
+Infrastructure as Code can use:
+  * [[dido:99_annexes:annex-b-terms-and-definitions:d:declarative_configuration|Declarative Configuration]]
+  * Procedural configuration
+  * A combination of declarative and procedural configuration
+A Declarative Configuration specifies a required result without prescribing the sequence of procedural steps used to produce that result.
 ===== Definition =====
-//representation of infrastructure through machine-processable definitions used by automated tools to provision, configure, modify, verify, and remove infrastructure resources//
+//practice of representing and controlling [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_configuration|Infrastructure Configuration]] as machine-processable [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] that automated tools or workflows process//
 ===== Source =====
-Generalized from infrastructure automation, software configuration management, cloud computing, and DevOps usage and specialized for the Crucible architecture and operational model.
+  * Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
+  * Generalized from infrastructure automation, software configuration management, cloud computing, and DevOps usage
 ===== Note =====
-IaC identifies an engineering approach rather than a particular language, tool, provider, or file format.
+Infrastructure as Code identifies an engineering approach rather than a particular language, tool, provider, or file format.
-Machine-processable infrastructure definitions do not become controlled IaC solely because they exist as files. Effective IaC also depends on version control, review, validation, repeatable execution, and change governance.
+Infrastructure as Code does not by itself establish:
+  * Configuration approval
+  * Deployment authorization
+  * Configuration validity
+  * Revision retention
+  * Infrastructure compliance
+  * Successful deployment
+  * Repeatable execution
+  * Change governance
+Separate requirements and processes govern those characteristics.
+Version control, review, validation, testing, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], repeatable execution, and controlled change strengthen the governance and reliability of Infrastructure as Code but do not define whether a machine-processable Infrastructure Configuration is IaC.
+Within Crucible, an [[dido:99_annexes:annex-b-terms-and-definitions:i:infrastructure_baseline|Infrastructure Baseline]] can contain IaC Artifacts that a deployment process realizes through a selected Provider Plugin and [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_platform|Deployment Platform]].
+The term does not prescribe a configuration language, schema, file format, [[dido:99_annexes:annex-b-terms-and-definitions:v:version_control_system|Version Control System]], provisioning tool, cloud provider, virtualization platform, container platform, or operating system.
 ===== Example =====
-An IaC definition specifies the compute nodes, virtual networks, subnets, storage, security rules, and load balancer required for a Kubernetes platform. An automated deployment process realizes those resources in the selected Cloud Environment.
+An IaC Artifact specifies the compute nodes, virtual networks, storage resources, security rules, and load balancer required for an Infrastructure Environment.
+An automated deployment workflow processes the Artifact and realizes the specified Infrastructure Resources on the selected [[dido:99_annexes:annex-b-terms-and-definitions:d:deployment_target|Deployment Target]].
 ----