Version pinning configures a dependency to use a specific module, tool, plugin, or database version instead of accepting automatic updates. In infrastructure as code, it preserves idempotency and helps existing configurations continue using known outputs without introducing drift. section 5.2 section 13.2.1
Apply version pinning as an operational control:
- Tag and publish a known module release, then refactor every consuming configuration to reference that release. section 5.2
- Pin module, tool, and plugin versions before upgrading so breaking changes do not reach every consumer automatically. section 13.2.1
- Review compatibility, defaults, documentation, and commit history before approving a pinned dependency for team use. section 13.1.1
- Mirror approved modules internally to retain availability when a public endpoint fails, and recheck each new release before approval. section 13.1.3
Database module migration
A database module is tagged v1.0.0 while applications still consume its endpoint and password outputs. Consumers pin v1.0.0 while the module changes to store passwords in a secrets manager. The revised module is tagged v2.0.0; teams then refactor their infrastructure as code to retrieve the password through the new secrets-manager path. section 5.2
Figure 13.5 Before you upgrade a tool, your checklist should include pinning and checking all versions for modules, plugins, and tools.
Use the upgrade checklist to inspect and pin module, plugin, and tool versions before changing infrastructure. section 13.2.1
