Congratulations — you now have a CI/CD pipeline that runs end to end, from pushing code all the way to going live in production, complete with an approval gate. In this closing article, we'll cover the things that tend to trip up beginners, how to debug efficiently, and where you can go to keep learning after this.
Common Beginner Mistakes
Committing credentials directly into code. This is the most fatal one. Once an API key gets committed to git history, even if you delete it in the very next commit, it's still sitting in the history and can be found. Always use Secrets, and if a credential has already leaked into a commit, revoke/rotate it immediately — don't just delete it from the code.
Flaky tests (sometimes pass, sometimes fail, with no code changes). Usually caused by tests that depend on execution order, timing, or state that isn't reset between tests. Flaky tests are dangerous, because over time teams get used to re-running the pipeline instead of investigating — and eventually trust in CI erodes entirely.
Pipelines that take too long, so people stop using them. If a pipeline takes 20 minutes to finish, people get impatient and start skipping it. Optimizations like caching dependencies (the cache: 'npm' we used) and running jobs in parallel aren't just about speed — they're about keeping the team's habit of actually using CI/CD.
No branch protection, so CI is just a formality. Already covered in the first hands-on article — if CI is red but people can still merge manually, most of the value of CI is lost.
Production and staging configurations that drift far apart. If staging and production differ in Node version, environment variables, or data structure, bugs that pass in staging can resurface in production. Try to keep them as close as possible (parity).
Too many manual steps that are "supposedly" automated. For example, still having a step that says "don't forget to manually update file X before deploying." Any recurring manual instruction like that is a strong candidate to be automated into the pipeline.
A Checklist for Debugging a Broken Pipeline
If your pipeline fails and you're not sure where to start, try this order:
Read the log from the failed step, not just the red status. Expand the step, find the specific error line.
Reproduce it locally first. Run the exact same commands (npm ci, npm test) on your local machine. If it fails locally too, it's a code bug, not a CI problem.
If it only fails in CI but is fine locally, suspect an environment difference — Node/runtime version, an environment variable that isn't set, or dependencies that differ because package-lock.json is out of sync.
Check the job/step order and needs. Make sure a job that depends on another job's output actually has that dependency correctly defined.
Check Secrets and permissions. Errors like "401 Unauthorized" or "permission denied" are usually caused by a wrong or expired secret, or one that hasn't been added to the right repo.
If it's a workflow syntax error (e.g. the .yml file doesn't run at all), use a YAML validator or your editor's GitHub Actions extension to check indentation and structure.
The most important habit: don't just re-run the pipeline hoping "it'll pass this time" without knowing why it failed. If that becomes a habit, it means you're already starting to lose trust in the signal CI is giving you — and that's the start of a much bigger problem.
What to Learn Next
This series deliberately focused on the fundamentals so you'd have a solid foundation. If you want to go deeper, here are some directions to explore:
Docker & containerization — packaging an app into a container so the environment is truly consistent from local all the way to production. Many modern production pipelines build a Docker image as part of the build job.
Multi-environment deployment — having a staging/dev environment separate from production, with a pipeline that deploys to staging automatically first, then to production after it's validated.
Pipeline notifications — integrating Slack/Discord/email so the team knows immediately when a pipeline fails, without having to check a dashboard manually.
Infrastructure as Code (IaC) — tools like Terraform for managing infrastructure (not just application code) through a pipeline as well.
Other CI/CD tools beyond GitHub Actions — if you later work somewhere that uses a different platform, the concepts (trigger, job, runner, artifact) stay exactly the same, only the syntax changes:
-
GitLab CI/CD — very similar, uses a
.gitlab-ci.yml file.
-
Jenkins — older, self-hosted, very flexible but more complex to set up.
-
CircleCI — also popular, conceptually similar to GitHub Actions.
The good news: since you already understand the core concepts from the pipeline anatomy article — trigger, job, step, runner, artifact — learning another CI/CD tool later is just a matter of adapting to new syntax, not starting from zero again.
Closing
We've come a long way — from "why CI/CD matters," through understanding pipeline anatomy, hands-on practice building a first CI pipeline, adding secrets and build artifacts, all the way to automatic production deployment with an approval gate. Most importantly, you now have a real, reusable pipeline template you can adapt for your own projects.
Thanks for following along with the CI/CD for Beginners series. Good luck applying it to your own projects!