Modern data centers are becoming increasingly software-driven. Network engineers are no longer limited to configuring individual switches through the CLI; instead, infrastructure can be represented as code, stored in version-control systems, tested automatically, and deployed through controlled pipelines.
This is where NetDevOps and CI/CD pipelines become highly relevant to Cisco ACI environments.
Cisco ACI already provides a policy-driven and API-based approach to data center networking through APIC. By combining these capabilities with Git, automation tools, testing frameworks, and CI/CD platforms, network teams can create a repeatable process for moving an ACI configuration change from development to production.
The objective is simple:
Design → Commit → Validate → Test → Approve → Deploy → Verify
The source material describes the same fundamental CI/CD idea: configuration changes are stored in a repository, validated through automated stages, and eventually deployed instead of being applied directly to the production network.
What Is NetDevOps?
NetDevOps applies DevOps principles to network engineering.
Traditional network operations often look like this:
Requirement → Engineer logs in → CLI/API change → Verification
Although this approach can work, it becomes difficult to maintain consistency when hundreds or thousands of configuration changes are performed across a large environment.
A NetDevOps approach introduces:
- Version control
- Automation
- Automated testing
- Peer review
- Repeatable deployments
- Change tracking
- Rollback capability
- Continuous validation
For Cisco ACI, this means that objects such as:
- Tenants
- VRFs
- Bridge Domains
- Application Profiles
- EPGs
- Contracts
- Filters
- L3Outs
- Interface policies
- Access policies
can be managed through an automated and controlled workflow.
Why Use CI/CD for Cisco ACI?
Cisco ACI is already designed around centralized policy management. However, manually creating and modifying policies through the APIC GUI or CLI can still introduce operational risks.
A CI/CD workflow adds another layer of control around those changes.
1. Version Control
ACI configuration definitions can be maintained in Git.
This provides a history of:
- Who changed the configuration
- What was changed
- When it was changed
- Which version was deployed
This becomes particularly useful during troubleshooting or rollback.
2. Automated Validation
Before a change reaches production, the pipeline can validate:
- Configuration syntax
- Required parameters
- Naming standards
- IP addressing
- Policy dependencies
- Configuration structure
- Organizational standards
3. Automated Testing
The configuration can be deployed to a test or non-production environment before production deployment.
For example, a pipeline could verify:
Tenant → VRF → BD → EPG → Contract → Connectivity
4. Controlled Production Deployment
Only changes that successfully pass the required validation and approval stages should be promoted to the production ACI fabric.
5. Better Auditability
Every pipeline execution can provide an audit trail showing:
Commit → Test Result → Approval → Deployment → Verification
This is significantly easier to review than a collection of manually executed CLI commands.
Understanding the CI/CD Pipeline for Cisco ACI
A typical ACI CI/CD pipeline can be divided into five major stages:
Source → Build → Test → Deploy → Verify
For Cisco ACI, we can extend this model by adding explicit validation and post-deployment verification.
Stage 1: Source Repository
The process starts when a network engineer creates or modifies an ACI configuration definition.
Instead of immediately changing APIC, the configuration is stored in a source-control repository.
For example:
ACI-Configuration/
│
├── tenants/
│ ├── tenant-web.yaml
│ └── tenant-app.yaml
│
├── vrfs/
│ └── vrf-production.yaml
│
├── bridge-domains/
│ └── bd-web.yaml
│
├── epgs/
│ └── epg-web.yaml
│
└── contracts/
└── contract-web-to-app.yamlA network engineer can create a feature branch, make the required change, and submit it for review.
For example:
main
|
+---- feature/new-web-epg
|
+---- configuration change
|
+---- validation
|
+---- pull requestThis creates a much more controlled change-management process.
Stage 2: Build and Configuration Validation
Once a change is committed, the CI/CD pipeline can automatically start.
The build stage does not necessarily mean compiling software as it would in application development.
For network automation, the build stage can mean:
- Loading configuration files
- Validating YAML or JSON
- Checking required fields
- Validating configuration structure
- Checking dependencies
- Running policy checks
- Preparing the deployment package
For example, a pipeline could detect:
Tenant: PROD
VRF: PROD_VRF
BD: WEB_BD
Subnet: 10.10.10.0/24
Gateway: 10.10.10.1and verify that the values comply with the organization's standards.
A failed validation should stop the pipeline before the configuration reaches the ACI fabric.
Stage 3: Test the ACI Configuration
Testing is one of the most important parts of the pipeline.
The objective is not simply to determine whether the configuration can be pushed to APIC.
The more important question is:
Does the configuration produce the expected network behavior?
Depending on the environment, automated tests could verify:
Tenant Validation
Is the expected tenant present?
VRF Validation
Does the correct VRF exist?
Bridge Domain Validation
Is the BD associated with the correct VRF?
EPG Validation
Is the EPG associated with the expected BD?
Contract Validation
Are the expected contracts and filters configured?
Connectivity Validation
Can the required endpoints communicate?
Policy Validation
Does the resulting configuration comply with the organization's security and network policies?
The source document similarly describes using a non-production testing environment to validate network configuration before production deployment.
Stage 4: Approval and Production Deployment
After successful testing, the change can move toward production.
There are several possible deployment models.
Manual Approval
The pipeline pauses and asks an engineer to approve the production change.
Test Passed
↓
Change Review
↓
Engineer Approval
↓
Production DeploymentThis is often a good starting point for production ACI environments.
Automated Promotion
More mature environments can automatically promote a change when all required checks pass.
Commit
↓
Build
↓
Test
↓
Security Check
↓
Approval Policy
↓
ProductionFor production ACI, I recommend beginning with human approval and gradually introducing controlled automation.
Stage 5: Deploy to Cisco ACI
The pipeline can communicate with APIC using appropriate automation interfaces.
Possible approaches include:
- APIC REST API
- Python-based automation
- ACI SDK/tooling
- Ansible
- Terraform where appropriate
- Custom automation scripts
A simplified workflow could look like:
Git Repository
↓
CI/CD Server
↓
Validation
↓
Automation Engine
↓
Cisco APIC
↓
ACI Leaf/Spine FabricThe key advantage is that the engineer does not need to manually repeat the same configuration process for every deployment.
Stage 6: Post-Deployment Verification
Deployment should not be considered the end of the pipeline.
A good network CI/CD pipeline should verify that the intended state actually exists after deployment.
For example:
Deploy
↓
Check APIC Response
↓
Check Object State
↓
Check ACI Faults
↓
Check EPG/Contract State
↓
Check Connectivity
↓
Success / RollbackThis is especially important in ACI because a configuration can be accepted by the controller while the resulting operational state still requires validation.
A Practical Cisco ACI CI/CD Example
Imagine an application team requests a new application environment.
The requirement is:
Application: Customer-App
Tenant: PROD
VRF: PROD-VRF
BD: CUSTOMER-BD
EPG: CUSTOMER-APP
Contract: APP-TO-DBInstead of manually creating every object through APIC, the engineer creates the desired configuration in the repository.
The pipeline then performs the following:
Step 1 — Commit
The engineer commits the configuration.
Step 2 — Build
The pipeline checks the configuration structure.
Step 3 — Validate
It checks naming conventions, required fields, and dependencies.
Step 4 — Test
The configuration is tested against an ACI test environment or appropriate validation framework.
Step 5 — Review
A network engineer reviews the proposed change.
Step 6 — Deploy
The approved configuration is pushed through the automation layer to APIC.
Step 7 — Verify
The pipeline checks:
- Tenant
- VRF
- BD
- EPG
- Contract
- Faults
- Connectivity
Step 8 — Record
The pipeline records the deployment result.
This creates a repeatable workflow instead of a one-time manual change.
Tools Commonly Used in Network CI/CD
For Cisco ACI environments, these tools can be mapped into a broader workflow.
| Function | Example Tools |
|---|---|
| Source Control | Git, GitLab, GitHub |
| Pipeline | GitLab CI/CD, Jenkins, GitHub Actions |
| Automation | Ansible, Python, Terraform |
| ACI Interface | APIC REST API, ACI SDK/tooling |
| Testing | pyATS, custom API tests |
| Lab/Simulation | Cisco Modeling Labs |
| Monitoring | Existing enterprise monitoring platforms |
| Configuration Format | YAML, JSON |
| Review | Git Pull/Merge Requests |
The exact combination depends on the organization's architecture and automation standards.
Git and Cisco ACI: Why Version Control Matters
One of the biggest changes when moving from traditional networking to NetDevOps is treating configuration as a managed artifact.
Consider a manual change:
Engineer → APIC → Configuration ChangeLater someone asks:
"What exactly changed last Tuesday?"
The answer may require searching audit logs and controller history.
With Git:
Engineer
↓
Git Commit
↓
Review
↓
Pipeline
↓
APICThe configuration change becomes part of a structured history.
This makes troubleshooting and rollback easier.
CI/CD Does Not Mean "Push Everything Automatically"
This is an important point for network engineers.
CI/CD does not mean that every configuration change should automatically reach production.
A mature network pipeline should include appropriate controls.
For example:
Developer
↓
Git Commit
↓
Automated Validation
↓
Automated Testing
↓
Security / Compliance Check
↓
Peer Review
↓
Human Approval
↓
Production
↓
VerificationThe amount of automation can increase as confidence in the pipeline increases.
What Happens When a Test Fails?
A good pipeline should stop.
For example:
Git Commit
↓
Build
↓
Validation
↓
Test
↓
❌ FAILED
↓
Stop Pipeline
↓
Notify EngineerThe engineer can correct the configuration and submit another change.
This is much safer than discovering the problem after deployment to the production fabric.
Rollback Strategy for Cisco ACI
Rollback should be considered before automation is introduced.
A version-controlled workflow makes it easier to identify the previous known-good configuration.
A simplified process is:
Current Version
↓
New Configuration
↓
Deployment
↓
Verification
↓
Failure?
↙ ↘
Yes No
↓ ↓
Rollback ContinueThe exact rollback mechanism should be designed carefully according to the ACI objects involved and the organization's change-management procedures.
Benefits of CI/CD for Cisco ACI Engineers
Faster Changes
Repeated configuration tasks can be automated.
Fewer Manual Errors
Automated validation reduces common configuration mistakes.
Consistency
The same process can be applied repeatedly.
Better Collaboration
Network and application teams can work with a common version-control workflow.
Easier Auditing
Configuration changes are associated with commits, reviews, pipeline results, and deployment records.
Safer Production Changes
Changes can be validated before reaching the production fabric.
Repeatability
The same desired configuration can be deployed consistently across environments where appropriate.
Challenges You Should Consider
CI/CD is powerful, but it is not a magic solution.
1. Poorly Designed Automation
Automating a bad process simply makes the bad process faster.
2. Insufficient Testing
If tests do not represent real network behavior, a successful pipeline does not guarantee a successful production deployment.
3. Secrets Management
API credentials, tokens, and other sensitive information must be handled securely.
4. Pipeline Permissions
The automation account should have only the permissions required for its task.
5. Production Safety
High-impact changes should have appropriate approvals and safeguards.
6. Lack of Rollback Planning
Every production deployment should have a defined recovery strategy.
ACI CI/CD Maturity Model
A network team does not have to automate everything on day one.
A practical progression is:
Level 1 — Version Control
Store ACI configurations in Git.
Level 2 — Automated Validation
Validate every configuration change.
Level 3 — Automated Testing
Test changes against a non-production environment.
Level 4 — Controlled Deployment
Deploy approved changes automatically.
Level 5 — Continuous Verification
Automatically verify the resulting network state.
Level 6 — Advanced Network Automation
Introduce more sophisticated orchestration, compliance, and intent-based workflows.
This gradual approach allows network engineers to build confidence without immediately handing complete production control to an automation pipeline.
NetDevOps Changes the Role of the Network Engineer
CI/CD does not eliminate the need for network engineers.
Instead, it changes where their time is spent.
Traditional model:
Configure
Troubleshoot
RepeatModern model:
Design
↓
Define Desired State
↓
Automate
↓
Test
↓
Deploy
↓
Observe
↓
ImproveNetwork engineers therefore benefit from learning skills beyond traditional CLI configuration.
Some particularly valuable skills include:
- Git
- Python
- REST APIs
- YAML/JSON
- Ansible
- Terraform
- CI/CD concepts
- Automated testing
- Infrastructure as Code
- Network programmability
For Cisco ACI engineers, this combination can be especially powerful because ACI already provides a centralized controller and programmable interfaces.
Summary
Final Thoughts
Cisco ACI provides a strong foundation for policy-driven and automated data center networking. CI/CD and NetDevOps can extend that foundation by introducing version control, automated validation, testing, controlled deployment, and continuous verification.
The biggest mindset change is to stop thinking of a network change as simply:
"A command I need to execute."
Instead, think of it as:
"A configuration change that should pass through a controlled lifecycle."
A mature Cisco ACI CI/CD workflow can therefore look like:
Design → Git → Validate → Test → Review → Deploy → Verify → Monitor
The goal is not to automate every possible task.
The goal is to make network changes repeatable, testable, auditable, and safer.
For network engineers who already work with Cisco ACI, learning CI/CD and NetDevOps is a natural next step toward modern network automation.
Related Articles from Netterrene
Cisco ACI Explained: Concepts, Learning Prerequisites, Benefits, and Limitations
Read the Cisco ACI fundamentals guide
AI Planning Strategies for Cisco ACI Engineers
Read the ACI AI planning guide
How AI Agents Actually "Touch" Your Cisco ACI Fabric
Read the ACI automation and API guide
How AI Memory Can Revolutionize Cisco ACI Operations
Read the ACI AI memory guide
Multi-Agent AI Systems Explained for Cisco ACI Engineers
Read the ACI multi-agent guide
Networklearner – Cisco ACI, Network Automation and AI Articles
Visit Netterrene
Need Help With Cisco ACI or Network Automation?
Need help with Cisco ACI, Nexus, data center networking, or network automation?
I am a CCIE Data Center engineer with 18+ years of enterprise networking experience.
Contact me for consulting, troubleshooting, design reviews, and project support free of cost.
