Scaling Enterprise Quality: A Case Study on Parallelization and Distributed Execution in CI/CD Pipelines

The practice of Continuous Integration (CI) has a big impact on how software is developed today. Shortening integration and feedback cycles promises to increase software quality, feature throughput, and customer satisfaction. Thus, it is not a surprise that companies try to embrace CI in domains where it is rather difficult to implement.In this paper we present our findings from two rounds of interviews with a car manufacturer on the use of tools in system engineering and how these tools would support wider adoption of CL Our findings suggest a complex tool landscape with immense requirements that are not easily fulfilled by existing tools; this holds also for tools that well support CI in other domains. From this notion, we further explore what makes the automotive domain challenging when it comes to CI (namely complexity of system and value chain). We hope that our findings will help address such challenges.

By definition, the practice of Continuous Integration (CI) promotes continuous software quality improvement. In systems adopting such a practice, quality assurance is usually performed by using static and dynamic analysis tools (e.g., SonarQube) that compute overall metrics such as maintainability or reliability measures. Furthermore, developers usually define quality gates, i.e., source code quality thresholds that must be reached by the software product after every newly committed change. If certain quality gates fail (e.g., a maintainability metric is below a settled threshold), developers should refactor the code possibly addressing some of the proposed warnings. While previous research findings showed that refactoring is often not done in practice, it is still unclear whether and how the adoption of a CI philosophy has changed the way developers perceive and adopt refactoring. In this paper, we preliminarily study-running a survey study that involves 31 developers-how developers perform refactoring in CI, which needs they have and the barriers they face while continuously refactor source code.

In this position paper, we present and demonstrate the idea of using an interdisciplinary literature review to accelerate the research on continuous integration practice. A common suggestion has been that build waiting time in continuous integration cycle should be less than 10 minutes. This guideline is based on practitioners' opinion and has not been further investigated. The objective of this study is to understand the effects of build waiting time in software engineering and to get input from waiting time research in other disciplines. The objective is met by performing two literature reviews, first on build waiting time and second on waiting times in the contexts of service operation, web use and computer use. The found effects of build waiting time were categorized into continuous integration specific, cognitive and emotional. Two minute build waiting time was considered optimal, but under 10 minutes was considered acceptable. Insight from other waiting time research suggests that the perceptions of waiting time are important and the perceptions can be lowered by providing feedback and giving developers other activities during the integration.

In an age characterized by fast-paced technological developments and the intensifying predominance of cloud computing, businesses are constantly on the lookout for new ways to optimize software delivery cycles. The following paper examines the synergistic integration of GitHub and DevOps practices in order to simplify and maximize cloud deployments by making use of Continuous Integration (CI). The combination of version control, automation, and collaborative flows has not only changed development pipelines but also reduced time-to-market, enhanced software quality, and improved deployment reliability. GitHub, a contemporary code repository and collaboration site, plays a pivotal role in this integration, serving as a platform where developers can develop, test, and deploy applications effortlessly via GitHub Actions and other CI tools. Coupled with DevOps practices—Infrastructure as Code (IaC), automated testing, and agile release cycles—organizations are able to obtain greater deployment velocity with less human error. This research examines how these technologies are integrated into leading cloud service providers such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) to establish resilient CI/CD pipelines. The research uses a qualitative case study analysis, deployment metrics, and industry reports to evaluate the effect of GitHub-integrated DevOps workflows. Primary performance metrics like build success rates, deployment cycles, lead time for changes, and recovery time are measured to prove the operational effectiveness achieved through continuous integration practices. Moreover, the paper explains real-world applications in which innovation in CI has aided firms in responding quicker to customer requirements, making scalable solutions, and preserving high levels of system stability . The results of this research highlight the innovative value of GitHub-facilitated DevOps cultures, specifically in promoting collaboration, speeding development, and enabling cloud-native design. It stresses that effective CI adoption is not just a matter of technical tools but cultural acceptance among development and operation teams. The article concludes by providing strategic advice for companies looking to implement or increase their CI capability through GitHub and DevOps best practices.

In this position paper, we present and demonstrate the idea of using an interdisciplinary literature review to accelerate the research on continuous integration practice. A common suggestion has been that build waiting time in continuous integration cycle should be less than 10 minutes. This guideline is based on practitioners' opinion and has not been further investigated. The objective of this study is to understand the effects of build waiting time in software engineering and to get input from waiting time research in other disciplines. The objective is met by performing two literature reviews, first on build waiting time and second on waiting times in the contexts of service operation, web use and computer use. The found effects of build waiting time were categorized into continuous integration specific, cognitive and emotional. Two minute build waiting time was considered optimal, but under 10 minutes was considered acceptable. Insight from other waiting time research suggests that the perceptions of waiting time are important and the perceptions can be lowered by providing feedback and giving developers other activities during the integration.

As continuous delivery and continuous integration practices become more prevalent in industry, the need for education in these areas grows. Introducing these topics introduces complexities due to the learning curve of the involved tools and the amount of time available for teaching these topics. Furthermore, there has been limited research into effective teaching practices for incorporating continuous integration and delivery concepts into traditional software engineering courses. In this paper, we discuss the results of an initial study of introducing a continuous delivery educational pipeline into an undergraduate software engineering course. The pipeline used was designed to help instructors introduce continuous integration and delivery into preexisting courses and allow students to visually understand the processes of continuous delivery and continuous integration.

