ABSTRACT Background DevOps pipelines have become the primary vehicle for operationalizing software architecture decisions; however, their design and evolution remain largely ad hoc and tool‐specific. This disconnect weakens traceability from architectural intent to runtime automation, complicates change impact analysis, and increases the risk of configuration errors. Although model‐driven engineering (MDE) has been proposed to support CI/CD adoption, existing approaches typically focus on individual tools or isolated pipeline fragments and lack a unified, reusable foundation for systematic transformation. Aims This paper aims to introduce a unified DevOps Pipeline Meta‐Model (DP2M) and an architecture‐to‐pipeline transformation framework that enables the derivation of executable DevOps pipelines directly from software architecture models, while ensuring traceability and supporting systematic reuse. Materials and Methods A mixed‐methods approach is employed, combining: (i) a systematic mapping of MDE‐for‐DevOps literature; (ii) a cross‐vendor analysis of industrial pipeline specification languages across Jenkins (Declarative and Scripted), GitHub Actions, GitLab CI, Azure Pipelines, CircleCI, Travis CI, Google Cloud Build, and AWS CodePipeline; and (iii) semi‐structured interviews with practitioners. From this, a taxonomy of pipeline artifacts and concerns—covering build, test, deployment, security, compliance, and observability—is derived, along with quality‐driven requirements for pipeline modeling. These are formalized into the DP2M meta‐model and a catalog of reusable transformation patterns with defined rules and constraints. Results The proposed DP2M captures a technology‐agnostic representation of DevOps pipelines with explicit traceability links to architectural elements and decisions. A prototype toolchain implements the framework and generates executable pipelines across multiple CI/CD platforms. Evaluation through realistic case studies demonstrates expressiveness across heterogeneous toolchains, preservation of architectural intent, reduction of duplication, and improved handling of DevSecOps concerns as first‐class modeling constructs. Discussions The findings highlight the limitations of existing tool‐centric approaches and demonstrate how a unified meta‐model combined with formal transformation patterns can bridge the gap between architecture and pipeline implementation. The approach supports traceability, facilitates change impact analysis, and enables controlled co‐evolution of architecture and pipeline models across diverse environments. Conclusions This work presents a practical and scalable path toward architecture‐centric, model‐driven DevOps pipelines. By enabling analyzable, evolvable, and reusable pipelines across projects and platforms, the proposed framework advances the integration of software architecture and DevOps practices while addressing key challenges in traceability, consistency, and automation.
Alenezi et al. (Mon,) studied this question.