Lab Overview

Introduction

Welcome to GitOps for NetEng: The Hero Journey. In this lab, you will build a local-first GitOps workflow step by step and see how Git becomes the source of truth for network changes. Along the way, you will create router configuration files, review changes with Git, validate those changes with automation, package deployment artifacts, and then extend the hosted pipeline so it starts and updates an existing Cisco Modeling Labs (CML) lab.

This lab is intentionally Git-heavy because Git is not just a tool you will use once during the exercise. It is the foundation that connects every part of the workflow. As you move through the tasks, you will repeat the core Git commands often enough that they begin to feel natural and predictable.

By the end of the lab, you will have more than a set of notes or isolated examples. You will have a working project that shows how Git, automation, and CML fit together in a practical NetDevOps workflow.

Learning Objectives

By the end of this lab, you will be able to:

Create and manage a Git repository for network automation work.
Use git status, git diff, git add, git commit, git push, git fetch, and git pull with confidence.
Organize a repository for configuration files, topology files, and automation scripts.
Run a local validation and packaging workflow for network configuration changes.
Extend a GitHub Actions workflow with a deployment job that updates node configurations in an existing CML lab through the API and then starts the lab.
Explain how Git supports a GitOps operating model for network engineering.

Scenario

Imagine you are part of a network engineering team that wants to improve how changes are tracked and tested. Today, router updates are often copied into terminals by hand, notes are scattered across laptops, and it is not always clear what changed or why. That makes reviews harder, troubleshooting slower, and repeatability weaker than it should be.

Your team wants a better workflow, one that starts with Git and treats the repository as the place where intended network state is stored and reviewed. They also want the workflow to be simple enough to run from a local workstation so engineers can learn it, test it, and demonstrate it without depending on a large shared platform.

In this lab, you will build that workflow yourself.

What You Will Build

As you move through the lab, you will create:

A Git-managed configs/ directory that stores router configurations.
A topology.yaml file that documents the intended three-router CML topology.
Local scripts for validation and packaging.
A repeatable workflow that begins with a Git change and ends with an updated CML lab.

Workflow Diagram

flowchart LR
    A[Edit router config] --> B[git status]
    B --> C[git diff]
    C --> D[git add]
    D --> E[git commit]
    E --> F[Run local validation]
    F --> G[Package artifacts]
    G --> H[Hosted validate and package pipeline]
    H --> I[Start existing CML lab]
    I --> J[Update existing CML lab]

This workflow shows the path you will practice throughout the lab. Each stage builds on the one before it. First, you make a change and inspect it in Git. Next, you validate and package it locally. Then you recreate those stages in GitHub Actions and extend the workflow so the router configurations stored in the repository are applied to the existing lab environment through the CML API.

Lab Requirements

Before you begin, make sure you have access to the following:

A local workstation running macOS, Linux, or Windows with a Bash-compatible shell.
Git installed and configured with your name and email.
tar and jq available in your shell.
Access to a GitHub repository where GitHub Actions can run.
Access to an existing CML lab and valid credentials stored as GitHub repository secrets.
Internet access for cloning repositories or publishing to GitHub if your environment requires it.

These tools give you everything needed to complete the lab from a single machine.

Suggested Repository Layout

The project you build will follow a structure like this:

gitops-neteng-lab/
├── .github/
│   └── workflows/
│       └── gitops-pipeline.yml
├── configs/
│   ├── router1.cfg
│   ├── router2.cfg
│   └── router3.cfg
├── scripts/
│   ├── validate_configs.sh
│   ├── package_artifacts.sh
├── topology.yaml
└── README.md

Seeing the layout before you start makes it easier to understand how the pieces fit together. The configuration files describe the desired router state, the scripts automate validation and packaging, and the topology file documents the intended design that the existing CML lab is expected to match.

Estimated Time

Plan for 75 to 90 minutes to complete the full lab.

Phase	Focus	Estimated Time
1	Repository setup and Git foundation	15 minutes
2	Configuration changes and repeated Git workflow	20 minutes
3	Local validation and packaging	15 minutes
4	Hosted CI validation and packaging	15 minutes
5	Hosted CML deployment update	15 to 20 minutes

If you spend extra time reviewing diffs, reading the scripts closely, or exploring the Git history, the lab may take a little longer. That is time well spent because those activities build the habits that make GitOps reliable.

Disclaimer

This lab is designed for learning and proof-of-concept use. The configurations, scripts, and workflow patterns are intentionally simple so you can understand what each part is doing and complete the exercise in a reasonable amount of time.

The Git, API, JSON, CI/CD, and network automation concepts practiced here can help prepare you for the automation and programmability topics associated with CCNA Automation certification study. This lab is not a complete certification course or exam guarantee, but it gives you hands-on practice with the kinds of workflows and vocabulary that make those topics more concrete.

Before adapting any part of this lab to a shared or production environment, review the scripts carefully and make sure credentials, validation logic, and deployment methods match your operational requirements.

Do not store real production credentials in Git. Use environment variables, local secret stores, or another secure method for handling sensitive information.

Success Criteria

You have completed the lab successfully when you can:

Show Git history for multiple configuration updates.
Run local validation and packaging scripts without errors.
Trigger a hosted workflow that validates and packages the repository content.
Extend that workflow so it updates node configurations in an existing CML lab by API and then starts the lab.
Explain how the router configurations from configs/ are mapped to the existing nodes in CML during deployment.
Explain how the repository, artifact, and CI/CD workflow work together during deployment.
Explain how each stage supports a GitOps workflow.

These outcomes matter because they show that you understand both the mechanics of the workflow and the reason each stage exists.

Task Sequence

Work through the lab in this order:

Each task builds on the previous one, so working in order will give you the clearest learning path.

Stretch Assignments

If you finish early, try one or more of these extensions:

Add a branch and pull request workflow for peer review.
Use git restore to discard an intentional local change, then use git restore --staged to unstage a file without deleting the edit.
Practice git stash by saving unfinished work, switching context, and then applying the stashed change again.
Create and resolve a small merge conflict in a throwaway branch so you can practice Git conflict handling safely.
Expand validation rules to check interface descriptions, IP addressing, or policy consistency.
Extend the hosted deployment workflow to include post-deploy verification or reporting.
Add rollback logic that can redeploy the last known good artifact.
Expand the topology to include a fourth router or a simulated Internet edge.

These challenges are a good way to keep practicing after the core lab is complete.

Lab Survey

After you complete the lab, please take a few minutes to complete the survey. Your feedback helps the lab team understand how well the lab performed, whether the content was valuable, and whether the material was understandable enough to help you learn the concepts.