Reflections on a DevOps Journey and Insights from the Jenkins 2.x Practical Guide

Looking Back

When I first graduated, my previous company had an advanced continuous integration setup for an overseas project involving multiple countries, and we introduced DevOps into the company.

My team, TeamBuild, handled packaging, deployment, automated testing, etc. At that time DevOps was little known in China, but later the DevOps wave from abroad spread domestically.

The team's main tasks were:

Implement continuous integration using Microsoft's TFS tool.

PowerShell automated deployment (I mainly did this, often working until 3 am).

Use Microsoft Azure for continuous delivery.

Etc.

Present Day

In my current company DevOps is not valued, so few teams are enthusiastic, yet it remains necessary and valuable.

Although many decisions are out of our control, we can create value through our own practice and possibly promote it to other teams if we lead by example.

The Book

Recently I wrote several articles on using Jenkins for continuous integration and continuous delivery and found a Jenkins book to supplement theory.

The book is titled “Jenkins 2.x Practical Guide”.

The book mainly explains how to implement CI/CD stages—build, test, artifact management, deployment—through Jenkins pipelines.

Beyond the technology, two points resonated with me:

Resonance One

I find packaging and deployment cumbersome and error‑prone, affecting personal and team efficiency.

The book draws on sociological theory to provide a theoretical basis for improving software engineering productivity.

Excerpt from the book:

Three essential elements of software engineering: Labor : software developers and testers are labor, but when they are not working they are 劳动者 . Labor Materials : offices, chairs, tools; the book discusses production tools from hardware and software perspectives. Labor Objects : unlike manufacturing cars, software labor objects are intangible knowledge, divided into business knowledge and technical knowledge. Managers should help laborers achieve optimal work states to produce more labor; otherwise they remain workers, not labor.

Resonance Two

In 2013 the author fully implemented Jenkins pipelines in the team. The biggest challenge was not technical but convincing decision‑makers of the pipeline’s benefits and costs, and getting team members willing and able to learn. Potential issues include: (1) No one in the team has practiced continuous integration and continuous delivery before. (2) Developers suddenly need to care about build success and operations, feeling “more work”. (3) Veteran staff may feel threatened as heroic firefighting is replaced by engineering processes, requiring them to keep up.

Recommended further reading:

“Continuous Delivery 2.0 – Business‑Driven DevOps Essentials” (available on WeChat Reading).

“Continuous Integration: Improving Software Quality and Reducing Risk” (not yet on WeChat Reading).

If you are interested in DevOps, feel free to add me on WeChat (ID: passjava, note: DevOps).