Glossary — Speak the Language

The five friends may use factory words, but in job interviews and documentation people use these. This page has everything you need to talk about Jenkins with confidence: a quick-reference table, a set of interview-ready answers, and a Classic Interview Q&A section.

Quick Reference

Term	Factory meaning	Plain meaning
Jenkins	The assembly line controller	An open-source automation server for building, testing, and deploying software
Pipeline	The full assembly line	A sequence of stages that automate the CI/CD process, defined in a Jenkinsfile
Jenkinsfile	The assembly line recipe	A Groovy-based file committed to Git that defines the pipeline
Job (Project)	A single assembly line task	A configured task or pipeline in Jenkins
Stage	A station on the assembly line	A major phase of a pipeline (Build, Test, Deploy)
Step	An action at a station	An individual command within a stage
Agent	A workstation	A machine (or Docker container) that executes the pipeline
Node	A physical workstation	A machine in the Jenkins cluster that can run agents
Master/Controller	The factory manager	The Jenkins server that coordinates all jobs and agents
Executor	A worker at a station	A slot on an agent that can run one pipeline at a time
Workspace	The workbench	A directory on the agent where the pipeline runs
Trigger	The production schedule	What causes a pipeline to run (webhook, cron, manual)
Webhook	The instant order button	A push notification from Git that triggers a build immediately
SCM Polling	Checking for new orders periodically	Jenkins periodically checks Git for new commits
Build	A production run	One execution of a pipeline — with a unique build number
Build Number	The batch number	A unique, auto-incrementing number for each build
Artifact	The finished product	Files produced by a build (JARs, Docker images, reports)
Credential	The safe key	Stored secrets (passwords, tokens, keys) used by pipelines
Shared Library	Reusable factory jigs	A collection of reusable Groovy code shared across pipelines
Declarative Pipeline	The blueprint notation	The recommended pipeline syntax — structured, readable, validated
Scripted Pipeline	The freehand notation	The older, more flexible (but harder to read) pipeline syntax
Post	The quality report	Actions that run after the pipeline completes (success, failure, always)
Input	The inspector's signature	A manual approval gate before a stage proceeds
Parallel	Multiple workstations working simultaneously	Running independent stages at the same time
Branch	A different assembly line for a feature	A Git branch that gets its own pipeline run
Multi-Branch Pipeline	Auto-installed assembly lines	A job that automatically creates pipelines for all branches
Docker Agent	A fresh, disposable workstation	A Docker container used as the pipeline execution environment
Bounce	Restarting the factory	Restarting Jenkins or an agent to clear issues
Console Output	The factory log	The detailed output of a pipeline run — every command and its result
Queue	The waiting line	Pipelines waiting for an available agent to run on

Interview-Ready Answers

Core Concepts

Jenkins Pipeline A Jenkins pipeline is a sequence of stages that automate the software delivery process. It's defined in a Jenkinsfile (committed to Git) and executed by Jenkins. The declarative syntax is recommended — it's structured, readable, and validated. The gotcha: pipelines are stateless. Each run is independent. Don't assume files from a previous build exist unless you explicitly archive or pass them.

Jenkinsfile A Jenkinsfile is a Groovy-based file that defines the entire CI/CD pipeline. It's committed to your Git repository, making the pipeline version-controlled and reviewable like any other code. The gotcha: Jenkinsfile runs on the agent, not on your local machine. Test pipeline changes in a feature branch before merging.

Agent An agent is a machine (or Docker container) that executes the pipeline. The agent directive in the Jenkinsfile specifies where the pipeline runs. agent any uses any available agent. Docker agents give clean environments every time. The gotcha: if no agents are available, the build stays in the queue. Monitor your agent capacity.

Stages and Steps Stages are the major phases of a pipeline (Build, Test, Deploy). Steps are individual commands within a stage. Stages are displayed separately in the Jenkins UI, making it easy to see which phase succeeded or failed. The gotcha: stages run sequentially by default. Use parallel for independent stages to speed up builds.

Operations

