Understanding Network as Code for Unified Branch Deployment Flow

Now that you’re familiar with Unified Branch as Code templates and variable configuration, let’s explore the deployment flow — the conceptual journey from defined templates and variables to fully operational branch networks.

Branch as Code leverages the Meraki Dashboard API as its primary configuration interface, transforming your infrastructure-as-code definitions into live network configurations. The deployment process requires proper API authentication with organization-level permissions to ensure successful configuration management.

Key Requirements:

• API key with appropriate organizational permissions
• Meraki user account with admin or configuration management rights
• Network access to Meraki Dashboard endpoints

💡 Learn More: For detailed API permission requirements, refer to the Meraki API documentation.

The Branch as Code deployment process consists of four conceptual phases, each with distinct responsibilities in transforming your infrastructure definitions into operational network configurations. Understanding these phases helps you better manage and troubleshoot your deployment workflow.

The deployment journey begins with configuration synthesis, where your distributed configuration components converge into a unified data model.

What Happens:

• CVD-aligned templates provide the structural foundation
• Site-specific variables customize configurations for your environment
• Environment credentials establish secure access to your Meraki organization

This synthesis creates a comprehensive data model that serves as the single source of truth for your branch network configuration by performing the rendering. To render the templates, the terraform model module is being used.

The Rendering Process:

# Template processing occurs in the workspace environment
cd workspaces
terraform init
terraform apply

It is important to note that during this step:

• No live deployment occurs during this phase
• All files in \data folder are deep merged along with variables merge to create final YAML configurations
• Output generates merged_configuration.nac.yaml in the workspaces directory, this is configurable in the main.tf file in the workspaces folder.
• Configuration exists only in memory and local files

The associated configuration:

module "model" {
  source           = "github.com/netascode/terraform-meraki-nac-meraki/modules/model"
  yaml_directories = ["../data"]
  write_model_file = "merged_configuration.nac.yaml"
}

This phase transforms your template definitions into deployment-ready configuration files while maintaining complete separation from live network changes.

The optional, yet recommended, validation phase provides essential quality assurance before any live deployment occurs. This phase acts as a safety gate, ensuring your configurations meet technical and organizational standards.

Validation Types:

Syntax Validation

• Verifies YAML formatting and structure
• Catches basic configuration errors early
• Ensures template rendering produced valid output

Semantic Validation

• Confirms logical consistency of configurations
• Validates relationships between network components
• Checks for conflicting or incompatible settings

Policy Compliance

• Enforces organizational configuration standards
• Validates against security and governance requirements
• Ensures consistency with enterprise policies

The final phase transforms validated configurations into live network infrastructure through controlled deployment processes.

Deployment Planning:

# Return to project root for deployment operations
cd ..
terraform init
terraform plan

At this point, terraform plan will be performed. At this time, the following actions will be taken:

• State comparison between current and desired configurations
• Change preview showing exactly what will be modified
• The above information can serve for impact assessment for maintenance planning and risk management

The output of the plan will be printed ending with something similar to:

Plan: 64 to add, 0 to change, 0 to destroy.

This means that 64 resources will be added, 0 changed, and 0 destroyed. This output will vary from deployment to deployment, depending on the size of the network and features deployed.

This is the point in time when the appropriate approvals may be required. Custom integration with ITSM and ChatOps is available as a Cisco Service as Code subscription.

Configuration Application:

terraform apply

Application Process:

• Configurations push to Meraki Dashboard via API
• Networks, devices, and policies deploy according to template definitions
• CVD-aligned standards ensure consistent, best-practice implementations

After successful deployment, it is possible to enable ongoing operational excellence through integrated testing and monitoring capabilities. Using testing tools provides more information about this, but in summary, at this step integration with continuous post-change configuration validation may be performed.

This enables:

• Network connectivity testing verifies successful deployment
• Security policy validation confirms proper policy implementation
• Performance baseline establishment creates operational benchmarks

By understanding these deployment flow concepts, you can effectively leverage Branch as Code to achieve reliable, repeatable, and automated branch network deployments that consistently follow Cisco best practices.