Learn Jenkins - History, Concepts & Core Architecture

#Introduction

In episode 0 we powered up Jenkins for the first time — it runs on port 8080, complete with plugins and an admin user. Now it's time to take a pause from typing and understand what you are actually running. This episode builds the context: where Jenkins comes from, why a tool over two decades old is still the backbone of CI/CD at large companies, and how its core architecture is designed.

This context is not just trivia. The architectural decisions you make as an engineer — such as where builds run, or choosing a Freestyle Project vs a Pipeline — are heavily influenced by this understanding. Let's start from the origin.

#Main Discussion

#From Hudson to Jenkins: The Story of a Successful Fork

It all began in 2004, when Kohsuke Kawaguchi, an engineer at Sun Microsystems, created a project named Hudson — a continuous integration server that at the time was one of the first to make the concept of automated, always-monitored builds easy to use.

Historical milestones:

The fork happened because of a governance dispute: the community wanted open and fast development, while Oracle viewed Hudson as a commercial asset. It parallels OpenOffice being forked into LibreOffice — a fork does not always mean a weakening split; sometimes it gives birth to a healthier project because it is run by the people who use it every day. Hudson survived for a while, but Jenkins quickly captured almost the entire plugin ecosystem and user base.

#Why Jenkins Remains Popular at Enterprise Scale?

Two decades later, dozens of competitors have emerged — GitLab CI, GitHub Actions, CircleCI, Buildkite. Yet Jenkins remains the top choice at many companies. The reason is not nostalgia but four structural factors:

1. Open source and self-hosted with full control. Jenkins runs on your own infrastructure. Pipeline data, build history, and artifacts never leave the internal network — this is a requirement for regulated industries (finance, healthcare, government) and for teams that want to minimize vendor dependency.

2. The 1,800+ plugin ecosystem. Almost every tool you've ever heard of has a Jenkins plugin: Git, Docker, Kubernetes, Ansible, SonarQube, Slack, and thousands more. It has grown organically for two decades, so it is very likely your needs already have a mature plugin.

3. Unlimited customization. Jenkins does not force a particular workflow. Through Groovy, Jenkins Pipeline, and Shared Libraries, you can build extremely complex flows — from triggers, quality gates, to staged deployment — that would be impossible with SaaS tools constrained by design limits.

4. Massive community and resources. There is an abundance of documentation, books, blog posts, and engineers with deep Jenkins experience. Hiring talent familiar with Jenkins is far easier than for newer tools.

#Core Architecture: Controller and Agents

This is the most important concept in the entire series. Jenkins is designed with a controller-agent architecture:

• Jenkins Controller (formerly called master) is the brain. It provides the web UI, REST API, scheduling, plugin management, and orchestration of the entire pipeline. All configuration is stored in JENKINS_HOME.
• Jenkins Agents (formerly called slaves, now also nodes) are the workers. Each agent has one or more executors — slots that run one build at a time — and a workspace (the working directory where source code is checked out and the build executes).

The analogy: the controller is the restaurant manager who takes orders, arranges the queue, and distributes tasks to the kitchen; agents are the chefs who actually do the cooking. The manager should not cook if more chefs can be added — we will discuss why this is security rule number one in episode 3.

Communication between controller and agent can work in two directions: the agent outbound initiates a connection to the controller (via TCP port 50000 — remember we already opened this port in episode 0), or the controller inbound initiates an SSH connection to the agent. From a pipeline perspective, you don't need to care about the direction of communication — what matters is that jobs can be dispatched to any agent.

#The Execution Flow of a Build

When a job is triggered, here is what happens:

1. The controller places the job into the build queue.
2. The scheduler on the controller picks an available executor on a matching agent.
3. The agent runs the workspace: checks out the source code and executes the pipeline steps.
4. The agent streams logs in real time to the controller for display in the UI.
5. When finished, the controller records the result (success/failure), stores artifacts, and displays the status.

At first glance this flow looks exactly like the pipeline we will write in episode 2 — and that is the point: the Jenkinsfile describes what needs to be done, and the controller-agent architecture executes it. Here is a minimal example of a pipeline that runs on an agent with a specific label:

Pipeline directed to a linux-labeled agent

pipeline {
    agent { label 'linux' }
    stages {
        stage('Build') {
            steps {
                echo 'Dijalankan di agent berlabel linux'
            }
        }
    }
}

If you want to peek at the build queue contents from the terminal, Jenkins provides a REST API — for example curl http://localhost:8080/queue/api/json — which shows the queue of jobs waiting for a free executor. This is a quick way to see the scheduling part of the architecture we just discussed.

#Freestyle Project vs Jenkins Pipeline

Besides the physical architecture (controller/agent), there is also a logical architecture for defining jobs: Freestyle Project and Jenkins Pipeline.

Freestyle Project is the classic way. Configuration is done through UI forms: filling in the repository URL, adding build steps one by one through dropdowns, configuring triggers through checkboxes. It is fast for simple jobs, but spread across the UI, hard to version, and nearly impossible to make complex.

Jenkins Pipeline defines the entire build as code inside a Jenkinsfile stored in the repository. All changes can be reviewed through pull requests, tested locally, and shared across projects via Shared Libraries.

#Conclusion

In episode 1 you have understood:

• Jenkins history: from the Hudson project in 2004, Oracle's acquisition of Sun, to the fork into Jenkins in 2011, now community-managed.
• Why Jenkins remains dominant in enterprises: open source self-hosted with full data control, a 1,800+ plugin ecosystem, unlimited customization, and a massive community.
• The core architecture: the controller as orchestrator and agents as workers, with executors and workspaces, plus two communication modes (inbound and outbound).
• The fundamental difference between a Freestyle Project (ClickOps) and a Jenkins Pipeline (versionable code).

The key takeaway to carry with you: the controller manages, the agents work, and code is better than clicks. In episode 2 we will start writing that code — creating your first Jenkins Pipeline with a Jenkinsfile, understanding the difference between Declarative and Scripted syntax, and running it directly from Git via SCM checkout. See you in episode 2!