Understanding CI/CD and Jenkins: Principles, Practices, and Learning Recommendations

1.1 Traditional Application Release Model

If you have never experienced the traditional release process, you may not appreciate the appeal of CI/CD. Typically, a development team includes developers, testers, and operations staff. The classic release workflow involves developers committing code, operations packaging and deploying builds, and testers manually or automatically validating the product across environments, often leading to manual errors and inconsistencies.

1.2 What is CI/CD in 2020?

Continuous Integration (CI) requires every code commit to be built and tested to ensure it compiles and passes tests. Before dedicated CI servers, scripts could monitor version‑control events and trigger builds; today, CI servers automate this process.

Continuous Delivery (CD) builds on CI by automatically publishing verified builds to various environments (DEV, TEST, UAT, STAGE) and managing artifacts in repositories, enabling a "build once, run everywhere" approach.

Continuous Deployment further automates the release of tested artifacts to production, followed by health checks, monitoring, and log management.

1.3 Jenkins Continuous Integration

Jenkins, originally Hudson, is a widely used open‑source CI server written in Java and available on Windows, Linux, and macOS. It supports distributed builds with a master (server) node and agent nodes, which can run in containers or Kubernetes. Agents can be static or dynamically provisioned.

What is an Agent?

Agents execute build tasks; the server mainly schedules jobs. Dynamic agents can be created on demand, providing flexible resource allocation.

What is a Pipeline?

Jenkins pipelines implement "Pipeline as Code" using a Jenkinsfile. The pipeline defines build, test, and deployment steps in code, executed sequentially by Jenkins.

What is a Stage?

A pipeline consists of multiple stages (e.g., Build, Test, Deploy), each representing a logical step in the CI/CD flow.

1.4 My Jenkins Practice Experience

I started using Jenkins around 2018 and, after two years, migrated from manual pipeline creation to a shared‑library approach. By consolidating many Jenkinsfiles into a single, modular file and leveraging Groovy functions, we reduced complexity and improved maintainability.

We transitioned from scripted syntax to declarative syntax, using when clauses to conditionally run stages, and integrated shared libraries for reusable logic.

Our DevOps project evolved through four major pipeline versions, each addressing configuration gaps, certification requirements, and automation needs, ultimately achieving end‑to‑end automation with Jira integration, container‑based testing, and artifact management.

Developed Jenkins shared libraries for flexible multi‑pipeline support.

Created a container‑based build resource pool to accelerate compilation.

Separated Jenkins CI from CD and integrated with the broader DevOps platform.

Implemented artifact upload/download workflows to shorten release cycles.

Built Jira‑driven end‑to‑end pipelines.

Automated testing pipelines using containers.

Explored SQL audit tools to improve code quality.

Integrated SonarQube for flexible code scanning.

Connected GitLab APIs for automated code handling.

1.5 Jenkins Learning Recommendations

To effectively learn Jenkins, master Linux system operations and shell scripting, then acquire a programming language such as Python (Jenkins pipelines use Groovy). Familiarity with Docker and Kubernetes further enhances pipeline capabilities. Jenkins serves as a bridge between development and operations, making it essential for aspiring DevOps engineers.

In summary, we have covered introductory concepts, practical Jenkins usage, and strategies for deepening your CI/CD expertise.