Freestyle vs Pipeline jobs

Why pipeline-as-code wins.

Jenkins has two main ways to define what a job does. Freestyle projects are configured entirely through the web UI — you click to add build steps, check boxes, fill fields. Pipeline jobs are defined by a script (a Jenkinsfile) written in a Groovy-based DSL. Freestyle is where many people start; Pipeline is where every serious project ends up.

Why pipeline-as-code wins

A freestyle job’s configuration lives only inside Jenkins — it is invisible to your version control, cannot be code-reviewed, and vanishes if the instance is lost. A Jenkinsfile lives in the repository next to the code it builds, so every change to the pipeline goes through the same pull-request review as the app, you can see who changed what and when, and the job can be rebuilt from scratch on any Jenkins. That auditability is also a security property: pipeline changes are reviewable, not silent UI edits.

The idiomatic setup is a Multibranch Pipeline: point Jenkins at a repository, and it automatically discovers every branch (and pull request) that contains a Jenkinsfile and creates a job for it. New branch, new pipeline, no clicking — and it disappears when the branch is merged or deleted.

# a Multibranch Pipeline job scans the repo and builds any branch with a Jenkinsfile
#   New Item → Multibranch Pipeline → point at the repo → Jenkins finds branches + PRs
# the pipeline definition is the repo’s Jenkinsfile, reviewed like any other code