CircleCI comparison in Jenkins - Step-by-Step Execution

Process Flow - CircleCI comparison

Start: Code pushed to repo

↓

Trigger CI pipeline

↓

Build, Test, Deploy steps

↓

Feedback: Success or Fail

↓

End

Shows the flow of code triggering a CircleCI pipeline, running build/test/deploy steps, and giving feedback.

Execution Sample

Jenkins

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { echo 'Building...' }
    }
  }
}

A simple Jenkins pipeline that echoes 'Building...' in the build stage.

Process Table

Step	Action	CircleCI Behavior	Jenkins Behavior	Result
1	Code pushed to repo	Triggers CircleCI pipeline automatically	Triggers Jenkins pipeline if webhook configured	Pipeline starts
2	Pipeline config read	Reads .circleci/config.yml	Reads Jenkinsfile in repo	Pipeline config loaded
3	Job execution	Runs jobs in containers or VMs, supports parallelism	Runs jobs on configured agents, parallelism possible but manual	Jobs start
4	Build step	Runs build commands as defined	Runs build commands as defined	Build runs
5	Test step	Runs tests, reports results	Runs tests, reports results	Tests run
6	Deploy step	Deploys if configured, supports workflows	Deploys if scripted, supports pipelines	Deploy runs
7	Feedback	Sends status to VCS, dashboard updates	Sends status to VCS, dashboard updates	User notified
8	Pipeline end	Pipeline finishes, resources released	Pipeline finishes, agents freed	Pipeline complete

💡 Pipeline completes after all configured steps run and feedback is sent.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
Pipeline Status	Not started	Config loaded	Build running	Deploy running	Complete
Jobs Running	0	0	1 (build)	1 (deploy)	0
Feedback Sent	No	No	No	No	Yes

Key Moments - 3 Insights

Why does CircleCI use a YAML file while Jenkins uses a Jenkinsfile?

CircleCI uses a YAML file (.circleci/config.yml) for pipeline config which is declarative and easy to read, while Jenkins uses a Jenkinsfile written in Groovy script, which is more flexible but requires scripting knowledge. See execution_table step 2.

How does parallel job execution differ between CircleCI and Jenkins?

CircleCI natively supports parallel jobs with simple config, running jobs in isolated containers or VMs. Jenkins can run parallel jobs but requires manual setup of agents and pipeline syntax. See execution_table step 3.

How is feedback delivered to developers in both tools?

Both CircleCI and Jenkins send build status back to the version control system and update their dashboards to notify users of success or failure. See execution_table step 7.

Visual Quiz - 3 Questions

Look at the execution table, at which step does CircleCI read its pipeline configuration?

A Step 1

B Step 4

C Step 2

D Step 7

💡 Hint

Check the 'Pipeline config read' row in the execution_table.

According to the variable tracker, what is the 'Pipeline Status' after Step 4?

A Build running

B Config loaded

C Not started

D Complete

💡 Hint

Look at the 'Pipeline Status' row under 'After Step 4' in variable_tracker.

If Jenkins did not have configured agents, how would the 'Jobs Running' variable change after Step 4?

A It would be 1 as usual

B It would remain 0 because no jobs can run

C It would be 2 because jobs queue up

D It would be -1 indicating error

💡 Hint

Consider the 'Jobs Running' variable and how Jenkins requires agents to run jobs.

Concept Snapshot

CircleCI uses a YAML config file (.circleci/config.yml) to define pipelines declaratively.
Jenkins uses a scripted Jenkinsfile for pipeline definition.
CircleCI runs jobs in containers with easy parallelism.
Jenkins requires manual agent setup for parallel jobs.
Both provide feedback to developers via VCS and dashboards.
CircleCI is cloud-friendly; Jenkins can be self-hosted or cloud.

Full Transcript

This visual execution compares CircleCI and Jenkins pipelines. When code is pushed, both trigger pipelines if configured. CircleCI reads its YAML config file, Jenkins reads the Jenkinsfile script. CircleCI runs jobs in containers with built-in parallelism; Jenkins runs jobs on agents which must be set up. Both run build, test, and deploy steps and send feedback to developers via version control and dashboards. The pipeline ends after all steps complete and feedback is sent. Key differences include config format, parallel job handling, and hosting options.