Intelligent and Secure Automation of CI/CD Pipelines for Cloud Infrastructures

Intelligent and Secure Automation of CI/CD Pipelines for Cloud Infrastructures | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Article Intelligent and Secure Automation of CI/CD Pipelines for Cloud Infrastructures Riham Borghol, Rim Zoglami, Hamza Sarraj This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-9260975/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 8 You are reading this latest preprint version Abstract The paradigm shift towards cloud-native applications and microservices architectures has introduced significant complexities in software deployment and management. Traditional manual deployment processes are inadequate, being error-prone, slow, and insecure. This paper presents a comprehensive case study on the design and implementation of a fully automated, secure, and intelligent CI/CD pipeline for a cloud-based infrastructure. Leveraging a suite of modern DevOps tools, we demonstrate an end-to-end workflow for a microservices-based application deployed on Microsoft Azure. Unlike purely theoretical models, this work focuses on practical implementation, this work focuses on a practical implementation carried out in an academic engineering environment. The architecture integrates Jenkins for Continuous Integration, SonarQube for static code analysis, and Trivy for container security scanning. Continuous Deployment is achieved through a GitOps approach, orchestrated by ArgoCD on an Azure Kubernetes Service (AKS) cluster. The results validate the efficacy of this model, showcasing a 95.6% pipeline success rate, an 87.5% reduction in deployment time, and the enforcement of stringent quality and security gates. These results were obtained in an academic environment; performance may vary in large-scale industrial deployments. This study aims to share concrete implementation insights that may support organizations and academic institutions seeking to improve the reliability, traceability, and security of their software delivery lifecycle. Physical sciences/Engineering Physical sciences/Mathematics and computing CI/CD GitOps DevOps Cloud-Native Kubernetes Microservices Jenkins ArgoCD Secure Automation Trivy Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 1. Introduction In the contemporary landscape of software engineering, the adoption of distributed systems, particularly microservices architectures, has become ubiquitous. This architectural style offers enhanced scalability, resilience, and maintainability compared to monolithic systems [ 1 , 2 ]. However, it also introduces significant challenges related to deployment, configuration management, and operational oversight. In practice, these challenges are often underestimated, especially when systems evolve rapidly or involve multiple independent services. The need to manage dozens or even hundreds of independently deployable services necessitates a departure from traditional, manual operational practices towards highly automated, reliable, and secure workflows. In response to these challenges, DevOps practices, combined with Continuous Integration (CI) and Continuous Deployment (CD), have emerged as the industry standard [ 4 ]. CI/CD pipelines automate the process of building, testing, and deploying software, enabling development teams to deliver value to users faster and more reliably. More recently, the GitOps paradigm has gained prominence as an evolution of CI/CD for cloud-native environments. GitOps leverages Git as the single source of truth for declarative infrastructure and applications [ 5 , 6 ], using automated tools to ensure the live system state converges towards the state described in the repository. This shift also introduces a cultural change, as operational actions become auditable software changes rather than manual interventions. This paper details a practical implementation of these modern principles through a case study conducted at ESPRIT School of Engineering. The project's primary objective was to build a secure and automated CI/CD pipeline with a GitOps workflow for a real-world web application. The application, a training management platform, was developed using a microservices architecture and deployed on the Microsoft Azure cloud platform [ 7 ]. The contribution of this work lies not in proposing a new tool, but in demonstrating how existing technologies can be combined into a coherent and operational deployment ecosystem. We document the architecture, implementation methodology, and empirical results, offering valuable insights for practitioners and academics aiming to implement similar systems. This paper contributes to the field of cloud-native software delivery by presenting an integrated DevSecOps and GitOps-based CI/CD framework tailored for microservices architectures deployed on Kubernetes. Unlike existing approaches that address automation, security, or deployment independently, this work combines continuous integration, security enforcement, and declarative deployment into a unified and fully automated pipeline. The proposed approach is experimentally validated through a real-world case study deployed on Microsoft Azure, where quantitative metrics related to deployment time, pipeline reliability, and security compliance are analyzed. The results demonstrate that embedding quality and security controls early in the pipeline significantly improves deployment efficiency, reliability, and operational transparency. The remainder of this paper is organized as follows. Section 2 reviews related work on cloud-native architectures, CI/CD automation, DevSecOps practices, and GitOps-based deployment models. Section 3 presents the overall system architecture and the design choices adopted for the proposed cloud-native application, including its microservices decomposition and containerization strategy. Section 4 details the methodology and implementation of the automated CI/CD pipeline, describing the integration of security and quality controls as well as the GitOps-based deployment process. Section 5 discusses the experimental results and evaluates the effectiveness of the proposed approach using quantitative performance and security metrics. Finally, Section 6 concludes the paper and outlines directions for future work. 2. Related Work To the best of our knowledge, no existing work provides a fully integrated CI/CD pipeline that simultaneously combines continuous integration automation, DevSecOps security practices, and GitOps-based deployment for cloud-native applications on Kubernetes. Existing studies typically focus on individual aspects of the software delivery lifecycle, such as CI/CD automation, security integration, or declarative deployment, without addressing their end-to-end integration. Several studies have investigated CI/CD pipelines in cloud computing environments. Rahman et al. [ 8 ] systematically mapped continuous integration practices and demonstrated that automated pipelines reduce deployment errors and improve release frequency. However, these approaches often rely on imperative deployment scripts and manual operational steps, which can lead to configuration drift, limited traceability, and operational complexity in large-scale distributed systems. To mitigate security risks, the DevSecOps paradigm has been proposed to integrate security controls early in the software development lifecycle. Myrbakken and Colomo-Palacios [ 9 ] highlighted the benefits of shift-left security practices, while Sablotny et al. [ 10 ] demonstrated the effectiveness of static code analysis and container vulnerability scanning in CI/CD pipelines. Nevertheless, most DevSecOps solutions still treat deployment as a final stage, lacking continuous security monitoring and automated compliance enforcement after deployment. More recently, GitOps has emerged as an evolution of CI/CD tailored for cloud-native environments. By using Git repositories as the single source of truth, GitOps frameworks such as ArgoCD enable declarative deployment, automatic rollback, and enhanced auditability [ 6 , 11 ]. Studies by Hüttermann [ 11 ] and Wurster et al. [ 12 ] show that GitOps improves deployment reliability and consistency in Kubernetes-based environments. However, GitOps-based solutions often focus primarily on deployment and do not fully integrate CI processes such as build automation, testing, and security scanning. Table 1 summarizes representative CI/CD pipeline approaches from the literature and highlights their limitations in terms of deployment time, security coverage, and auditability. In contrast to existing works, the approach proposed in this paper provides an end-to-end pipeline that integrates CI/CD automation, DevSecOps practices, and GitOps deployment within a unified and fully auditable framework, validated through a real-world cloud deployment case study. Table 1 Comparison of Existing CI/CD Pipelines and Limitations Pipeline / Study Components Avg. Deployment Time Security Checks Auditability Limitations How Our Approach Overcomes Traditional Jenkins Jenkins CI, manual scripts 45–120 min Limited, mostly post-build Low, manual logging Long deployment, error-prone, limited traceability Fully automated, declarative pipeline with audit trail Jenkins + DevSecOps Jenkins + SonarQube, Trivy 30–60 min Improved via static code & container scanning Medium Security checks often post-build, limited rollback Shift-left security integrated, automatic rollback via ArgoCD GitOps pipelines GitOps (ArgoCD) + Kubernetes 15–30 min Basic deployment security High Lacks CI integration for building, testing, container scanning Full CI/CD + DevSecOps + GitOps in unified pipeline Proposed Approach Jenkins CI + SonarQube + Trivy + ArgoCD on AKS 12–15 min Full shift-left security High, automated & auditable N/A Combines CI/CD automation, DevSecOps, and GitOps with real metrics 3. System Architecture and Design The foundation of this study is a web-based training management platform designed for an educational institution. The system's architecture was deliberately chosen to reflect modern software design patterns, providing a realistic testbed for the DevOps pipeline. The design process followed the Scrum agile framework [13], breaking down the work into manageable sprints. 3.1 Application Architecture The application follows a three-tier architecture, comprising a presentation layer, an application layer, and a data layer. This separation of concerns is fundamental to building a maintainable and scalable system. • Presentation Layer: A dynamic Single-Page Application (SPA) built with Angular [14]. It provides a responsive user interface for administrators and teachers to manage and browse training programs. • Application Layer: The backend is built on a microservices architecture using Spring Boot [15]. This layer contains the core business logic, decomposed into independent, loosely coupled services. • Data Layer: A MySQL relational database [16] provides persistent storage for all application data, including user information, training details, and registrations. Figure 1 presents the global architecture of the proposed training management platform. The system follows a three-tier architecture composed of a presentation layer, an application layer, and a data layer, ensuring a clear separation of concerns. This architectural design improves modularity and scalability by isolating user interaction, business logic, and data management. Such separation facilitates independent evolution of each layer and aligns with best practices for cloud-native application development. 3.2 Microservices Decomposition and Communication The backend was decomposed into two primary microservices, each with a distinct responsibility, to promote modularity and independent scalability: • Formation Service: Manages the entire lifecycle of training programs, including creation, updates, and teacher registrations. • User Service: Handles user authentication, authorization, and profile management. Communication between these services is handled through a combination of synchronous and asynchronous patterns to balance responsiveness and resilience. • Synchronous Communication: For immediate request-response interactions, such as the frontend fetching data from a service, RESTful APIs are used. To avoid hardcoding service locations, Netflix Eureka is employed as a service discovery registry [17], allowing services to dynamically find and communicate with each other. • Asynchronous Communication: For decoupling services and handling events that do not require an immediate response, Apache Kafka is used as a distributed event streaming platform [18]. For instance, when a teacher registers for a course via the Formation Service, an event is published to a Kafka topic. The User Service subscribes to this topic and asynchronously updates the teacher's registration history, ensuring eventual consistency without creating a tight coupling between the services. Figure 2 illustrates the communication patterns between the microservices composing the backend system. Synchronous interactions are handled through RESTful APIs, while asynchronous communication is achieved using Apache Kafka for event-driven processing. The combination of synchronous and asynchronous communication enhances system resilience and reduces tight coupling between services. In particular, event-driven communication improves scalability and fault tolerance, which are critical requirements in distributed cloud environments. 3.3 Containerization and Repository Structure To ensure consistency across development, testing, and production environments, all application components (frontend, backend microservices, Eureka server) were containerized using Docker [19]. A docker-compose.yml file was created to orchestrate the entire stack for local development. A critical decision for the GitOps workflow was the separation of source code and deployment configurations into two distinct Git repositories. This practice is a cornerstone of robust GitOps implementations [6]. • Application Repository ( espritPFAapp): Contains all application source code (Angular and Spring Boot), Dockerfiles, and the Jenkinsfile defining the CI pipeline. • Manifests Repository ( formationApp-k8s): Contains only the Kubernetes YAML manifests that declaratively define the desired state of the application in the cluster. This repository is the single source of truth for ArgoCD. Figure 3 shows the separation between the application source code repository and the Kubernetes manifests repository. This separation is a fundamental principle of the GitOps approach adopted in this work. By isolating deployment configurations from application code, this approach improves traceability, simplifies rollback operations, and ensures that the desired system state is fully version-controlled. 4. Methodology: The Automated DevOps Workflow The implementation of the automated pipeline was divided into three logical phases: infrastructure provisioning, continuous integration setup, and continuous deployment implementation using GitOps. 4.1. Tool Selection Rationale and Alternatives The effectiveness of a CI/CD pipeline for cloud-native applications strongly depends on the selection of tools that ensure automation, security, scalability, and auditability. In this work, tool selection was guided by four main criteria: (i) compatibility with Kubernetes-based environments, (ii) support for automation and declarative configuration, (iii) integration of security controls within the pipeline (DevSecOps), and (iv) maturity and adoption in both industrial and academic contexts. These criteria are widely recognized in cloud-native and DevOps literature as essential for building reliable and reproducible deployment pipelines [19, 8, 11]. The following subsections justify the selection of each tool and discuss the considered alternatives. 4.1.1. Continuous Integration Tool Selection Jenkins was selected as the primary Continuous Integration (CI) tool due to its maturity, extensibility, and widespread adoption in both industry and research [ 20 ]. Jenkins provides extensive plugin support, enabling seamless integration with version control systems, testing frameworks, container registries, and security analysis tools. Its pipeline-as-code model promotes reproducibility and version-controlled CI workflows, which are essential for large-scale cloud-native systems. Alternative CI tools such as GitHub Actions [ 21 ] and GitLab CI [ 22 ] were considered. GitHub Actions offers tight integration with GitHub repositories but provides limited flexibility for complex, multi-stage pipelines and hybrid cloud deployments. GitLab CI integrates CI/CD into a single platform; however, its strong coupling with GitLab repositories may reduce portability across heterogeneous infrastructures. In contrast, Jenkins offers greater flexibility, extensibility, and vendor neutrality, making it more suitable for cloud-agnostic CI/CD architectures. 4.1.2. Containerization and Orchestration Platform Docker was adopted for application containerization due to its lightweight execution model, standardized image format, and extensive ecosystem support. Containerization ensures consistent application behavior across development, testing, and production environments, significantly reducing environment-specific issues [ 19 ]. For orchestration, Kubernetes [ 2 , 23 ] was chosen as the deployment platform. Kubernetes has become the de facto standard for managing containerized applications, offering advanced features such as automatic scaling, self-healing, service discovery, and declarative configuration management. Alternative orchestration platforms, including Docker Swarm and Apache Mesos, were evaluated. Docker Swarm provides simpler configuration but lacks advanced scheduling and ecosystem maturity, while Mesos introduces higher operational complexity. Kubernetes provides a balanced trade-off between scalability, flexibility, and community support, making it particularly suitable for cloud-native microservices architectures [ 2 ]. 4.1.3. Security Integration and DevSecOps Tooling To implement DevSecOps principles, security controls were embedded directly into the CI pipeline following a shift-left security strategy. SonarQube [ 9 ] was selected for static code analysis to detect code quality issues, security vulnerabilities, and technical debt early in the software development lifecycle. For container vulnerability scanning, Trivy [ 10 ] was chosen due to its lightweight design, high scanning performance, and comprehensive vulnerability database covering operating systems and application dependencies. Alternative security tools such as Checkmarx, Fortify, and Clair were considered. While enterprise solutions offer advanced analysis features, they often require proprietary licenses and complex configurations, which may hinder full automation in academic or resource-constrained environments. In contrast, SonarQube and Trivy offer an effective balance between accuracy, performance, and ease of integration, making them well-suited for automated cloud-native CI/CD pipelines. 4.1.4. GitOps Deployment Tool Selection For continuous deployment, ArgoCD was selected to implement the GitOps paradigm. ArgoCD continuously monitors Git repositories containing Kubernetes manifests and automatically reconciles the desired and actual system states of the cluster. This declarative deployment approach improves reliability, enables automated rollback, and ensures full auditability of configuration changes [ 6 , 11 , 12 ]. Alternative GitOps tools such as FluxCD were evaluated. Although FluxCD offers similar reconciliation capabilities, ArgoCD provides richer visualization, role-based access control, and advanced synchronization features. These characteristics make ArgoCD more suitable for deployment monitoring and operational transparency in complex Kubernetes environments. 4.1.5. Cloud Platform Selection Microsoft Azure Kubernetes Service (AKS) was selected as the target cloud platform due to its managed Kubernetes control plane, native integration with monitoring and security services, and support for scalable production deployments. While other managed Kubernetes platforms such as Amazon EKS and Google GKE offer comparable functionality, AKS was chosen to demonstrate the portability of the proposed CI/CD and GitOps pipeline across public cloud infrastructures. The proposed methodology remains cloud-agnostic and can be replicated on alternative Kubernetes-based platforms. 4.2. Cloud Infrastructure on Microsoft Azure A secure and scalable foundation was provisioned on Microsoft Azure. All resources were organized within a single resource group for simplified management and billing. The core components were : • Virtual Machines for DevOps Tools: Two Ubuntu VMs were deployed. The first (Standard_B2s) hosted the Jenkins CI server and the Trivy security scanner. The second (Standard_B2ms) hosted the SonarQube server for code quality analysis. Network Security Groups (NSGs) were configured to restrict access to necessary ports (e.g., 8080 for Jenkins, 9000 for SonarQube). • Azure Kubernetes Service (AKS): A production-grade AKS cluster with three worker nodes (Standard_D2s_v3) was deployed to host the containerized application. This managed Kubernetes service handles control plane operations, health monitoring, and scaling, significantly reducing operational overhead. • Container Registry: Docker Hub was used as the public container registry to store the Docker images built by the CI pipeline. Credentials were securely stored in Jenkins for authenticated pushes. Figure 4 illustrates the configuration of the virtual machine hosting the Jenkins server on Microsoft Azure. The VM is secured using Network Security Groups to restrict access to essential services. 4.3. The Continuous Integration Pipeline The CI pipeline, orchestrated by Jenkins, is the engine of the workflow. It is defined as code in a Jenkinsfile and automatically triggered by commits to the application repository. The pipeline executes a series of stages designed to build, test, and secure the application before a deployment artifact is created. During the initial iterations, several pipeline failures were encountered, mainly due to dependency conflicts and unstable test configurations. These issues were progressively resolved, highlighting the importance of incremental pipeline refinement. Figure 5 presents the declarative Jenkins pipeline used for continuous integration. The pipeline is composed of multiple stages, including build, testing, static code analysis, containerization, and security scanning. This pipeline design enables early detection of defects and vulnerabilities by enforcing quality and security checks before deployment artifacts are generated. The use of declarative pipelines also improves maintainability and reproducibility. To improve the reproducibility and measurability of the proposed CI/CD pipeline, the execution time and validation metrics of each pipeline stage were systematically recorded. Table 2 summarizes the pipeline stages, their average execution time, and the quality and security metrics enforced at each step. Table 2 CI/CD pipeline stages, execution time, and enforced metrics Pipeline Stage Description Avg. Time Metrics / Checks Enforced Checkout Clone application source repository ~ 1 min Repository access, success rate Build Compile backend and frontend components ~ 3 min Build success, dependency resolution Unit Tests Execute automated unit tests ~ 2 min Test coverage ≥ 70% SonarQube Analysis Static code quality and security analysis ~ 2 min No critical bugs or vulnerabilities Docker Build Build optimized container images ~ 1 min Image size optimization Trivy Scan Container vulnerability scanning ~ 1 min CVEs: 0 critical / high severity Push Docker Images Push validated images to registry ~ 1 min Successful push logs Update Manifests Update Kubernetes manifests (GitOps trigger) ~ 1 min ArgoCD synchronization success As shown in Table 2 , the full CI pipeline executes in approximately 12–15 minutes, while enforcing strict quality and security gates at each stage. This structured and metric-driven workflow ensures both reproducibility and reliability, enabling consistent deployment behavior across multiple execution cycles. The key stages of the CI pipeline include: 1. Checkout: Clones the source code from the Git repository. 2. Build: Compiles the Spring Boot microservices using Maven and builds the production version of the Angular frontend. 3. Unit Tests: Executes automated unit tests for both backend and frontend to ensure code correctness. 4. SonarQube Analysis: The code is analyzed by SonarQube for bugs, vulnerabilities, and code smells. A Quality Gate is enforced; if the code fails to meet predefined thresholds (e.g., >70% test coverage, 0 critical vulnerabilities), the pipeline fails. This stage acts as an intelligent quality checkpoint. 5. Build Docker Images: Docker images are built for each component using multi-stage builds to optimize for size and security. 6. Trivy Security Scan: Each newly built Docker image is scanned by Trivy for known Common Vulnerabilities and Exposures (CVEs). The pipeline fails if critical or high-severity vulnerabilities are detected, preventing insecure images from being pushed to the registry. 7. Push Docker Images: Upon passing all previous checks, the validated Docker images are tagged with the build number and pushed to Docker Hub. 8. Update Manifests: The final stage automatically checks out the formationApp-k8s repository, updates the image tags in the relevant Kubernetes Deployment manifests, and pushes the change back to Git. This commit is the trigger for the GitOps workflow. Figure 6 shows an example of a Trivy security scan report generated during the CI process. The scan identifies known vulnerabilities in container images before they are pushed to the registry. Integrating container vulnerability scanning into the CI pipeline enforces a shift-left security strategy, preventing insecure images from reaching production environments. 4.4. Continuous Deployment with GitOps and ArgoCD The final link in the chain is the Continuous Deployment process, managed by ArgoCD according to GitOps principles. ArgoCD was installed in the AKS cluster and configured to monitor the formationApp-k8s repository. The workflow is as follows: 1. Detection: ArgoCD continuously monitors the manifests repository. When the CI pipeline pushes an updated image tag, ArgoCD detects that the live state of the cluster has drifted from the desired state in Git. 2. Synchronization: ArgoCD automatically initiates a synchronization process. It pulls the new manifests from Git and applies them to the AKS cluster. 3. Rolling Update: Kubernetes handles the update gracefully using a rolling update strategy. It incrementally replaces old application pods with new ones, ensuring zero downtime for the end-user. 4. Self-Healing: A key benefit of GitOps is self-healing. If any manual, out-of-band changes are made to the cluster (e.g., via kubectl), ArgoCD detects this drift and can automatically revert the changes to match the state defined in Git, ensuring consistency and auditability. Figure 7 illustrates the complete end-to-end CI/CD and GitOps workflow, from source code commit to deployment on the Kubernetes cluster. This workflow highlights the indirect deployment mechanism enabled by GitOps, where changes are applied through version-controlled manifests rather than direct cluster access. This approach enhances auditability, consistency, and operational safety. 5. Results and Discussion The implemented system was rigorously tested and validated to measure its effectiveness, performance, and reliability. The results confirm the significant benefits of adopting an automated, secure, and GitOps-driven deployment model. 5.1. Deployment Verification and Monitoring Following the first successful pipeline run, ArgoCD synchronized the application to the AKS cluster. Verification using kubectl confirmed that all pods for the microservices, database, and frontend were in a `Running` state with high availability (2 replicas for stateless services). The frontend was accessible via a public IP address assigned by the Azure Load Balancer, and all backend functionalities were operational. The ArgoCD dashboard provided a real-time, comprehensive view of the application's health and sync status. The resource tree view allowed for intuitive visualization of the entire application hierarchy, from high-level services down to individual pods, making troubleshooting and monitoring highly efficient. Figure 8 presents the ArgoCD resource tree view, providing a real-time visualization of the deployed application and its associated Kubernetes resources. This visualization facilitates monitoring and troubleshooting by offering a clear overview of application health and synchronization status. Figure 9 shows the fully deployed and functional training management application accessed through the public interface. 5.2. Performance and Quality Metrics The automated pipeline yielded significant quantitative improvements : • Pipeline Performance: The end-to-end CI pipeline execution time averaged between 12-15 minutes. This represents an 87.5% reduction compared to an estimated manual process of 2 hours. Over 45 builds were executed during the project, with a success rate of 95.6%, demonstrating the pipeline's reliability. • Code Quality: SonarQube's quality gates were consistently met. For example, the Formation Service achieved 78.3% test coverage with zero bugs or vulnerabilities and an 'A' rating for maintainability. This automated quality enforcement prevented technical debt from accumulating. • Security Posture: Trivy scans confirmed that all final Docker images pushed to the registry had zero critical or high-severity vulnerabilities. This "shift-left" approach to security ensures that vulnerabilities are caught early in the development cycle, not in production. 5.3. Analysis of the GitOps Workflow The GitOps workflow, orchestrated by ArgoCD, proved to be a robust and transparent method for continuous deployment. The validation of a complete commit-to-production cycle took approximately 16 minutes with zero manual intervention. Note that these measurements were obtained in a controlled academic environment; execution times may differ in larger production deployments. A key test involved simulating a bug introduction and then reverting the commit in the manifests repository. ArgoCD detected the revert and automatically rolled the application back to the previous stable version within 3 minutes, demonstrating the effectiveness of Git-based rollback mechanisms. The primary benefits observed from this model include: • Traceability: Every change to the production environment is tied to a Git commit, providing a complete and immutable audit trail. • Consistency: The single source of truth in Git ensures that all environments are configured consistently, eliminating configuration drift. • Developer Experience: Developers can trigger deployments by simply merging code, without needing direct access to the Kubernetes cluster, which also improves the security posture. • Reliability: Automated rollbacks and zero-downtime rolling updates significantly increase the reliability of the deployment process. While this implementation demonstrates a practical and effective approach for automating CI/CD pipelines with integrated security and GitOps practices, it is limited by the scale of the academic environment, the number of microservices, and the specific cloud platform used (Microsoft Azure). Further studies are required to validate scalability, cost efficiency, and performance in industrial settings with larger deployments. 6. Conclusion and Future Work 6.1 Conclusion This paper has successfully demonstrated the design, implementation, and validation of an intelligent and secure CI/CD pipeline for a cloud-native microservices application. By integrating Jenkins, SonarQube, Trivy, and ArgoCD on the Microsoft Azure platform, we constructed a fully automated workflow that bridges the gap between development and operations. The case study confirms that a GitOps-centric approach not only accelerates the software delivery lifecycle but also embeds quality and security checks directly into the process. The empirical results indicate significant reductions in deployment time and demonstrate the practical benefits observed in this case study. The presented architecture serves as a practical and replicable model for organizations aiming to achieve true agility and reliability in their cloud infrastructure management. 6.2 Future Work While the current implementation provides a robust foundation, several avenues for future enhancement exist. These perspectives aim to extend the proposed framework rather than represent limitations of the current model • Enhanced Monitoring and Observability: Integrating Prometheus, Grafana, and the ELK stack • Advanced Security: Kubernetes Network Policies, Azure Key Vault, OAuth2/OIDC • Progressive Delivery: Canary or blue-green deployments with Argo Rollouts • Infrastructure as Code: Full automation using Terraform to achieve complete infrastructure reproducibility Declarations Author contributions Riham Borghol contributed to the methodology design, the conceptualization of the study, supervision of the research activities, validation of results, and critical revision of the manuscript. Rim Zoglami contributed to the implementation of the CI/CD pipeline, experimental setup. Hamza Sarraj contributed to the formal analysis, investigation, and interpretation of experimental results. Funding No funding received for this study Data availability No datasets were generated or analysed during this study. Competing interests The authors declare no competing interests References Newman S (2015) Building Microservices. O’Reilly Media Zhang Q, Chen M, Li L, Li Y (2021) Kubernetes-based cloud-native application deployment: architecture and challenges. J Cloud Comput 10(1). https://doi.org/10.1186/s13677-021-00251-x Humble J, Farley D (2010) Continuous Delivery. Addison-Wesley Fowler M, Humble J (2010) Continuous Integration. ThoughtWorks Weaveworks (2017) Guide to GitOps. https://weave.works/technologies/gitops/ The Argo Project (2025) Argo CD: Declarative GitOps CD for Kubernetes. https://argoproj.github.io/argo-cd/ Microsoft Corporation (2025) Azure Kubernetes Service (AKS). https://azure.microsoft.com/ Rahman AA, Helms E, Williams L (2019) A systematic mapping study of continuous integration. J Syst Softw 155:78–94. https://doi.org/10.1016/j.jss.2019.05.003 Myrbakken H, Colomo-Palacios R (2017) DevSecOps: A multivocal literature review. Softw Qual J 25(3):701–739. https://doi.org/10.1007/s11219-016-9336-1 Sablotny M, Biallas S, Schmid K (2020) Security testing in CI/CD pipelines for cloud-native applications. IEEE Softw 37(6):42–49. https://doi.org/10.1109/MS.2020.2991187 Hüttermann M (2022) GitOps and Kubernetes: Continuous deployment with declarative infrastructure. IEEE Cloud Comput 9(1):60–67. https://doi.org/10.1109/MCC.2022.3169632 Wurster M et al (2021) Improving deployment reliability using GitOps. J Cloud Comput 10(1). https://doi.org/10.1186/s13677-021-00234-x Sutherland J, Schwaber K (2017) The Scrum Guide. Scrum.org Google (2025) Angular documentation. https://angular.io Spring (2025) Spring Boot documentation. https://spring.io/projects/spring-boot Oracle Corporation (2025) MySQL reference manual. https://dev.mysql.com/doc/ Netflix (2012) Eureka at Netflix. https://netflixtechblog.com Kreps J, Narkhede N, Rao J (2011) Kafka: A distributed messaging system. NetDB Pahl C (2015) Containerization and the PaaS cloud. IEEE Cloud Comput 2(3):24–31 Jenkins Project (2025) Jenkins documentation. https://www.jenkins.io GitHub (2024) GitHub Actions documentation. https://docs.github.com/actions GitLab (2024) GitLab CI/CD documentation. https://docs.gitlab.com/ee/ci/ Burns B et al (2016) Borg, Omega, and Kubernetes. ACM Queue 14(1) Additional Declarations No competing interests reported. Cite Share Download PDF Status: Under Review Version 1 posted Reviews received at journal 03 May, 2026 Reviewers agreed at journal 14 Apr, 2026 Reviewers agreed at journal 13 Apr, 2026 Reviewers invited by journal 13 Apr, 2026 Editor assigned by journal 13 Apr, 2026 Editor invited by journal 13 Apr, 2026 Submission checks completed at journal 09 Apr, 2026 First submitted to journal 09 Apr, 2026 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-9260975","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Article","associatedPublications":[],"authors":[{"id":622744284,"identity":"638cb414-2186-4e04-99a1-00def5652810","order_by":0,"name":"Riham Borghol","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA6ElEQVRIiWNgGAWjYDACZh4QeQCIgYwHFSAOYwMJWhLOgLU0NjAk4NODrCWxjQFqDR4t5u28Bz/dYLgjZ96/9uCDxHk29ubSh9sfMP64g1OLzGG+ZOkchmfGMjfeJRskbktL3NmXCHLYM5xaJJh5DIBaDifOkDhjJpG47XCCwRmwXw7j02L8G6Flzn97YrSYQWzh7wFqaTjAuIEYLdY5Bs+MJSR4jA0SjiUn7uxhbJyRkIZHC/8Z49s5FXfkgAzDBx9q7OzNedgffPhgg1sLBBiANCcg2PhjEg74DyBpGQWjYBSMglGABACoe1PneDY/ewAAAABJRU5ErkJggg==","orcid":"","institution":"ESPRIT School of Engineering","correspondingAuthor":true,"prefix":"","firstName":"Riham","middleName":"","lastName":"Borghol","suffix":""},{"id":622744291,"identity":"499034bb-469e-4adc-bac0-073e8d6dbb6f","order_by":1,"name":"Rim Zoglami","email":"","orcid":"","institution":"ESPRIT School of Engineering","correspondingAuthor":false,"prefix":"","firstName":"Rim","middleName":"","lastName":"Zoglami","suffix":""},{"id":622744294,"identity":"67624546-cc79-492a-a9b9-441ece8df17e","order_by":2,"name":"Hamza Sarraj","email":"","orcid":"","institution":"ESPRIT School of Engineering","correspondingAuthor":false,"prefix":"","firstName":"Hamza","middleName":"","lastName":"Sarraj","suffix":""}],"badges":[],"createdAt":"2026-03-29 21:23:16","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-9260975/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-9260975/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":108046402,"identity":"96841471-a280-4463-b0e7-325f7ce3a82e","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":1088973,"visible":true,"origin":"","legend":"\u003cp\u003eGlobal System Architecture.\u003c/p\u003e","description":"","filename":"floatimage1.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/f7bb6fd8eb79d4c769367dbd.png"},{"id":108181213,"identity":"89a8e1fc-bebf-47d5-b913-c397ed493c74","added_by":"auto","created_at":"2026-04-30 08:58:24","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":879477,"visible":true,"origin":"","legend":"\u003cp\u003eMicroservices Communication Patterns with Eureka and Kafka.\u003c/p\u003e","description":"","filename":"floatimage2.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/bf25104d9c99d9efe96b35e7.png"},{"id":108181483,"identity":"384d8c09-985a-42c3-92c5-f28ab1bb2582","added_by":"auto","created_at":"2026-04-30 08:58:41","extension":"jpeg","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":903457,"visible":true,"origin":"","legend":"\u003cp\u003eSeparation of Application Code and Kubernetes Manifests into Two Git Repositories.\u003c/p\u003e","description":"","filename":"floatimage3.jpeg","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/9adc5e6b447ba1206f50c19e.jpeg"},{"id":108046404,"identity":"d327ff08-2112-419d-915b-ebacb892849f","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":78256,"visible":true,"origin":"","legend":"\u003cp\u003eAzure VM Configuration for the Jenkins Server.\u003c/p\u003e","description":"","filename":"floatimage4.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/20c53450a0d48601bcce9050.png"},{"id":108046406,"identity":"75bb4749-b8aa-4695-9e97-25766936561b","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":77564,"visible":true,"origin":"","legend":"\u003cp\u003eJenkins Declarative Pipeline Architecture with Parallel Stages.\u003c/p\u003e","description":"","filename":"floatimage5.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/a3f6d73392bc98045d484daa.png"},{"id":108046407,"identity":"08e7e49f-a99f-4347-ac51-4159bd97f0fd","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":110175,"visible":true,"origin":"","legend":"\u003cp\u003eTrivy Security Scan Report Integrated into the Jenkins Pipeline Output.\u003c/p\u003e","description":"","filename":"floatimage6.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/cef5a0867e6378cd1831c065.png"},{"id":108181599,"identity":"f26fdaf3-14d4-472e-9ca7-2115bc0f6415","added_by":"auto","created_at":"2026-04-30 08:58:46","extension":"jpeg","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":717058,"visible":true,"origin":"","legend":"\u003cp\u003eThe End-to-End Automated CI/CD and GitOps Workflow.\u003c/p\u003e","description":"","filename":"floatimage7.jpeg","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/778a02c07f2143b5d1862df4.jpeg"},{"id":108046410,"identity":"d26af41e-e3a0-401b-ad2b-e0128efbaf5b","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":114720,"visible":true,"origin":"","legend":"\u003cp\u003eArgoCD's Resource Tree View, Visualizing the Deployed Application Hierarchy and Health Status.\u003c/p\u003e","description":"","filename":"floatimage8.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/d2f3a4c81b707480d2255a0d.png"},{"id":108046409,"identity":"0007969a-fc0c-4352-8aeb-3a7acd33b19e","added_by":"auto","created_at":"2026-04-28 19:52:38","extension":"png","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":147147,"visible":true,"origin":"","legend":"\u003cp\u003eThe Fully Deployed and Functional Training Management Application.\u003c/p\u003e","description":"","filename":"floatimage9.png","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/8dfad152943e1da9ec569c8c.png"},{"id":108490972,"identity":"04d6d81f-3583-495c-a0b3-6159de2c4bc4","added_by":"auto","created_at":"2026-05-05 09:50:35","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":4085972,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-9260975/v1/592f4c71-6b54-4fb8-9d19-b216034c3b3d.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"Intelligent and Secure Automation of CI/CD Pipelines for Cloud Infrastructures","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eIn the contemporary landscape of software engineering, the adoption of distributed systems, particularly microservices architectures, has become ubiquitous. This architectural style offers enhanced scalability, resilience, and maintainability compared to monolithic systems [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e, \u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. However, it also introduces significant challenges related to deployment, configuration management, and operational oversight. In practice, these challenges are often underestimated, especially when systems evolve rapidly or involve multiple independent services. The need to manage dozens or even hundreds of independently deployable services necessitates a departure from traditional, manual operational practices towards highly automated, reliable, and secure workflows.\u003c/p\u003e \u003cp\u003eIn response to these challenges, DevOps practices, combined with Continuous Integration (CI) and Continuous Deployment (CD), have emerged as the industry standard [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e]. CI/CD pipelines automate the process of building, testing, and deploying software, enabling development teams to deliver value to users faster and more reliably. More recently, the GitOps paradigm has gained prominence as an evolution of CI/CD for cloud-native environments. GitOps leverages Git as the single source of truth for declarative infrastructure and applications [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e, \u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e], using automated tools to ensure the live system state converges towards the state described in the repository. This shift also introduces a cultural change, as operational actions become auditable software changes rather than manual interventions.\u003c/p\u003e \u003cp\u003eThis paper details a practical implementation of these modern principles through a case study conducted at ESPRIT School of Engineering. The project's primary objective was to build a secure and automated CI/CD pipeline with a GitOps workflow for a real-world web application. The application, a training management platform, was developed using a microservices architecture and deployed on the Microsoft Azure cloud platform [\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e]. The contribution of this work lies not in proposing a new tool, but in demonstrating how existing technologies can be combined into a coherent and operational deployment ecosystem. We document the architecture, implementation methodology, and empirical results, offering valuable insights for practitioners and academics aiming to implement similar systems.\u003c/p\u003e \u003cp\u003eThis paper contributes to the field of cloud-native software delivery by presenting an integrated DevSecOps and GitOps-based CI/CD framework tailored for microservices architectures deployed on Kubernetes.\u003c/p\u003e \u003cp\u003eUnlike existing approaches that address automation, security, or deployment independently, this work combines continuous integration, security enforcement, and declarative deployment into a unified and fully automated pipeline.\u003c/p\u003e \u003cp\u003eThe proposed approach is experimentally validated through a real-world case study deployed on Microsoft Azure, where quantitative metrics related to deployment time, pipeline reliability, and security compliance are analyzed.\u003c/p\u003e \u003cp\u003eThe results demonstrate that embedding quality and security controls early in the pipeline significantly improves deployment efficiency, reliability, and operational transparency.\u003c/p\u003e \u003cp\u003eThe remainder of this paper is organized as follows.\u003c/p\u003e \u003cp\u003eSection 2 reviews related work on cloud-native architectures, CI/CD automation, DevSecOps practices, and GitOps-based deployment models.\u003c/p\u003e \u003cp\u003eSection 3 presents the overall system architecture and the design choices adopted for the proposed cloud-native application, including its microservices decomposition and containerization strategy.\u003c/p\u003e \u003cp\u003eSection 4 details the methodology and implementation of the automated CI/CD pipeline, describing the integration of security and quality controls as well as the GitOps-based deployment process.\u003c/p\u003e \u003cp\u003eSection 5 discusses the experimental results and evaluates the effectiveness of the proposed approach using quantitative performance and security metrics.\u003c/p\u003e \u003cp\u003eFinally, Section 6 concludes the paper and outlines directions for future work.\u003c/p\u003e"},{"header":"2. Related Work","content":"\u003cp\u003eTo the best of our knowledge, no existing work provides a fully integrated CI/CD pipeline that simultaneously combines continuous integration automation, DevSecOps security practices, and GitOps-based deployment for cloud-native applications on Kubernetes. Existing studies typically focus on individual aspects of the software delivery lifecycle, such as CI/CD automation, security integration, or declarative deployment, without addressing their end-to-end integration.\u003c/p\u003e \u003cp\u003eSeveral studies have investigated CI/CD pipelines in cloud computing environments. Rahman et al. [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e] systematically mapped continuous integration practices and demonstrated that automated pipelines reduce deployment errors and improve release frequency. However, these approaches often rely on imperative deployment scripts and manual operational steps, which can lead to configuration drift, limited traceability, and operational complexity in large-scale distributed systems.\u003c/p\u003e \u003cp\u003eTo mitigate security risks, the DevSecOps paradigm has been proposed to integrate security controls early in the software development lifecycle. Myrbakken and Colomo-Palacios [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e] highlighted the benefits of shift-left security practices, while Sablotny et al. [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e] demonstrated the effectiveness of static code analysis and container vulnerability scanning in CI/CD pipelines. Nevertheless, most DevSecOps solutions still treat deployment as a final stage, lacking continuous security monitoring and automated compliance enforcement after deployment.\u003c/p\u003e \u003cp\u003eMore recently, GitOps has emerged as an evolution of CI/CD tailored for cloud-native environments. By using Git repositories as the single source of truth, GitOps frameworks such as ArgoCD enable declarative deployment, automatic rollback, and enhanced auditability [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e, \u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e]. Studies by H\u0026uuml;ttermann [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e] and Wurster et al. [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e] show that GitOps improves deployment reliability and consistency in Kubernetes-based environments. However, GitOps-based solutions often focus primarily on deployment and do not fully integrate CI processes such as build automation, testing, and security scanning.\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e summarizes representative CI/CD pipeline approaches from the literature and highlights their limitations in terms of deployment time, security coverage, and auditability. In contrast to existing works, the approach proposed in this paper provides an end-to-end pipeline that integrates CI/CD automation, DevSecOps practices, and GitOps deployment within a unified and fully auditable framework, validated through a real-world cloud deployment case study.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab1\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eComparison of Existing CI/CD Pipelines and Limitations\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"7\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c6\" colnum=\"6\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c7\" colnum=\"7\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003ePipeline / Study\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eComponents\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eAvg. Deployment Time\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eSecurity Checks\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e \u003cp\u003eAuditability\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c6\"\u003e \u003cp\u003eLimitations\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c7\"\u003e \u003cp\u003eHow Our Approach Overcomes\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eTraditional Jenkins\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eJenkins CI, manual scripts\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e45\u0026ndash;120 min\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eLimited, mostly post-build\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eLow, manual logging\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003eLong deployment, error-prone, limited traceability\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003eFully automated, declarative pipeline with audit trail\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eJenkins\u0026thinsp;+\u0026thinsp;DevSecOps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eJenkins\u0026thinsp;+\u0026thinsp;SonarQube, Trivy\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e30\u0026ndash;60 min\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eImproved via static code \u0026amp; container scanning\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eMedium\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003eSecurity checks often post-build, limited rollback\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003eShift-left security integrated, automatic rollback via ArgoCD\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eGitOps pipelines\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eGitOps (ArgoCD) + Kubernetes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e15\u0026ndash;30 min\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eBasic deployment security\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eHigh\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003eLacks CI integration for building, testing, container scanning\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003eFull CI/CD\u0026thinsp;+\u0026thinsp;DevSecOps\u0026thinsp;+\u0026thinsp;GitOps in unified pipeline\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eProposed Approach\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eJenkins CI\u0026thinsp;+\u0026thinsp;SonarQube\u0026thinsp;+\u0026thinsp;Trivy\u0026thinsp;+\u0026thinsp;ArgoCD on AKS\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e12\u0026ndash;15 min\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eFull shift-left security\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eHigh, automated \u0026amp; auditable\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003eN/A\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003eCombines CI/CD automation, DevSecOps, and GitOps with real metrics\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e"},{"header":"3. System Architecture and Design","content":"\u003cp\u003eThe foundation of this study is a web-based training management platform designed for an educational institution. The system\u0026apos;s architecture was deliberately chosen to reflect modern software design patterns, providing a realistic testbed for the DevOps pipeline. The design process followed the Scrum agile framework [13], breaking down the work into manageable sprints.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.1 Application Architecture\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe application follows a three-tier architecture, comprising a presentation layer, an application layer, and a data layer. This separation of concerns is fundamental to building a maintainable and scalable system.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Presentation Layer: \u0026nbsp;A dynamic Single-Page Application (SPA) built with Angular [14]. It provides a responsive user interface for administrators and teachers to manage and browse training programs.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Application Layer: \u0026nbsp;The backend is built on a microservices architecture using Spring Boot [15]. This layer contains the core business logic, decomposed into independent, loosely coupled services.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Data Layer: \u0026nbsp;A MySQL relational database [16] provides persistent storage for all application data, including user information, training details, and registrations.\u003c/p\u003e\n\u003cp\u003eFigure 1 presents the global architecture of the proposed training management platform. The system follows a three-tier architecture composed of a presentation layer, an application layer, and a data layer, ensuring a clear separation of concerns. This architectural design improves modularity and scalability by isolating user interaction, business logic, and data management. Such separation facilitates independent evolution of each layer and aligns with best practices for cloud-native application development.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.2 Microservices Decomposition and Communication\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe backend was decomposed into two primary microservices, each with a distinct responsibility, to promote modularity and independent scalability:\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Formation Service: \u0026nbsp;Manages the entire lifecycle of training programs, including creation, updates, and teacher registrations.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; User Service: \u0026nbsp;Handles user authentication, authorization, and profile management.\u003c/p\u003e\n\u003cp\u003eCommunication between these services is handled through a combination of synchronous and asynchronous patterns to balance responsiveness and resilience.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Synchronous Communication: \u0026nbsp;For immediate request-response interactions, such as the frontend fetching data from a service, RESTful APIs are used. To avoid hardcoding service locations, Netflix Eureka is employed as a service discovery registry [17], allowing services to dynamically find and communicate with each other.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Asynchronous Communication: \u0026nbsp;For decoupling services and handling events that do not require an immediate response, Apache Kafka is used as a distributed event streaming platform [18]. For instance, when a teacher registers for a course via the Formation Service, an event is published to a Kafka topic. The User Service subscribes to this topic and asynchronously updates the teacher\u0026apos;s registration history, ensuring eventual consistency without creating a tight coupling between the services.\u003c/p\u003e\n\u003cp\u003eFigure 2 illustrates the communication patterns between the microservices composing the backend system. Synchronous interactions are handled through RESTful APIs, while asynchronous communication is achieved using Apache Kafka for event-driven processing. The combination of synchronous and asynchronous communication enhances system resilience and reduces tight coupling between services. In particular, event-driven communication improves scalability and fault tolerance, which are critical requirements in distributed cloud environments.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e3.3 Containerization and Repository Structure\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eTo ensure consistency across development, testing, and production environments, all application components (frontend, backend microservices, Eureka server) were containerized using Docker [19]. A docker-compose.yml file was created to orchestrate the entire stack for local development.\u003c/p\u003e\n\u003cp\u003eA critical decision for the GitOps workflow was the separation of source code and deployment configurations into two distinct Git repositories. This practice is a cornerstone of robust GitOps implementations [6].\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Application Repository ( espritPFAapp): \u0026nbsp;Contains all application source code (Angular and Spring Boot), Dockerfiles, and the Jenkinsfile defining the CI pipeline.\u003c/p\u003e\n\u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Manifests Repository ( formationApp-k8s): \u0026nbsp;Contains only the Kubernetes YAML manifests that declaratively define the desired state of the application in the cluster. This repository is the single source of truth for ArgoCD.\u003c/p\u003e\n\u003cp\u003eFigure 3 shows the separation between the application source code repository and the Kubernetes manifests repository. This separation is a fundamental principle of the GitOps approach adopted in this work. By isolating deployment configurations from application code, this approach improves traceability, simplifies rollback operations, and ensures that the desired system state is fully version-controlled.\u003c/p\u003e"},{"header":"4. Methodology: The Automated DevOps Workflow","content":"\u003cp\u003eThe implementation of the automated pipeline was divided into three logical phases: infrastructure provisioning, continuous integration setup, and continuous deployment implementation using GitOps.\u003c/p\u003e\n\u003cdiv id=\"Sec8\" class=\"Section2\"\u003e\n \u003ch2\u003e4.1. Tool Selection Rationale and Alternatives\u003c/h2\u003e\n \u003cp\u003eThe effectiveness of a CI/CD pipeline for cloud-native applications strongly depends on the selection of tools that ensure automation, security, scalability, and auditability. In this work, tool selection was guided by four main criteria:\u003cbr\u003e\u0026nbsp;(i) compatibility with Kubernetes-based environments,\u003cbr\u003e\u0026nbsp;(ii) support for automation and declarative configuration,\u003cbr\u003e\u0026nbsp;(iii) integration of security controls within the pipeline (DevSecOps), and\u003cbr\u003e\u0026nbsp;(iv) maturity and adoption in both industrial and academic contexts.\u003c/p\u003e\n \u003cp\u003eThese criteria are widely recognized in cloud-native and DevOps literature as essential for building reliable and reproducible deployment pipelines [19, 8, 11]. The following subsections justify the selection of each tool and discuss the considered alternatives.\u003c/p\u003e\n \u003cdiv id=\"Sec9\" class=\"Section3\"\u003e\n \u003ch2\u003e4.1.1. Continuous Integration Tool Selection\u003c/h2\u003e\n \u003cp\u003eJenkins was selected as the primary Continuous Integration (CI) tool due to its maturity, extensibility, and widespread adoption in both industry and research [\u003cspan citationid=\"CR20\" class=\"CitationRef\"\u003e20\u003c/span\u003e]. Jenkins provides extensive plugin support, enabling seamless integration with version control systems, testing frameworks, container registries, and security analysis tools. Its \u003cem\u003epipeline-as-code\u003c/em\u003e model promotes reproducibility and version-controlled CI workflows, which are essential for large-scale cloud-native systems.\u003c/p\u003e\n \u003cp\u003eAlternative CI tools such as GitHub Actions [\u003cspan citationid=\"CR21\" class=\"CitationRef\"\u003e21\u003c/span\u003e] and GitLab CI [\u003cspan citationid=\"CR22\" class=\"CitationRef\"\u003e22\u003c/span\u003e] were considered. GitHub Actions offers tight integration with GitHub repositories but provides limited flexibility for complex, multi-stage pipelines and hybrid cloud deployments. GitLab CI integrates CI/CD into a single platform; however, its strong coupling with GitLab repositories may reduce portability across heterogeneous infrastructures. In contrast, Jenkins offers greater flexibility, extensibility, and vendor neutrality, making it more suitable for cloud-agnostic CI/CD architectures.\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec10\" class=\"Section3\"\u003e\n \u003ch2\u003e4.1.2. Containerization and Orchestration Platform\u003c/h2\u003e\n \u003cp\u003eDocker was adopted for application containerization due to its lightweight execution model, standardized image format, and extensive ecosystem support. Containerization ensures consistent application behavior across development, testing, and production environments, significantly reducing environment-specific issues [\u003cspan citationid=\"CR19\" class=\"CitationRef\"\u003e19\u003c/span\u003e].\u003c/p\u003e\n \u003cp\u003eFor orchestration, Kubernetes [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e, \u003cspan citationid=\"CR23\" class=\"CitationRef\"\u003e23\u003c/span\u003e] was chosen as the deployment platform. Kubernetes has become the de facto standard for managing containerized applications, offering advanced features such as automatic scaling, self-healing, service discovery, and declarative configuration management. Alternative orchestration platforms, including Docker Swarm and Apache Mesos, were evaluated. Docker Swarm provides simpler configuration but lacks advanced scheduling and ecosystem maturity, while Mesos introduces higher operational complexity. Kubernetes provides a balanced trade-off between scalability, flexibility, and community support, making it particularly suitable for cloud-native microservices architectures [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e].\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec11\" class=\"Section3\"\u003e\n \u003ch2\u003e4.1.3. Security Integration and DevSecOps Tooling\u003c/h2\u003e\n \u003cp\u003eTo implement DevSecOps principles, security controls were embedded directly into the CI pipeline following a \u003cem\u003eshift-left\u003c/em\u003e security strategy. SonarQube [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e] was selected for static code analysis to detect code quality issues, security vulnerabilities, and technical debt early in the software development lifecycle.\u003c/p\u003e\n \u003cp\u003eFor container vulnerability scanning, Trivy [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e] was chosen due to its lightweight design, high scanning performance, and comprehensive vulnerability database covering operating systems and application dependencies.\u003c/p\u003e\n \u003cp\u003eAlternative security tools such as Checkmarx, Fortify, and Clair were considered. While enterprise solutions offer advanced analysis features, they often require proprietary licenses and complex configurations, which may hinder full automation in academic or resource-constrained environments. In contrast, SonarQube and Trivy offer an effective balance between accuracy, performance, and ease of integration, making them well-suited for automated cloud-native CI/CD pipelines.\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec12\" class=\"Section3\"\u003e\n \u003ch2\u003e4.1.4. GitOps Deployment Tool Selection\u003c/h2\u003e\n \u003cp\u003eFor continuous deployment, ArgoCD was selected to implement the GitOps paradigm. ArgoCD continuously monitors Git repositories containing Kubernetes manifests and automatically reconciles the desired and actual system states of the cluster. This declarative deployment approach improves reliability, enables automated rollback, and ensures full auditability of configuration changes [\u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e, \u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e, \u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e].\u003c/p\u003e\n \u003cp\u003eAlternative GitOps tools such as FluxCD were evaluated. Although FluxCD offers similar reconciliation capabilities, ArgoCD provides richer visualization, role-based access control, and advanced synchronization features. These characteristics make ArgoCD more suitable for deployment monitoring and operational transparency in complex Kubernetes environments.\u003c/p\u003e\n \u003c/div\u003e\n \u003cdiv id=\"Sec13\" class=\"Section3\"\u003e\n \u003ch2\u003e4.1.5. Cloud Platform Selection\u003c/h2\u003e\n \u003cp\u003eMicrosoft Azure Kubernetes Service (AKS) was selected as the target cloud platform due to its managed Kubernetes control plane, native integration with monitoring and security services, and support for scalable production deployments. While other managed Kubernetes platforms such as Amazon EKS and Google GKE offer comparable functionality, AKS was chosen to demonstrate the portability of the proposed CI/CD and GitOps pipeline across public cloud infrastructures. The proposed methodology remains cloud-agnostic and can be replicated on alternative Kubernetes-based platforms.\u003c/p\u003e\n \u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec14\" class=\"Section2\"\u003e\n \u003ch2\u003e4.2. Cloud Infrastructure on Microsoft Azure\u003c/h2\u003e\n \u003cp\u003eA secure and scalable foundation was provisioned on Microsoft Azure. All resources were organized within a single resource group for simplified management and billing. The core components were :\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Virtual Machines for DevOps Tools: \u0026nbsp;Two Ubuntu VMs were deployed. The first (Standard_B2s) hosted the Jenkins CI server and the Trivy security scanner. The second (Standard_B2ms) hosted the SonarQube server for code quality analysis. Network Security Groups (NSGs) were configured to restrict access to necessary ports (e.g., 8080 for Jenkins, 9000 for SonarQube).\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Azure Kubernetes Service (AKS): \u0026nbsp;A production-grade AKS cluster with three worker nodes (Standard_D2s_v3) was deployed to host the containerized application. This managed Kubernetes service handles control plane operations, health monitoring, and scaling, significantly reducing operational overhead.\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Container Registry: \u0026nbsp;Docker Hub was used as the public container registry to store the Docker images built by the CI pipeline. Credentials were securely stored in Jenkins for authenticated pushes.\u003c/p\u003e\n \u003cp\u003eFigure 4 illustrates the configuration of the virtual machine hosting the Jenkins server on Microsoft Azure. The VM is secured using Network Security Groups to restrict access to essential services.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec15\" class=\"Section2\"\u003e\n \u003ch2\u003e4.3. The Continuous Integration Pipeline\u003c/h2\u003e\n \u003cp\u003eThe CI pipeline, orchestrated by Jenkins, is the engine of the workflow. It is defined as code in a Jenkinsfile and automatically triggered by commits to the application repository. The pipeline executes a series of stages designed to build, test, and secure the application before a deployment artifact is created. During the initial iterations, several pipeline failures were encountered, mainly due to dependency conflicts and unstable test configurations. These issues were progressively resolved, highlighting the importance of incremental pipeline refinement.\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan refid=\"Fig5\" class=\"InternalRef\"\u003e5\u003c/span\u003e presents the declarative Jenkins pipeline used for continuous integration. The pipeline is composed of multiple stages, including build, testing, static code analysis, containerization, and security scanning. This pipeline design enables early detection of defects and vulnerabilities by enforcing quality and security checks before deployment artifacts are generated. The use of declarative pipelines also improves maintainability and reproducibility.\u003c/p\u003e\n \u003cp\u003eTo improve the reproducibility and measurability of the proposed CI/CD pipeline, the execution time and validation metrics of each pipeline stage were systematically recorded. Table \u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e summarizes the pipeline stages, their average execution time, and the quality and security metrics enforced at each step.\u003c/p\u003e\n \u003cp\u003e\u003c/p\u003e\u0026nbsp;\u003ctable float=\"Yes\" id=\"Tab2\" border=\"1\"\u003e\n \u003ccaption language=\"En\"\u003e\n \u003cdiv class=\"CaptionNumber\"\u003eTable 2\u003c/div\u003e\n \u003cdiv class=\"CaptionContent\"\u003e\n \u003cp\u003eCI/CD pipeline stages, execution time, and enforced metrics\u003c/p\u003e\n \u003c/div\u003e\n \u003c/caption\u003e\n \u003cthead\u003e\n \u003ctr\u003e\n \u003cth align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003ePipeline Stage\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eDescription\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003eAvg. Time\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eMetrics / Checks Enforced\u003c/p\u003e\n \u003c/th\u003e\n \u003c/tr\u003e\n \u003c/thead\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eCheckout\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eClone application source repository\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;1 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eRepository access, success rate\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eBuild\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eCompile backend and frontend components\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;3 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eBuild success, dependency resolution\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eUnit Tests\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eExecute automated unit tests\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;2 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eTest coverage\u0026thinsp;\u0026ge;\u0026thinsp;70%\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eSonarQube Analysis\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eStatic code quality and security analysis\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;2 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eNo critical bugs or vulnerabilities\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eDocker Build\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eBuild optimized container images\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;1 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eImage size optimization\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eTrivy Scan\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eContainer vulnerability scanning\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;1 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eCVEs: 0 critical / high severity\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003ePush Docker Images\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003ePush validated images to registry\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;1 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eSuccessful push logs\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\" colname=\"c1\"\u003e\n \u003cp\u003eUpdate Manifests\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c2\"\u003e\n \u003cp\u003eUpdate Kubernetes manifests (GitOps trigger)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c3\"\u003e\n \u003cp\u003e~\u0026thinsp;1 min\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\" colname=\"c4\"\u003e\n \u003cp\u003eArgoCD synchronization success\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n \u003cp\u003e\u003c/p\u003e\n \u003cp\u003eAs shown in Table \u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e, the full CI pipeline executes in approximately 12\u0026ndash;15 minutes, while enforcing strict quality and security gates at each stage. This structured and metric-driven workflow ensures both reproducibility and reliability, enabling consistent deployment behavior across multiple execution cycles.\u003c/p\u003e\n \u003cp\u003eThe key stages of the CI pipeline include:\u003c/p\u003e\n \u003cp\u003e1. Checkout: \u0026nbsp;Clones the source code from the Git repository.\u003c/p\u003e\n \u003cp\u003e2. Build: \u0026nbsp;Compiles the Spring Boot microservices using Maven and builds the production version of the Angular frontend.\u003c/p\u003e\n \u003cp\u003e3. Unit Tests: \u0026nbsp;Executes automated unit tests for both backend and frontend to ensure code correctness.\u003c/p\u003e\n \u003cp\u003e4. SonarQube Analysis: \u0026nbsp;The code is analyzed by SonarQube for bugs, vulnerabilities, and code smells. A Quality Gate is enforced; if the code fails to meet predefined thresholds (e.g., \u0026gt;70% test coverage, 0 critical vulnerabilities), the pipeline fails. This stage acts as an intelligent quality checkpoint.\u003c/p\u003e\n \u003cp\u003e5. Build Docker Images: \u0026nbsp;Docker images are built for each component using multi-stage builds to optimize for size and security.\u003c/p\u003e\n \u003cp\u003e6. Trivy Security Scan: \u0026nbsp;Each newly built Docker image is scanned by Trivy for known Common Vulnerabilities and Exposures (CVEs). The pipeline fails if critical or high-severity vulnerabilities are detected, preventing insecure images from being pushed to the registry.\u003c/p\u003e\n \u003cp\u003e7. Push Docker Images: \u0026nbsp;Upon passing all previous checks, the validated Docker images are tagged with the build number and pushed to Docker Hub.\u003c/p\u003e\n \u003cp\u003e8. Update Manifests: \u0026nbsp;The final stage automatically checks out the formationApp-k8s repository, updates the image tags in the relevant Kubernetes Deployment manifests, and pushes the change back to Git. This commit is the trigger for the GitOps workflow.\u003c/p\u003e\n \u003cp\u003eFigure 6 shows an example of a Trivy security scan report generated during the CI process. The scan identifies known vulnerabilities in container images before they are pushed to the registry. Integrating container vulnerability scanning into the CI pipeline enforces a shift-left security strategy, preventing insecure images from reaching production environments.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec16\" class=\"Section2\"\u003e\n \u003ch2\u003e4.4. Continuous Deployment with GitOps and ArgoCD\u003c/h2\u003e\n \u003cp\u003eThe final link in the chain is the Continuous Deployment process, managed by ArgoCD according to GitOps principles. ArgoCD was installed in the AKS cluster and configured to monitor the formationApp-k8s repository.\u003c/p\u003e\n \u003cp\u003eThe workflow is as follows:\u003c/p\u003e\n \u003cp\u003e1. Detection: \u0026nbsp;ArgoCD continuously monitors the manifests repository. When the CI pipeline pushes an updated image tag, ArgoCD detects that the live state of the cluster has drifted from the desired state in Git.\u003c/p\u003e\n \u003cp\u003e2. Synchronization: \u0026nbsp;ArgoCD automatically initiates a synchronization process. It pulls the new manifests from Git and applies them to the AKS cluster.\u003c/p\u003e\n \u003cp\u003e3. Rolling Update: \u0026nbsp;Kubernetes handles the update gracefully using a rolling update strategy. It incrementally replaces old application pods with new ones, ensuring zero downtime for the end-user.\u003c/p\u003e\n \u003cp\u003e4. Self-Healing: \u0026nbsp;A key benefit of GitOps is self-healing. If any manual, out-of-band changes are made to the cluster (e.g., via kubectl), ArgoCD detects this drift and can automatically revert the changes to match the state defined in Git, ensuring consistency and auditability.\u003c/p\u003e\n \u003cp\u003eFigure 7 illustrates the complete end-to-end CI/CD and GitOps workflow, from source code commit to deployment on the Kubernetes cluster. This workflow highlights the indirect deployment mechanism enabled by GitOps, where changes are applied through version-controlled manifests rather than direct cluster access. This approach enhances auditability, consistency, and operational safety.\u003c/p\u003e\n \u003cp\u003e\u003cbr\u003e\u003c/p\u003e\n\u003c/div\u003e"},{"header":"5. Results and Discussion","content":"\u003cp\u003eThe implemented system was rigorously tested and validated to measure its effectiveness, performance, and reliability. The results confirm the significant benefits of adopting an automated, secure, and GitOps-driven deployment model.\u003c/p\u003e\n\u003cdiv id=\"Sec18\" class=\"Section2\"\u003e\n \u003ch2\u003e5.1. Deployment Verification and Monitoring\u003c/h2\u003e\n \u003cp\u003eFollowing the first successful pipeline run, ArgoCD synchronized the application to the AKS cluster. Verification using kubectl confirmed that all pods for the microservices, database, and frontend were in a `Running` state with high availability (2 replicas for stateless services). The frontend was accessible via a public IP address assigned by the Azure Load Balancer, and all backend functionalities were operational.\u003c/p\u003e\n \u003cp\u003eThe ArgoCD dashboard provided a real-time, comprehensive view of the application\u0026apos;s health and sync status. The resource tree view allowed for intuitive visualization of the entire application hierarchy, from high-level services down to individual pods, making troubleshooting and monitoring highly efficient.\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan refid=\"Fig8\" class=\"InternalRef\"\u003e8\u003c/span\u003e presents the ArgoCD resource tree view, providing a real-time visualization of the deployed application and its associated Kubernetes resources. This visualization facilitates monitoring and troubleshooting by offering a clear overview of application health and synchronization status.\u003c/p\u003e\n \u003cp\u003eFigure \u003cspan refid=\"Fig9\" class=\"InternalRef\"\u003e9\u003c/span\u003e shows the fully deployed and functional training management application accessed through the public interface.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec19\" class=\"Section2\"\u003e\n \u003ch2\u003e5.2. Performance and Quality Metrics\u003c/h2\u003e\n \u003cp\u003eThe automated pipeline yielded significant quantitative improvements :\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Pipeline Performance: \u0026nbsp;The end-to-end CI pipeline execution time averaged between 12-15 minutes. This represents an 87.5% reduction compared to an estimated manual process of 2 hours. Over 45 builds were executed during the project, with a success rate of 95.6%, demonstrating the pipeline\u0026apos;s reliability.\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Code Quality: \u0026nbsp;SonarQube\u0026apos;s quality gates were consistently met. For example, the Formation Service achieved 78.3% test coverage with zero bugs or vulnerabilities and an \u0026apos;A\u0026apos; rating for maintainability. This automated quality enforcement prevented technical debt from accumulating.\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Security Posture: \u0026nbsp;Trivy scans confirmed that all final Docker images pushed to the registry had zero critical or high-severity vulnerabilities. This \u0026quot;shift-left\u0026quot; approach to security ensures that vulnerabilities are caught early in the development cycle, not in production.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec20\" class=\"Section2\"\u003e\n \u003ch2\u003e5.3. Analysis of the GitOps Workflow\u003c/h2\u003e\n \u003cp\u003eThe GitOps workflow, orchestrated by ArgoCD, proved to be a robust and transparent method for continuous deployment. The validation of a complete commit-to-production cycle took approximately 16 minutes with zero manual intervention. Note that these measurements were obtained in a controlled academic environment; execution times may differ in larger production deployments. A key test involved simulating a bug introduction and then reverting the commit in the manifests repository. ArgoCD detected the revert and automatically rolled the application back to the previous stable version within 3 minutes, demonstrating the effectiveness of Git-based rollback mechanisms.\u003c/p\u003e\n \u003cp\u003eThe primary benefits observed from this model include:\u003c/p\u003e\n \u003cp\u003e\u0026bull;\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Traceability: \u0026nbsp;Every change to the production environment is tied to a Git commit, providing a complete and immutable audit trail.\u003c/p\u003e\n \u003cp\u003e\u0026bull;\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;Consistency: \u0026nbsp;The single source of truth in Git ensures that all environments are configured consistently, eliminating configuration drift.\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Developer Experience: \u0026nbsp;Developers can trigger deployments by simply merging code, without needing direct access to the Kubernetes cluster, which also improves the security posture.\u003c/p\u003e\n \u003cp\u003e\u0026bull; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp; Reliability: \u0026nbsp;Automated rollbacks and zero-downtime rolling updates significantly increase the reliability of the deployment process.\u003c/p\u003e\n \u003cp\u003eWhile this implementation demonstrates a practical and effective approach for automating CI/CD pipelines with integrated security and GitOps practices, it is limited by the scale of the academic environment, the number of microservices, and the specific cloud platform used (Microsoft Azure). Further studies are required to validate scalability, cost efficiency, and performance in industrial settings with larger deployments.\u003c/p\u003e\n\u003c/div\u003e"},{"header":"6. Conclusion and Future Work","content":"\u003cp\u003e\u003cstrong\u003e6.1 Conclusion\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis paper has successfully demonstrated the design, implementation, and validation of an intelligent and secure CI/CD pipeline for a cloud-native microservices application. By integrating Jenkins, SonarQube, Trivy, and ArgoCD on the Microsoft Azure platform, we constructed a fully automated workflow that bridges the gap between development and operations. The case study confirms that a GitOps-centric approach not only accelerates the software delivery lifecycle but also embeds quality and security checks directly into the process. The empirical results indicate significant reductions in deployment time and demonstrate the practical benefits observed in this case study.\u0026nbsp;The presented architecture serves as a practical and replicable model for organizations aiming to achieve true agility and reliability in their cloud infrastructure management.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e6.2 Future Work\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eWhile the current implementation provides a robust foundation, several avenues for future enhancement exist. These perspectives aim to extend the proposed framework rather than represent limitations of the current model\u003c/p\u003e\n\u003cp\u003e\u0026bull; Enhanced Monitoring and Observability: Integrating Prometheus, Grafana, and the ELK stack\u003cbr\u003e\u0026bull; Advanced Security: Kubernetes Network Policies, Azure Key Vault, OAuth2/OIDC\u003cbr\u003e\u0026bull; Progressive Delivery: Canary or blue-green deployments with Argo Rollouts\u003cbr\u003e\u0026bull; Infrastructure as Code: Full automation using Terraform to achieve complete infrastructure reproducibility\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003e\u003cstrong\u003eAuthor contributions\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eRiham Borghol contributed to the methodology design, the conceptualization of the study, supervision of the research activities, validation of results, and critical revision of the manuscript. \u0026nbsp;\u003c/p\u003e\n\u003cp\u003eRim Zoglami contributed to the implementation of the CI/CD pipeline, experimental setup. \u0026nbsp;\u003c/p\u003e\n\u003cp\u003eHamza Sarraj contributed to the formal analysis, investigation, and interpretation of experimental results. \u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFunding\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo funding received for this study \u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eData availability\u0026nbsp;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNo datasets were generated or analysed during this study.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCompeting interests\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThe authors declare no competing interests \u0026nbsp;\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n \u003cli\u003eNewman S (2015) Building Microservices. O\u0026rsquo;Reilly Media\u003c/li\u003e\n \u003cli\u003eZhang Q, Chen M, Li L, Li Y (2021) Kubernetes-based cloud-native application deployment: architecture and challenges. J Cloud Comput 10(1). https://doi.org/10.1186/s13677-021-00251-x\u003c/li\u003e\n \u003cli\u003eHumble J, Farley D (2010) Continuous Delivery. Addison-Wesley\u003c/li\u003e\n \u003cli\u003eFowler M, Humble J (2010) Continuous Integration. ThoughtWorks\u003c/li\u003e\n \u003cli\u003eWeaveworks (2017) Guide to GitOps. https://weave.works/technologies/gitops/\u003c/li\u003e\n \u003cli\u003eThe Argo Project (2025) Argo CD: Declarative GitOps CD for Kubernetes. https://argoproj.github.io/argo-cd/\u003c/li\u003e\n \u003cli\u003eMicrosoft Corporation (2025) Azure Kubernetes Service (AKS). https://azure.microsoft.com/\u003c/li\u003e\n \u003cli\u003eRahman AA, Helms E, Williams L (2019) A systematic mapping study of continuous integration. J Syst Softw 155:78\u0026ndash;94. https://doi.org/10.1016/j.jss.2019.05.003\u003c/li\u003e\n \u003cli\u003eMyrbakken H, Colomo-Palacios R (2017) DevSecOps: A multivocal literature review. Softw Qual J 25(3):701\u0026ndash;739. https://doi.org/10.1007/s11219-016-9336-1\u003c/li\u003e\n \u003cli\u003eSablotny M, Biallas S, Schmid K (2020) Security testing in CI/CD pipelines for cloud-native applications. IEEE Softw 37(6):42\u0026ndash;49. https://doi.org/10.1109/MS.2020.2991187\u003c/li\u003e\n \u003cli\u003eH\u0026uuml;ttermann M (2022) GitOps and Kubernetes: Continuous deployment with declarative infrastructure. IEEE Cloud Comput 9(1):60\u0026ndash;67. https://doi.org/10.1109/MCC.2022.3169632\u003c/li\u003e\n \u003cli\u003eWurster M et al (2021) Improving deployment reliability using GitOps. J Cloud Comput 10(1). https://doi.org/10.1186/s13677-021-00234-x\u003c/li\u003e\n \u003cli\u003eSutherland J, Schwaber K (2017) The Scrum Guide. Scrum.org\u003c/li\u003e\n \u003cli\u003eGoogle (2025) Angular documentation. https://angular.io\u003c/li\u003e\n \u003cli\u003eSpring (2025) Spring Boot documentation. https://spring.io/projects/spring-boot\u003c/li\u003e\n \u003cli\u003eOracle Corporation (2025) MySQL reference manual. https://dev.mysql.com/doc/\u003c/li\u003e\n \u003cli\u003eNetflix (2012) Eureka at Netflix. https://netflixtechblog.com\u003c/li\u003e\n \u003cli\u003eKreps J, Narkhede N, Rao J (2011) Kafka: A distributed messaging system. NetDB\u003c/li\u003e\n \u003cli\u003ePahl C (2015) Containerization and the PaaS cloud. IEEE Cloud Comput 2(3):24\u0026ndash;31\u003c/li\u003e\n \u003cli\u003eJenkins Project (2025) Jenkins documentation. https://www.jenkins.io\u003c/li\u003e\n \u003cli\u003eGitHub (2024) GitHub Actions documentation. https://docs.github.com/actions\u003c/li\u003e\n \u003cli\u003eGitLab (2024) GitLab CI/CD documentation. https://docs.gitlab.com/ee/ci/\u003c/li\u003e\n \u003cli\u003eBurns B et al (2016) Borg, Omega, and Kubernetes. ACM Queue 14(1)\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"scientific-reports","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"scirep","sideBox":"Learn more about [Scientific Reports](http://www.nature.com/srep/)","snPcode":"","submissionUrl":"","title":"Scientific Reports","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Scientific Reports","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"CI/CD, GitOps, DevOps, Cloud-Native, Kubernetes, Microservices, Jenkins, ArgoCD, Secure Automation, Trivy","lastPublishedDoi":"10.21203/rs.3.rs-9260975/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-9260975/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eThe paradigm shift towards cloud-native applications and microservices architectures has introduced significant complexities in software deployment and management. Traditional manual deployment processes are inadequate, being error-prone, slow, and insecure. This paper presents a comprehensive case study on the design and implementation of a fully automated, secure, and intelligent CI/CD pipeline for a cloud-based infrastructure. Leveraging a suite of modern DevOps tools, we demonstrate an end-to-end workflow for a microservices-based application deployed on Microsoft Azure. Unlike purely theoretical models, this work focuses on practical implementation, this work focuses on a practical implementation carried out in an academic engineering environment. The architecture integrates Jenkins for Continuous Integration, SonarQube for static code analysis, and Trivy for container security scanning. Continuous Deployment is achieved through a GitOps approach, orchestrated by ArgoCD on an Azure Kubernetes Service (AKS) cluster. The results validate the efficacy of this model, showcasing a 95.6% pipeline success rate, an 87.5% reduction in deployment time, and the enforcement of stringent quality and security gates. These results were obtained in an academic environment; performance may vary in large-scale industrial deployments. This study aims to share concrete implementation insights that may support organizations and academic institutions seeking to improve the reliability, traceability, and security of their software delivery lifecycle.\u003c/p\u003e","manuscriptTitle":"Intelligent and Secure Automation of CI/CD Pipelines for Cloud Infrastructures","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2026-04-28 19:52:33","doi":"10.21203/rs.3.rs-9260975/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"editorInvitedReview","content":"","date":"2026-05-03T10:19:13+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"130019697176451791889088414723456858315","date":"2026-04-14T06:28:04+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"270849451728658162959627576366101082663","date":"2026-04-13T14:13:52+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2026-04-13T13:46:09+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2026-04-13T13:15:50+00:00","index":"","fulltext":""},{"type":"editorInvited","content":"","date":"2026-04-13T07:26:41+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2026-04-09T13:09:10+00:00","index":"","fulltext":""},{"type":"submitted","content":"Scientific Reports","date":"2026-04-09T11:46:33+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"scientific-reports","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"scirep","sideBox":"Learn more about [Scientific Reports](http://www.nature.com/srep/)","snPcode":"","submissionUrl":"","title":"Scientific Reports","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Scientific Reports","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"bff6e418-a266-48a4-861b-287f8542eec8","owner":[],"postedDate":"April 28th, 2026","published":true,"recentEditorialEvents":[{"type":"editorInvitedReview","content":"","date":"2026-05-03T10:19:13+00:00","index":28,"fulltext":""}],"rejectedJournal":[],"revision":"","amendment":"","status":"under-review","subjectAreas":[{"id":66266875,"name":"Physical sciences/Engineering"},{"id":66266876,"name":"Physical sciences/Mathematics and computing"}],"tags":[],"updatedAt":"2026-04-28T19:52:34+00:00","versionOfRecord":[],"versionCreatedAt":"2026-04-28 19:52:33","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-9260975","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-9260975","identity":"rs-9260975","version":["v1"]},"buildId":"XKTyCvWXoU3ODBz1xrDgd","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}