Reexamining Software Process Improvement in the DevOps and Cloud‑Native Era

Author: Yang Zhentao, Tencent Cloud TVP.

This article examines software process improvement (SPI) from the perspectives of Jenkins, DevOps, and cloud‑native technologies, discussing the challenges and value of SPI across different eras and its significance for enhancing software development and delivery efficiency and quality.

Preface – SPI is closely related to software engineering and project management, but it is often viewed as a change‑driven activity that meets resistance. While the core of software development has not fundamentally changed, organizational forms have evolved, especially with agile and DevOps. The article explores why SPI remains necessary in the DevOps era and how it aligns with cloud‑native practices.

01. Reexamining Software Process Improvement

Two basic concepts are introduced: (1) Software process – the framework of tasks, artifacts, resources, roles, methods, and tools needed to build high‑quality software; (2) Process model – a development strategy (e.g., waterfall, spiral, incremental, iterative, V‑model) that guides project execution. In many small‑to‑medium enterprises, processes are loosely defined and driven by KPI or management pressure, whereas large internet companies invest heavily in efficiency and quality, making SPI essential for continuous improvement. Metrics such as release cycle, success rate, daily builds, and deployment frequency are crucial for observing improvement. An example is the migration from SVN to Git, where without proper SPI‑based evaluation the impact on delivery efficiency may be missed.

02. Software Process Improvement in the DevOps Era

DevOps initially faced skepticism (e.g., concerns about ops roles disappearing) but has proven to increase ops efficiency and system complexity handling. DevOps tightly couples development and operations, enabling shared metrics across roles. This creates new SPI challenges: the need for flexible measurement methods, avoiding the misconception that DevOps alone eliminates the need for improvement, and focusing on continuous refinement of tools such as automated testing, CI/CD pipelines, monitoring, and alerting dashboards.

03. Viewing SPI Through Jenkins’ Evolution

Jenkins, originating from the Hudson era, started as a tool for automated builds and basic testing. Before 2013, its use in China was limited to simple build automation and deployment scripts. With the rise of Docker and Kubernetes, Jenkins adoption exploded, leading to community meetups, the first Chinese Jenkins conference, and the growth of the Jenkins Chinese community. Jenkins 2.x introduced Pipeline, and Jenkins X extends CI/CD to a cloud‑native, Git‑and‑K8s‑driven model, embodying the “everything is programmable” principle and illustrating how process automation can be fully codified.

04. Outlook: Cloud‑Native Ecosystem, DevOps, and SPI

The cloud‑native era is moving from rapid growth to maturity. Cloud‑native is more than efficiency; it represents a breakthrough in software delivery. Required capabilities include observability, chaos engineering, and AIOps. Large‑scale micro‑services increase testing complexity, making traditional testing insufficient; chaos engineering injects faults to validate system robustness. SPI now must address solution‑level services rather than isolated tools, integrating with engineering‑efficiency and infrastructure teams. Jenkins X, built on Git and Kubernetes, continues to lead CI/CD in this environment, offering a reference for SPI initiatives.

Conclusion

The article traces SPI from its conceptual roots through Jenkins’ history to the current cloud‑native landscape, highlighting how evolving tools and practices create new opportunities and challenges for improving software development and delivery. It emphasizes that while AI makes the world smarter, engineering practices like SPI make it more efficient.