CI/CD Roadmap: What to Learn and What to Skip

Why CI/CD comes after Docker

By now you can build an image and run it on a server, but you do it by hand. Each manual run is a chance to skip a test or ship the wrong version. CI/CD (continuous integration and continuous delivery) turns those commands into steps that run the same way each time.

The order matters. A pipeline is only your own commands, written down. If you cannot build the image by hand, you cannot tell a broken pipeline from a broken Dockerfile.

It is also common in job posts. InterviewStack's June 2026 count of 7,523 DevOps Engineer postings found CI/CD in 67% of them. That figure comes from one job board that also sells interview prep, so treat it as a rough signal.

What to learn, in order

1. Workflows, jobs and steps. A workflow is a YAML file in .github/workflows/. Learn how GitHub Actions triggers one, because every later item is a change to this file.
2. Run tests on each pull request. Trigger on pull_request and run your linter (a tool that checks code style and simple errors) and tests. This gives you value on day one and no deploy can break anything yet.
3. Block bad merges. Turn on branch protection for main and require the test job. Without this, a red test is only a suggestion. On GitHub Free, this works on public repos only.
4. Build and push an image. On a push to main, build the image and push it to a registry (a store for images). GitHub has one. Tag it with the commit SHA (the unique ID of a commit), so you always know what code is running.
5. Secrets. Store the deploy key in GitHub Actions secrets, not in a file. Run the deploy only on main, never on pull_request, so that unreviewed code does not get near it.
6. Deploy to your server. Make a separate SSH key used only for deploys. Have the job log in, pull the new tag and restart the app. Runners are the machines that run your jobs. GitHub's do not use one fixed address, so you cannot easily limit SSH to them. Keep password login off, as you did at step 1.
7. Roll back. Deploying an older SHA tag should be one small action. Practice it now, while nothing is on fire.
8. Speed it up with caching. Cache dependencies and image layers once the pipeline works. A pipeline that takes 2 minutes gets used. One that takes 40 gets skipped.

What to skip for now

• Jenkins, GitLab CI and other tools. Comparing them teaches you little before you have built one pipeline.
• Self-hosted runners and writing your own custom actions.
• Blue-green and canary deploys (ways to shift users to a new version slowly). Learn what the words mean, then come back after Kubernetes.
• Long-lived cloud keys. There are no cloud keys yet, and you will replace that pattern with OIDC later.

Common mistakes

• Tagging every image latest. You then cannot tell what is running, and you have nothing clear to roll back to. Use the commit SHA.
• Adding retries to hide a flaky test. A flaky test is one that passes and fails with no code change. Retries teach the team to ignore red builds. Find the cause, such as test order, timing or a shared database.
• Using an action from a stranger's repo without checking it. That code runs with access to your secrets. GitHub's security guidance explains why to pin an action to a full commit SHA.
• Rolling back code but not the database. An old version may not work with a new table layout. Make database changes that both versions can run with.

Your project

Build the full pipeline for the app you have carried since step 5. Then open a pull request with a test that fails on purpose and take a screenshot of the blocked merge. Fix it, merge, and watch the app update with no help from you. Finally, ship a broken version and roll it back. Note the time it took in your README, because you will want that story when you talk about this project later.