Modeling continuous integration practice differences in industry software development

The continuity of continuous integration: Correlations and consequences

The practice of Continuous Integration (CI) allows developers to quickly integrate and verify projects modifications. Thus, CI acceleration products are a boon to developers seeking rapid feedback. However, if outcomes vary between accelerated and non-accelerated settings, the trustworthiness of the acceleration is called into question. <p xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">In this paper, we study the trustworthiness of two CI acceleration products, one based on program analysis (PA) and the other on machine learning (ML). We re-execute 50 failing builds from ten open-source projects in non-accelerated (baseline), PAaccelerated, and ML-accelerated settings. We find that when applied to known failing builds, PA-accelerated builds more often (43.83 percentage point difference across ten projects) align with the non-accelerated build results. We conclude that while there is still room for improvement for both CI acceleration products, the selected PA-product currently provides a more trustworthy signal of build outcomes than the ML-product.

A series of Development and Operations (DevOps) in the process of making the Narotama University Management Information System have not been implemented properly by previous developers. There are improvements or additional features of the Management Information System that are in accordance with the functionality and the increasing development needs that will be used by the academic community, so that the Management Information System developer has a little difficulty in integrating documents and distributing applications with different packages to the Production Server. In this study, a new system design is proposed by applying the practice of Continuous Integration / Continuous Delivery as a document integration process and can simplify the application distribution process, as well as implementing the Docker Container Platform as an application container with different packages that can be run on production server together. The results of implementing the practice of Continuous Integration / Continuous Delivery and the implementation of the Docker Container Platform are able to help integrate documents between developers and be able to release fixes and add features packaged in different containers automatically and periodically without long delays. which only takes an average of 17.9 seconds in the process of sending the application to the Production Server.

In the early days of software development the phrase build automation referred to automating the steps necessary to compile and link a program to create an application. Today, that phrase encompasses so much more. Creating an automated build refers to things that include build integration, unit testing, code analysis, and deployment. This book distinguishes between build automation and continuous integration (CI). By way of analogy, think of the build tools as musical instruments and build automation as the playing of those instruments. In this analogy, the practice of continuous integration is the orchestration, which is discussed in Chapter 10.KeywordsItem ListCommand LineAssembly InformationContinuous IntegrationScript FileThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Commercial software firms are increasingly using and contributing to open source software. Thus, they need to understand and work with open source software development processes. This paper investigates whether the practice of continuous integration of agile software development methods has had an impact on open source software projects. Using fine-granular data from more than 5000 active open source software projects we analyze the size of code contributions over a project’s life-span. Code contribution size has stayed flat. We interpret this to mean that open source software development has not changed its code integration practices. In particular, within the limits of this study, we claim that the practice of continuous integration has not yet significantly influenced the behavior of open source software developers.

Allure Reports, an open-source framework, significantly enhance the visualization and comprehensibility of test results in software testing. This paper explores the integration of Allure Reports with GitHub Workflows to automate the generation, publication, and management of detailed and interactive test reports. The primary focus is on improving communication, debugging processes, and overall testing efficiency through auto- mated, real-time reporting solutions. Key features of Allure Re- ports include interactive visualizations, comprehensive overviews, detailed test case information, customizable reports, and seamless integration with Continuous Integration/Continuous Deployment (CI/CD) pipelines. Additionally, the paper discusses the role of GitHub Pages and GitHub Artifacts in making test results accessible and supporting continuous integration and delivery processes. The implementation of this integration resulted in enhanced transparency, collaboration, and efficiency within development teams, as well as improved test result visibility and debugging capabilities. Empirical studies support our findings, highlighting improvements in task efficiency and reduced debugging time through the use of automated reporting and continuous integration practices [1- 3].

In 2006, Fowler and Foemmel defined ten core Continuous Integration (CI) practices that could increase the speed of software development feedback cycles and improve software quality. Since then, these practices have been widely adopted by industry and subsequent research has shown they improve software quality. However, there is poor understanding of how organizations implement these practices, of the benefits developers perceive they bring, and of the challenges developers and organizations experience in implementing them. In this paper, we discuss a multiple-case study of three small- to medium-sized companies using the recommended suite of ten CI practices. Using interviews and activity log mining, we learned that these practices are broadly implemented but how they are implemented varies depending on their perceived benefits, the context of the project, and the CI tools used by the organization. We also discovered that CI practices can create new constraints on the software process that hurt feedback cycle time. For researchers, we show that how CI is implemented varies, and thus studying CI (for example, using data mining) requires understanding these differences as important context for research studies. For practitioners, our findings reveal in-depth insights on the possible benefits and challenges from using the ten practices, and how project context matters.

The paper proposes extension of the Continuous Integration practices with debug automation of unhandled exceptions. Goal of this improvement is to reduce the amount of redundant work when inspecting hundreds of failed tests from possibly the same reason, and to decrease time necessary to provide a fix to the codebase. The suitable CI infrastructure is proposed and an automatic method how to eliminate duplicated bugs is discussed. Also an example of such automation in the Windows operating system is presented.