arXiv subjects

Francis Bordeleau

Publications and source records attributed to Francis Bordeleau.

14 recordsLinked to original sources

arXiv2026

Missing Dimensions: Integrating Human and Social Systems into Digital Twin Engineering

Digital twins (DTs) have emerged as a key technology at the core of digital transformation, yet their engineering practice remains too narrowly focused on engineered and natural systems. This paper argues that four system dimensions must be explicitly recognized in DT engineering: Engineered, Natural/Biological, Human, and Social. Each dimension brings distinct properties, modeling requirements, and ethical obligations that fundamentally shape what a DT must represent and how it must be built. We further argue that as DTs extend into the Human and Social dimensions, the emphasis should shift from automated control toward decision support and occupant empowerment. We illustrate our arguments using a smart building as a running example and identify four open research challenges for multi-dimensional DT engineering.

cs.SE↗

arXiv2026

Predicting Intermittent Job Failure Categories for Diagnosis Using Few-Shot Fine-Tuned Language Models

In principle, Continuous Integration (CI) pipeline failures provide valuable feedback to developers on code-related errors. In practice, however, pipeline jobs often fail intermittently due to non-deterministic tests, network outages, infrastructure failures, resource exhaustion, and other reliability issues. These intermittent (flaky) job failures lead to substantial inefficiencies: wasted computational resources from repeated reruns and significant diagnosis time that distracts developers from core activities and often requires intervention from specialized teams. Prior work has proposed machine learning techniques to detect intermittent failures, but does not address the subsequent diagnosis challenge. To fill this gap, we introduce FlaXifyer, a few-shot learning approach for predicting intermittent job failure categories using pre-trained language models. FlaXifyer requires only job execution logs and achieves 84.3% Macro F1 and 92.0% Top-2 accuracy with just 12 labeled examples per category. We also propose LogSift, an interpretability technique that identifies influential log statements in under one second, reducing review effort by 74.4% while surfacing relevant failure information in 87% of cases. Evaluation on 2,458 job failures from TELUS demonstrates that FlaXifyer and LogSift enable effective automated triage, accelerate failure diagnosis, and pave the way towards the automated resolution of intermittent job failures.

cs.SE↗

arXiv2026

Towards Build Optimization Using Digital Twins

Despite the indisputable benefits of Continuous Integration (CI) pipelines (or builds), CI still presents significant challenges regarding long durations, failures, and flakiness. Prior studies addressed CI challenges in isolation, yet these issues are interrelated and require a holistic approach for effective optimization. To bridge this gap, this paper proposes a novel idea of developing Digital Twins (DTs) of build processes to enable global and continuous improvement. To support such an idea, we introduce the CI Build process Digital Twin (CBDT) framework as a minimum viable product. This framework offers digital shadowing functionalities, including real-time build data acquisition and continuous monitoring of build process performance metrics. Furthermore, we discuss guidelines and challenges in the practical implementation of CBDTs, including (1) modeling different aspects of the build process using Machine Learning, (2) exploring what-if scenarios based on historical patterns, and (3) implementing prescriptive services such as automated failure and performance repair to continuously improve build processes.

cs.SE↗

arXiv2026

A Model-Driven Digital Twin for the Systematic Improvement of DevOps Pipelines

CI/CD pipelines are central to DevOps practices, yet their growing complexity makes them increasingly difficult to interpret, analyze, and systematically evolve. Existing tooling primarily offers execution logs and static graph representations, providing limited support for structured analysis of pipeline behavior, failures, and version-to-version evolution. This paper presents a model-driven Digital Twin (DT) for CI/CD pipelines that leverages BPMN as a model-ing backbone to transform raw CI configurations into structured, higher-level process representations. The proposed DT architecture enables visual abstraction of pipeline structure, failure tracing, and systematic version comparison, supporting both monitoring and evolution analysis of DevOps processes. Building upon validated DT architectural principles and prior work on build optimization and anomaly detection, the framework provides a modular, extensible foundation for integrating advanced analytical and prescriptive services into software delivery processes. The approach is validated using open-source CI/CD projects, and ongoing work targets the integration of additional improvement services and the extension of the DT to broader DevOps lifecycle processes.

