As I gradually moved from “following deployment steps” to actually understanding why modern delivery pipelines are designed the way they are, CI/CD stopped being a collection of tools and started to look like a coherent system.
This note summarizes my understanding of how code flows from Git to production, and more importantly, why each component exists and where its responsibility ends.
From Code to Production: Why CI/CD Exists
In real production environments, the core problem is rarely “can the code run?”.
Instead, teams care about questions like:
Who built this version?
Which commit is currently running in production?
Has this artifact been tested?
Can we safely roll back if something goes wrong?
CI/CD exists to answer these questions consistently, repeatedly, and audibly.
Git: The Single Source of Truth
Git is the foundation of the entire delivery pipeline.
Not only application code, but also build logic and deployment behavior should be version-controlled.
This is why Jenkins pipelines are increasingly defined via a Jenkinsfile stored in the repository.
When delivery logic lives in Git:
It can be reviewed
It can be rolled back
It can be traced to a specific change
At that point, deployment becomes an engineering activity rather than an operational ritual.
Jenkins and CI: Building Confidence, Not Just Code
Jenkins is best understood as a CI engine, not a deployment tool.
Its responsibility is to:
Pull code from Git
Execute the pipeline defined in Jenkinsfile
Build and test the application
Produce a deterministic output
That output is not “a running service” — it is an artifact.
Jenkins excels at standardizing and automating this process, but it intentionally avoids managing production runtime behavior directly.
Artifacts: The Real Product of CI
One of the most important concepts in CI/CD is the artifact.
An artifact is:
A reproducible, immutable result of a specific build, suitable for deployment.
Depending on the technology stack, an artifact may look different:
Java: a jar or war file
Python: a packaged code bundle
Frontend: compiled static assets
Containers: a Docker image
The key point is not the format, but traceability and immutability.
Once an artifact is built, it should never be modified — only promoted or rolled back.
Artifact Repositories: Why Jenkins Is Not Enough
Jenkins can temporarily store build outputs, but it is not an artifact repository.
Artifact repositories (such as Nexus or Artifactory) exist to:
Store artifacts long-term
Manage versions
Serve artifacts reliably to downstream systems
Decouple build from deployment
This separation allows teams to:
Build once
Deploy many times
Deploy the same artifact to different environments with confidence
CI vs CD: Why Production Needs Governance
CI focuses on code health.
CD focuses on production safety.
In regulated environments such as banks, production deployment requires:
Access control
Approval workflows
Environment separation
Rollback mechanisms
Audit trails
This is why CI tools like Jenkins are often paired with a dedicated CD orchestration platform.
Platform-Level CD: The Role of BlueKing Pipeline
In large organizations, release management is treated as a platform problem.
Platforms such as Tencent BlueKing Pipeline focus on:
Release approvals
Multi-environment orchestration
Coordinated multi-host deployments
Rollbacks and compliance auditing
Rather than replacing Jenkins, such platforms build on top of CI outputs, orchestrating how artifacts are promoted into production.
A typical enterprise flow looks like:
Git
↓
Jenkins (CI)
↓
Artifact Repository
↓
CD Platform
↓
Production EnvironmentEach component has a clearly defined responsibility.
Python vs Java: Runtime Differences Matter
Technology stack differences also shape delivery pipelines.
Java applications typically embed a production-ready web server (Tomcat, Jetty) and can be run directly as a JAR.
Python web applications require an external WSGI server such as Gunicorn for production readiness.
Understanding these runtime differences helps avoid incorrect assumptions when designing CI/CD pipelines across stacks.
Final Reflection
When each component is allowed to focus on what it does best, the overall system becomes both stable and controllable.
Through this process, I gained a clear understanding of:
Why Jenkins should not directly manage production
Why artifacts sit at the center of CI/CD
Why banks and large organizations rely on platform-level CD solutions
How everyday deployment steps map to deeper engineering principles
Most importantly, I am no longer just executing deployment steps —
I understand the system I am operating within.