CI/CD Pipelines
# CI/CD Pipelines
A feature gets written, merged, tested, stored, and shipped — automatically, every time the code base changes. No more waiting years between versions. This lesson walks the pipeline stage by stage.
Explain concepts related to continuous integration/continuous deployment (CI/CD) pipelines. Expect the exam to test whether you can tell automation apart from orchestration, name the CI/CD workflow tasks in order, and recognize an artifact, a repository type, or a secure-code practice from a scenario.
What you'll cover
Click one off as you go — this only lives in your browser tab.
- Trace a change through a full CI/CD pipeline, from commit to deployment.
- Distinguish automation from orchestration.
- Identify artifacts, repository types, and secure code practices.
Continuous Integration / Continuous Deployment
Older software shipped in major versions, often years apart, with a steep learning curve every time. CI/CD replaces that: a developer adds a feature, it's integrated into the existing code base, the new version builds automatically, automated tests confirm nothing broke, and the result is delivered to a repository — ready to deploy. The cycle repeats every time the code base changes.
"Delivery" or "deployment"?
Sources use the "CD" differently. Both are correct — they mark two different points on the same pipeline.
Automation practices
Automation refers to a single task set to run on its own — not a series of tasks. A few kinds of sysadmin work are natural candidates.
Troubleshooting automation
When an automated task fails, the cause usually falls into one of four buckets. Click one to see what to check.
- Managed node's OS or application version is incorrect
- Configuration management tool version is incorrect
- Configuration files provided don't match the deployment tool
- Configuration management is trying to use an OS feature that no longer exists
- ...or an application feature that no longer exists
- Older configuration files still contain deprecated settings
- Confirm automation tasks actually began successfully
- Check the automation software's logs
- Check system logs
- Find which step was the last one to complete successfully
- SSH key identities don't match (the user tied to the key changed)
- SSH keys changed — local private key no longer matches remote public key
- Service account isn't mapped correctly
Orchestration practices
"Automation" and "orchestration" aren't always used accurately, even though both are common across CI/CD, DevOps, and cloud administration. Automation sets a single task to run on its own. Orchestration configures a series of automated tasks to run together as one workflow. Same six-step web server deployment, run two different ways:
Sequencing matters — the OS must be installed before the web service is configured. A good orchestration workflow has the management tool confirm each step actually succeeded (e.g., that the instance exists) before starting the next one.
Workflow tasks
A CI/CD workflow splits into two halves. Under Continuous Integration: development, code merges, and testing happen, and the result lands in a repository. Under Continuous Deployment: code ships to targeted systems — on demand, or automatically as scaling and utilization require.
Troubleshooting orchestration
Deployment artifacts
An artifact is whatever the CI/CD workflow produces — code that's built and ready for production use. Click a type to see what it is.
Linux package managers
Often the step right after an orchestration workflow finishes deploying the VM itself — installing, updating, inventorying, and removing software from approved repositories. Mostly distribution-specific:
| Package manager | Command | Used on |
|---|---|---|
| Red Hat Package Manager | rpm | RHEL, Fedora, CentOS |
| Debian Package Manager | deb | Ubuntu, Mint, Debian |
| Yellowdog Updater Modified | yum | RHEL, Fedora, CentOS |
| Dandified YUM | dnf | RHEL, Fedora, CentOS |
Code repositories
Repositories are more than storage — they're the endpoint that gives CI/CD and IaC work their repeatability, consistency, version control, and drift prevention. Services authenticate to them too, not just developers, and many integrate actions that handle merging, approvals, and vulnerability scans automatically. They can also hold configuration files, VM and container image files, documentation, and other process artifacts.
- Open to anyone
- Fits open-source software or files you deliberately want on the internet
- Good for config templates, sample files, learning tools
- Access control — only authorized collaborators can use the resources
- Self-hosted internally, or hosted on sites like GitHub or DigitalOcean
- Hosted options remove the hardware burden, at the cost of less control over where data lives
Secure code management
Configuration files and scripts — Ansible, Puppet, Bash, PowerShell — aren't encrypted and are easy to read or modify. How you handle credentials and access inside them is a real security question, not an afterthought.
Click a practice to see why it matters.
Rapid, consistent deployment of instances, containers, and applications doesn't happen by accident.
It's made possible by Infrastructure as Code and DevOps practices — chiefly CI/CD.
This lesson covers the automation tools, version control mechanisms, and scripting practices behind that pipeline.