cs.SE↗

arXiv2025

DarTwin made precise by SysMLv2 -- An Experiment

The new SysMLv2 adds mechanisms for the built-in specification of domain-specific concepts and language extensions. This feature promises to facilitate the creation of Domain-Specific Languages (DSLs) and interfacing with existing system descriptions and technical designs. In this paper, we review these features and evaluate SysMLv2's capabilities using concrete use cases. We develop DarTwin DSL, a DSL that formalizes the existing DarTwin notation for Digital Twin (DT) evolution, through SysMLv2, thereby supposedly enabling the wide application of DarTwin's evolution templates using any SysMLv2 tool. We demonstrate DarTwin DSL, but also point out limitations in the currently available tooling of SysMLv2 in terms of graphical notation capabilities. This work contributes to the growing field of Model-Driven Engineering (MDE) for DTs and combines it with the release of SysMLv2, thus integrating a systematic approach with DT evolution management in systems engineering.

cs.SE↗

arXiv2025

RevMine: An LLM-Assisted Tool for Code Review Mining and Analysis Across Git Platforms

Empirical research on code review processes is increasingly central to understanding software quality and collaboration. However, collecting and analyzing review data remains a time-consuming and technically intensive task. Most researchers follow similar workflows - writing ad hoc scripts to extract, filter, and analyze review data from platforms like GitHub and GitLab. This paper introduces RevMine, a conceptual tool that streamlines the entire code review mining pipeline using large language models (LLMs). RevMine guides users through authentication, endpoint discovery, and natural language-driven data collection, significantly reducing the need for manual scripting. After retrieving review data, it supports both quantitative and qualitative analysis based on user-defined filters or LLM-inferred patterns. This poster outlines the tool's architecture, use cases, and research potential. By lowering the barrier to entry, RevMine aims to democratize code review mining and enable a broader range of empirical software engineering studies.

cs.SE↗

arXiv2025

On the Illusion of Success: An Empirical Study of Build Reruns and Silent Failures in Industrial CI

Reliability of build outcomes is a cornerstone of effective Continuous Integration (CI). Yet in practice, developers often struggle with non-deterministic issues in the code or CI infrastructure, which undermine trust in build results. When faced with such unexpected outcomes, developers often repeatedly rerun jobs hoping for true success, but this practice is known to increase CI costs and reduce productivity. While recent studies have focused on intermittent job failures, no prior work has investigated silent failures, where build jobs are marked as successful but fail to complete all or part of their tasks. Such silent failures often go unnoticed, creating an illusion of success with detrimental consequences such as bugs escaping into production. This paper presents the first empirical study of silent failures through the practice of rerunning successful jobs. An analysis of 142,387 jobs across 81 industrial projects shows that 11% of successful jobs are rerun, with 35% of these reruns occurring after more than 24 hours. Using mixed-effects models on 32 independent variables (AUC of 85%), we identified key factors associated with reruns of successful jobs, notably testing and static analysis tasks, scripting languages like Shell, and developers prior rerun tendencies. A further analysis of 92 public issues revealed 11 categories of silent failures aligning with these factors, the most frequent being artifact operation errors, caching errors, and ignored exit codes. Overall, our findings provide valuable insights into the circumstances and causes of silent failures to raise awareness among teams, and present solutions to improve CI reliability.

cs.SE↗

arXiv2025

An Empirical Study on the Amount of Changes Required for Merge Request Acceptance

