CircleCI Fundamentals

Analogy categoryAnalogies

CircleCI is a cloud-hosted (and self-hosted, via server) CI/CD platform that connects to a Git provider and executes pipelines defined in .circleci/config.yml. Unlike some competitors that infer structure from folder conventions, CircleCI's configuration is explicit: you define reusable job blocks, then compose them into one or more workflows that describe execution order, fan-out/fan-in, and approval gates. Its defining strengths historically include fast Docker layer caching, first-class support for matrix builds across language versions, and a marketplace of shareable configuration packages called orbs.

🏏

Cricket analogy: Like a franchise that doesn't rely on players just knowing their roles by tradition, CircleCI wants every fielding position spelled out explicitly in the team sheet — who bowls when, who's on drinks duty — and its .circleci/config.yml is that written-out game plan rather than assumed convention.

Jobs, Executors, and Steps

A job is the smallest independently schedulable unit of work; it runs on an executor, which is the environment type — docker, machine (a full VM), macos, or windows. Inside a job, steps is an ordered list of commands, and CircleCI ships built-in steps like checkout, run, save_cache, restore_cache, and store_artifacts that handle common needs without hand-rolled shell scripting.

🏏

Cricket analogy: A job is like a single over bowled by one bowler on one pitch (the executor — turf, indoor nets, or a different ground entirely), and the steps within it are the ordered sequence of deliveries, with built-in routines like "check the run-up mark" or "collect the ball" standing in for checkout and store_artifacts.

yaml

version: 2.1

orbs:
  node: circleci/node@5.2.0

jobs:
  build-and-test:
    docker:
      - image: cimg/node:20.11
    steps:
      - checkout
      - node/install-packages:
          cache-version: v1
      - run:
          name: Run unit tests
          command: npm run test -- --ci --coverage
      - store_test_results:
          path: test-results
      - store_artifacts:
          path: coverage

workflows:
  build-test-deploy:
    jobs:
      - build-and-test
      - hold-for-approval:
          type: approval
          requires:
            - build-and-test
          filters:
            branches:
              only: main

Orbs: Shareable Configuration

Orbs are reusable, versioned packages of CircleCI configuration — jobs, commands, and executors — published to a public or private registry. Rather than hand-writing the same Node.js dependency-caching logic in every repository, a team pulls in circleci/node@5.2.0 and calls its pre-built commands. Orbs reduce boilerplate dramatically but also introduce a supply-chain consideration: pinning orb versions and auditing third-party orbs matters just as much as pinning any other dependency.

🏏

Cricket analogy: Orbs are like buying a pre-packaged fielding drill set from a certified coaching academy instead of designing your own from scratch every season, but just as you'd check which academy and edition of the drill pack you're using, teams must pin the exact orb version and vet unfamiliar third-party publishers.

Workflows and Fan-Out

A workflow orchestrates jobs, expressing dependencies with requires, so independent jobs (like linting and unit tests) can fan out and run concurrently, then fan back in before a shared deployment job. Workflows also support scheduled triggers, manual approval gates (as shown above with type: approval), and branch/tag filtering, making complex release processes — like requiring a human sign-off before a production deploy — expressible natively rather than through external tooling.

🏏

Cricket analogy: A workflow is like a match-day schedule where the fielding-practice group and the batting-nets group train concurrently on separate pitches, then both report back together before the shared team-selection meeting, which itself needs the captain's manual sign-off before it's finalized — like a type: approval gate.

CircleCI's machine executor boots a full virtual machine rather than a container, which is the right choice when a job itself needs to build or run Docker containers (Docker-in-Docker), since nested containers-in-containers add complexity and lose performance.

CircleCI pipelines are defined explicitly in .circleci/config.yml using version: 2.1 syntax.
Jobs run on an executor type: docker, machine, macos, or windows.
Orbs are versioned, shareable packages of jobs/commands/executors that reduce config duplication.
Workflows compose jobs with requires to control ordering, fan-out, and fan-in.
Approval-type jobs let a workflow pause for manual sign-off before proceeding, e.g. before production deploys.
Built-in steps like checkout, save_cache, and store_artifacts cover common pipeline needs without custom scripting.

Practice what you learned

1. Where does CircleCI expect pipeline configuration to live in a repository?

2. Which executor type should be used when a job needs to build and run its own Docker containers (Docker-in-Docker)?

3. What is an orb in CircleCI?

4. In a CircleCI workflow, what keyword expresses that one job must complete before another starts?

5. What does a job with `type: approval` do inside a workflow?

Was this page helpful?

GitLab CI Basics

Azure Pipelines Overview

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#YAML#CICDToolsPipelinesStudyNotes#DevOps#CircleCIFundamentals#CircleCI#Fundamentals#Jobs#Executors#StudyNotes#SkillVeris

CircleCI Fundamentals