We test our implementation by validating within our tests that the requirements are present in our configuration file. Pester can produce artifacts such as Code Coverage and Test Result files for reporting results in CI pipeline. Tests can be run locally and should be integrated into a build script in a CI pipeline. Pester follows a file naming convention *.Tests.ps1, and uses a simple set of functions: Describe, Context, It, Should, and Mock to create a mini-DSL for writing tests. It is also a base for tools that validate whole environments, cloud deployments, database configurations, etc.

Pester is most commonly used for writing unit and integration tests. Pester is an testing- and mocking framework for PowerShell. Excellent tool for monitoring platform stability and health.Excellent tool for blue/green deployment strategies.Typically used in Integration/Quality/Pre-production/Production.Validates the complete flow of the multiple IaC artifacts.Executed after the IaC has been deployed.Validate the correct functionality of each IaC file/directive.Validates format, naming conventions, structure.The declarative approach is hard to testĭifferent Validation Strategies Static or style checks.This is a significant advantage, but it requires a certain degree of monitoring to react as unknown issues arise. With IaC, your applications can be continually updated while running, and everything is still under compliance. Otherwise, you run serious risks when it comes to application security and function. IaC is only an effective tool when you incorporate this into your DevOps process, and you are willing to run tests and validate your code continuously. But as with any other artifacts of a solution, we need to validate and enforce quality. With the advent of virtual infrastructure, IaC found its space and brought all the advantages of code (speed, repeatability, and human error removal). In turn, when executed, it generates the infrastructural artifacts necessary to support the solution. Infrastructure-as-Code (IaC) is a well-known approach by which the infrastructure requirements are described in code and configuration files. Multiple tools available: PowerShell DSC, InsPec, Open Policy Agent.Run compliance tests late to detect breaches and drifts (shift right).Run compliance tests early and frequently (shift left).Promote descriptive approaches vs pure code.Run them while in production to detect unexpected changes (drifts) from the described initially. Run compliance tests whenever possible, not just at later stages. Use descriptive approaches as PowerShell Desired State Configuration (DSC) vs just code as they are simpler to understand, read and maintain. Enables and simplifies audits through programmatically defined evidence gathering processesĬode the requirements as a test.Integrates compliance into daily practices, mitigating compliance knowledge silos.

Just as with any other *aC, precision and repeatability of code execution eliminate human error. Policies: Government, finance, health, etc.

Measured against regulatory standards and internal governance.

Using code to describe, validate, (possibly) remediate, monitor, and report compliance requirements and status.

This automation comes in the form of code and is integrated into the code repositories used by Devs and Engineers. Compliance-as-Code What is compliance as code?Ĭompliance-as-Code can be summarized as the organizational capability to automate the implementation, verification, remediation, monitoring, and compliance status reporting.

Pester code coverage