Code review (CR) is essential to software development, helping ensure that new code is properly integrated. However, the CR process often involves significant effort, including code adjustments, responses to reviewers, and continued implementation. While past studies have examined CR delays and iteration counts, few have investigated the effort based on the volume of code changes required, especially in the context of GitLab Merge Requests (MRs), which remains underexplored. In this paper, we define and measure CR effort as the amount of code modified after submission, using a dataset of over 23,600 MRs from four GitLab projects. We find that up to 71% of MRs require adjustments after submission, and 28% of these involve changes to more than 200 lines of code. Surprisingly, this effort is not correlated with review time or the number of participants. To better understand and predict CR effort, we train an interpretable machine learning model using metrics across multiple dimensions: text features, code complexity, developer experience, review history, and branching. Our model achieves strong performance (AUC 0.84-0.88) and reveals that complexity, experience, and text features are key predictors. Historical project characteristics also influence current review effort. Our findings highlight the feasibility of using machine learning to explain and anticipate the effort needed to integrate code changes during review.

cs.SE↗

arXiv2025

Efficient Detection of Intermittent Job Failures Using Few-Shot Learning

One of the main challenges developers face in the use of continuous integration (CI) and deployment pipelines is the occurrence of intermittent job failures, which result from unexpected non-deterministic issues (e.g., flaky tests or infrastructure problems) rather than regular code-related errors such as bugs. Prior studies developed machine learning (ML) models trained on large datasets of job logs to classify job failures as either intermittent or regular. As an alternative to costly manual labeling of large datasets, the state-of-the-art (SOTA) approach leveraged a heuristic based on non-deterministic job reruns. However, this method mislabels intermittent job failures as regular in contexts where rerunning suspicious job failures is not an explicit policy, and therefore limits the SOTA's performance in practice. In fact, our manual analysis of 2,125 job failures from 5 industrial and 1 open-source projects reveals that, on average, 32% of intermittent job failures are mislabeled as regular. To address these limitations, this paper introduces a novel approach to intermittent job failure detection using few-shot learning (FSL). Specifically, we fine-tune a small language model using a few number of manually labeled log examples to generate rich embeddings, which are then used to train an ML classifier. Our FSL-based approach achieves 70-88% F1-score with only 12 shots in all projects, outperforming the SOTA, which proved ineffective (34-52% F1-score) in 4 projects. Overall, this study underlines the importance of data quality over quantity and provides a more efficient and practical framework for the detection of intermittent job failures in organizations.

cs.SE↗

arXiv2025

On The Impact of Merge Request Deviations on Code Review Practices

Code review is a key practice in software engineering, ensuring quality and collaboration. However, industrial Merge Request (MR) workflows often deviate from standardized review processes, with many MRs serving non-review purposes (e.g., drafts, rebases, or dependency updates). We term these cases deviations and hypothesize that ignoring them biases analytics and undermines ML models for review analysis. We identify seven deviation categories, occurring in 37.02% of MRs, and propose a few-shot learning detection method (91% accuracy). By excluding deviations, ML models predicting review completion time improve performance in 53.33% of cases (up to 2.25x) and exhibit significant shifts in feature importance (47% overall, 60% top-*k*). Our contributions include: (1) a taxonomy of MR deviations, (2) an AI-driven detection approach, and (3) empirical evidence of their impact on ML-based review analytics. This work aids practitioners in optimizing review efforts and ensuring reliable insights.

cs.SE↗

arXiv2025

Analyzing DevOps Practices Through Merge Request Data: A Case Study in Networking Software Company

DevOps integrates collaboration, automation, and continuous improvement, enhancing agility, reducing time to market, and ensuring consistent software releases. A key component of this process is GitLab's Merge Request (MR) mechanism, which streamlines code submission and review. Studies have extensively analyzed MR data and similar mechanisms like GitHub pull requests and Gerrit Code Review, focusing on metrics such as review completion time and time to first comment. However, MR data also reflects broader aspects, including collaboration patterns, productivity, and process optimization. This study examines 26.7k MRs from four teams across 116 projects of a networking software company to analyze DevOps processes. We first assess the impact of external factors like COVID-19 and internal changes such as migration to OpenShift. Findings show increased effort and longer MR review times during the pandemic, with stable productivity and a lasting shift to out-of-hours work, reaching 70% of weekly activities. The transition to OpenShift was successful, with stabilized metrics over time. Additionally, we identify prioritization patterns in branch management, particularly in stable branches for new releases, underscoring the importance of workflow efficiency. In code review, while bots accelerate review initiation, human reviewers remain crucial in reducing review completion time. Other factors, such as commit count and reviewer experience, also influence review efficiency. This research provides actionable insights for practitioners, demonstrating how MR data can enhance productivity, effort analysis, and overall efficiency in DevOps.