Webhook A webhook is a push notification from your Git provider to Jenkins. When someone pushes code, Git sends a request to Jenkins, which triggers a build immediately. This is better than polling (which checks periodically and wastes resources). The gotcha: webhooks require Jenkins to be accessible from the internet. Use tools like ngrok for local development.

Credentials Jenkins credentials are stored secrets (passwords, tokens, SSH keys) that pipelines can reference by ID. Never hardcode secrets in a Jenkinsfile. Use withCredentials to inject them as environment variables. The gotcha: credential IDs are case-sensitive. DockerHub ≠ dockerhub. Always verify the exact ID.

Artifact An artifact is a file produced by a build — JARs, Docker images, test reports, deployment packages. Jenkins can archive artifacts, making them downloadable from the UI. The gotcha: artifacts consume disk space. Set up retention policies to automatically clean old builds.

Multi-Branch Pipeline A multi-branch pipeline automatically creates a separate pipeline for each branch in your repository. When a new branch is created (with a Jenkinsfile), Jenkins detects it and creates a pipeline. This is the recommended approach for teams working on multiple features simultaneously. The gotcha: each branch runs independently. A failure on a feature branch doesn't affect main.

Classic Interview Q&A

Q1: What is the difference between Continuous Integration and Continuous Delivery?

Answer: Continuous Integration (CI) is the practice of merging code changes frequently and automatically building and testing them. It catches bugs early. Continuous Delivery (CD) extends CI by automatically preparing releases for deployment. Continuous Deployment goes further by automatically deploying every change that passes tests. The gotcha: CI is the foundation. Without reliable CI, CD is just automating failures.

Q2: What is the difference between Declarative and Scripted Pipelines?

Answer: Declarative is the recommended syntax — it's structured, readable, and has built-in validation. Scripted is the older, more flexible syntax that allows arbitrary Groovy code. Declarative uses pipeline { } as the root block. Scripted uses node { }. In practice, always use Declarative — it's easier to read, review, and maintain. Scripted is only needed for complex, dynamic pipelines.

Q3: How do you handle secrets in Jenkins?

Answer: Never hardcode secrets in a Jenkinsfile. Store them in Jenkins Credentials (Manage Jenkins → Credentials). Reference them with withCredentials([usernamePassword(...)]) in the pipeline. Jenkins masks secrets in logs automatically. For extra security, use external secret managers (Vault, AWS Secrets Manager) with Jenkins plugins. The gotcha: secrets in environment variables can leak through process listings. Use withCredentials scope carefully.

Q4: What is a Shared Library and when should you use one?

Answer: A Shared Library is a collection of reusable Groovy code that can be used across multiple Jenkinsfiles. Use it when multiple pipelines repeat the same steps (building Docker images, deploying to Kubernetes, sending notifications). The library is stored in a separate Git repo and loaded with @Library('my-library') _. The gotcha: shared libraries add complexity. Only extract code to a library when you have at least 3 pipelines using the same logic.

Q5: How does Jenkins handle parallel execution?

Answer: Use the parallel directive within a stage to run independent steps simultaneously. This cuts build time by running unit tests and integration tests at the same time, or linting and security scans in parallel. Each parallel branch runs on a separate executor. The gotcha: parallel stages share the same workspace by default. Use separate directories or Docker agents to avoid file conflicts.

Q6: What is the difference between a Jenkins Agent and a Node?

Answer: In Jenkins terminology, a Node is a machine that's part of the Jenkins cluster. An Agent is a process that runs on a Node to execute pipelines. In practice, people use the terms interchangeably. The agent directive in the Jenkinsfile specifies which type of machine to use. The gotcha: an agent can run only one pipeline per executor. If all executors are busy, new builds wait in the queue.

Q7: How do you implement rollback in Jenkins?

Answer: Rollback depends on your deployment strategy. For Docker/Kubernetes: tag images with build numbers, and rollback by pointing the deployment back to the previous image tag (kubectl set image). For Jenkins pipelines: keep old artifacts and redeploy them. Use input gates before production deployments. The gotcha: rollback is only possible if you keep previous artifacts. Never delete old images or artifacts.