CI/CD for Infrastructure and Infrastructure as Code

What it is

Infrastructure as code, or IaC, means describing servers, networks and their settings in files that are stored, reviewed and applied like software.

A CI/CD pipeline for infrastructure then tests those files and applies them to the network automatically. Together they bring software discipline to network operations.

The aim is changes that are repeatable, reviewed, tested and easy to roll back.

How it works

The files in Git describe the desired state, and the pipeline moves that state to the network.

Principles of infrastructure as code

• Source of truth. Desired configuration lives in version control, not in anyone's memory or on the devices alone.
• Declarative description. You state the end result, and the tool works out the steps.
• Idempotence. Running the same code twice gives the same result. The second run changes nothing.
• Repeatability. The same code builds the same environment every time, in a lab or in production.
• Version control and review. Every change has an author, a reason and a reviewer, and you can see the history.
• Automation over manual work. People change the code, and machines apply it.
• Immutability, where possible. Replace a component with a fresh one instead of patching it by hand.

Declarative and imperative

Many tools mix the two. An Ansible task is written as a step, but most modules check the current state and change only what differs.

Configuration drift

Drift happens when a device's real configuration no longer matches the code, usually after a manual change. IaC reduces it. The pipeline can compare the device to the source of truth and report or correct the difference.

Templates and variables

IaC separates the pattern from the data. A template holds the pattern, and a variables file holds the values for each device or site.

# vars.yaml
vlans:
  - id: 110
    name: CAMERAS
  - id: 120
    name: PRINTERS

The same template with different variables builds the configuration for each site.

CI/CD pipeline components

A small pipeline file might look like this.

stages:
  - validate
  - test
  - deploy

lint:
  stage: validate
  script:
    - yamllint .

lab_test:
  stage: test
  script:
    - ansible-playbook -i lab_inventory site.yml --check

deploy_prod:
  stage: deploy
  script:
    - ansible-playbook -i prod_inventory site.yml
  when: manual

The --check option runs a playbook in dry run mode, so Ansible reports what it would change. The when: manual line makes the production step wait for a person.

Benefits

• Speed. Changes that took days can take minutes.
• Consistency. Every device gets the same treatment.
• Fewer errors. Automated tests catch mistakes before production.
• Audit trail. Git records who changed what and why.
• Easy rollback. Revert the commit and run the pipeline again.
• Collaboration. Teams review changes through merge requests.

Challenges

IaC needs new skills, careful secret handling and good tests. A pipeline can also push a wrong change very quickly, so approvals and staged rollouts matter.