cs.SE↗

arXiv2025

Build Optimization: A Systematic Literature Review

Continuous Integration (CI) consists of an automated build process involving continuous compilation, testing, and packaging of the software system. While CI comes up with several advantages related to quality and time to delivery, CI also presents several challenges addressed by a large body of research. To better understand the literature so as to help practitioners find solutions for their problems and guide future research, we conduct a systematic review of 97 studies on build optimization published between 2006 and 2024, which we summarized according to their goals, methodologies, used datasets, and leveraged metrics. The identified build optimization studies focus on two main challenges: (1) long build durations, and (2) build failures. To meet the first challenge, existing studies have developed a range of techniques, including predicting build outcome and duration, selective build execution, and build acceleration using caching or repairing performance smells. The causes of build failures have been the subject of several studies, leading to the development of techniques for predicting build script maintenance and automating repair. Recent studies have also focused on predicting flaky build failures caused by environmental issues. The majority of these techniques use machine learning algorithms and leverage build metrics, which we classify into five categories. Additionally, we identify eight publicly available build datasets for build optimization research.

cs.SE↗

arXiv2025

On the Diagnosis of Flaky Job Failures: Understanding and Prioritizing Failure Categories

The continuous delivery of modern software requires the execution of many automated pipeline jobs. These jobs ensure the frequent release of new software versions while detecting code problems at an early stage. For TELUS, our industrial partner in the telecommunications field, reliable job execution is crucial to minimize wasted time and streamline Continuous Deployment (CD). In this context, flaky job failures are one of the main issues hindering CD. Prior studies proposed techniques based on machine learning to automate the detection of flaky jobs. While valuable, these solutions are insufficient to address the waste associated with the diagnosis of flaky failures, which remain largely unexplored due to the wide range of underlying causes. This study examines 4,511 flaky job failures at TELUS to identify the different categories of flaky failures that we prioritize based on Recency, Frequency, and Monetary (RFM) measures. We identified 46 flaky failure categories that we analyzed using clustering and RFM measures to determine 14 priority categories for future automated diagnosis and repair research. Our findings also provide valuable insights into the evolution and impact of these categories. The identification and prioritization of flaky failure categories using RFM analysis introduce a novel approach that can be used in other contexts.

cs.SE↗

arXiv2024

Continuous Evolution of Digital Twins using the DarTwin Notation

Despite best efforts, various challenges remain in the creation and maintenance processes of digital twins (DTs). One of those primary challenges is the constant, continuous and omnipresent evolution of systems, their user's needs and their environment, demanding the adaptation of the developed DT systems. DTs are developed for a specific purpose, which generally entails the monitoring, analysis, simulation or optimization of a specific aspect of an actual system, referred to as the actual twin (AT). As such, when the twin system changes, that is either the AT itself changes, or the scope/purpose of a DT is modified, the DTs usually evolve in close synchronicity with the AT. As DTs are software systems, the best practices or methodologies for software evolution can be leveraged. This paper tackles the challenge of maintaining a (set of) DT(s) throughout the evolution of the user's requirements and priorities and tries to understand how this evolution takes place. In doing so, we provide two contributions: (i) we develop DarTwin, a visual notation form that enables reasoning on a twin system, its purposes, properties and implementation, and (ii) we introduce a set of architectural transformations that describe the evolution of DT systems. The development of these transformations is driven and illustrated by the evolution and transformations of a family home's DT, whose purpose is expanded, changed and re-prioritized throughout its ongoing lifecycle. Additionally, we evaluate the transformations on a lab-scale gantry crane's DT.

cs.SE↗