Continuous Integration Practices Research Articles

Automating Test Reporting: Integrating Allure Reports with GitHub Workflows for Enhanced Software Testing

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].

Automation of Software and Hardware Systems Acceptance Testing in the Paradigm of Behavior-Driven Development

The paper is devoted to the problem of software and hardware systems acceptance testing according to the Agile Testing methodology. The Agile approach is widely used by software developers, however, developers of software and hardware solutions rarely use this approach, not believing in its effectiveness. The paper assumes that for software and hardware complexes, the practice of continuous integration should be applicable and, as a result, test interaction with hardware at the level ofphysical interfaces performs automatically. The article's authors presented Accepta, a system for automating acceptance testing of software and hardware complexes, explicitly designed for the Agile Testing methodology in the context of continuous integration. The main component of Accepta is an interface block based on the Nucleo-F767ZI debug board manufactured by ST. Test actions that run within the framework of Accepta supplement by expanding the command system of the interface block. The software part, which implements the functions of test describing and execution, is based on the Cucumber framework for automating software systems acceptance testing. The requirements for the object under test and the scenarios for checking the requirements are described in the Gherkin language, which is close to the natural description. The test script steps are described programmatically in the Ruby language. The actual execution of test actions is provided by sending commands through the COM port to the interface unit and analyzing the received responses. As the practice of using Accepta in working projects has shown, this approach allows us to successfully apply the Agile development methodology for software and hardware systems. Due to the automotive interaction with the device under the test interface, high intensity of testing in the development process, including regression, is ensured. The regular testing consequence is fast feedback: as soon as any functionality stops working correctly, developers find out about it fast. At the same time, due to the use of test automation tools, the reproducibility of test action sequences led to the detection of a defect is ensured.

Adopting Continuous Integration Practices to Achieve Quality in DevOps

DevOps phenomenon is gaining popularity through its ability to support continuous value delivery. Every software process transition, technical practices has its own challenges so as DevOps. The aim of this study is to systematically review and analyse challenges confronted and practices adopted in continuous integration practice of software development to improve quality of software in DevOps. We have done systematic literature review of 44 papers. We conclude 26 challenges and 28 practices which are majorly in the continuous practices, automation, tools, monitoring and pipeline. These practices are having evidences of improving quality through faster release, monitoring performance, reduced risk, reduced testing time and efforts, improved security, fast feedback loop. In further research we have to measure the quality factors by using case study methods on selected software applications to quantify impact of presented practices.

DEVELOPMENT OF SECURE CONTAINERIZED APPLICATIONS WITH A MICROSERVICES ARCHITECTURE

The article analyzes approaches to software development that allow creating complex container applications with a microservice architecture based on automation tools and flexible development methods. The development of cloud technologies, the global strategy of containerization, the modernization of the application architecture, and the increase in security requirements have led to a change in the application development methodology. The study aims to determine approaches to increase the speed of development, security and quality of software code of containerized applications by implementing security principles and automation tools at all stages of the life cycle. Features and development prospects of microservice applications deployed in a container environment are considered. The advantages of the container infrastructure are defined: mobility, scalability, an additional level of microservice security. Containers provide an isolated environment for running a microservices, this reduces the risk of security vulnerabilities and simplifies interaction between microservices. The article identifies the security problems of microservice applications and the main vulnerabilities associated with the use of containers. It is determined that DevSecOps methodology allows implementing modern practice of continuous integration, continuous delivery, continuous application deployment and integration of security tools at all life cycle stages. DevSecOps describes development processes, deployment and operation processes using Security as Code and Infrastructure as Code practices. The research describes the model for developing and deploying microservice applications with containerization, defines the security domains, and the security controls for DevSecOps development pipeline. Based on this model, the main security control tools that must be used at all development and deployment pipeline stages are defined. The article proves that the considered technique regulates the implementation of given security procedures at all stages of the pipeline, allows to reduce development time and improve code quality for container applications with a microservices architecture.

Updates in SASfit for fitting analytical expressions and numerical models to small-angle scattering patterns.

Small-angle scattering is an increasingly common method for characterizing particle ensembles in a wide variety of sample types and for diverse areas of application. SASfit has been one of the most comprehensive and flexible curve-fitting programs for decades, with many specialized tools for various fields. Here, a selection of enhancements and additions to the SASfit program are presented that may be of great benefit to interested and advanced users alike: (a) further development of the technical basis of the program, such as new numerical algorithms currently in use, a continuous integration practice for automated building and packaging of the software, and upgrades on the plug-in system for easier adoption by third-party developers; (b) a selection of new form factors for anisotropic scattering patterns and updates to existing form factors to account for multiple scattering effects; (c) a new type of a very flexible distribution called metalog [Keelin (2016). Decis. Anal. 13, 243-277], and regularization techniques such as the expectation-maximization method [Dempster et al. (1977). J. R. Stat. Soc. Ser. B (Methodological), 39, 1-22; Richardson (1972) J. Opt. Soc. Am. 62, 55; Lucy (1974). Astron. J. 79, 745; Lucy (1994). Astron. Astrophys. 289, 983-994], which is compared with fits of analytical size distributions via the non-linear least-squares method; and (d) new structure factors, especially for ordered nano- and meso-scaled material systems, as well as the Ornstein-Zernike solver for numerical determination of particle interactions and the resulting structure factor when no analytical solution is available, with the aim of incorporating its effects into the small-angle scattering intensity model used for fitting with SASfit.

An innovative approach for the design of cryogenic electrical and process control systems at CERN: the cryogenic Continuous Integration project

Designing, building, commissioning, operating and maintaining multiple complex cryogenics process control systems involves many challenges. For several years, CERN has developed various solutions to help with the whole lifecycle of a cryogenic process control system. This has allowed the production of quality and highly reliable cryogenic control and electrical systems. This paper will present the use of these innovative and automated tools and their evolution; focusing in the first part on continuous integration practices applied to the production of Programmable Logic Controller (PLC) software. The second part will develop the practical applications for software upgrades implemented for the cryogenics processes of non-LHC detectors and test facilities at CERN. Finally, a detailed description of the approach to a standardized generation of electrical drawing for cryogenic systems will be presented along with concrete solutions already successfully implemented in operation.

Uncovering the Benefits and Challenges of Continuous Integration Practices

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.

Implementation of Docker and Continuous Integration / Continuous Delivery for Management Information System Development

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.

RETORCH: an approach for resource-aware orchestration of end-to-end test cases

Continuous integration practice mandates to continuously introduce incremental changes into code, but doing so may introduce new faults too. These faults could be detected automatically through regression testing, but this practice becomes prohibitive as the cost of executing the tests grows. This problem is preponderant in end-to-end testing where the whole system is requested for test execution. However, some of these test cases could be executed with fewer resources (e.g., memory, web services, computation, Cloud instances, among others), by deploying only the subsystems needed by each test. This paper is focused on the optimization of the resources employed in end-to-end testing by means of a resource-aware test orchestration technique in the context of continuous integration practices in the Cloud. The RETORCH approach proposes a novel way to identify the resources required by end-to-end test cases and to use this information to group together those tests requiring equivalent resources. Besides, the approach proposes to deploy the grouped tests in isolated and elastic environments, so that their execution can be scheduled in parallel on several machines. RETORCH is exemplified with a real-world application, and its performance evaluation shows promising savings in terms of resource usage and time.

Taking a Studio Course in Distributed Software Engineering from a Large Local Cohort to a Small Global Cohort

One of the challenges of global software engineering courses is to bring the practices and experience of large geographically distributed teams into the local and time-limited environment of a classroom. Over the last 6 years, an on-campus studio course for software engineering has been developed at the University of Queensland (UQ) that places small teams of students on different features of a common product. This creates two layers of collaboration, as students work within their teams on individual features, and the teams must interoperate with many other teams on the common product. The class uses continuous integration practices and predominantly asynchronous communication channels (Slack and GitHub) to facilitate this collaboration. The original goal of this design was to ensure that students would authentically experience issues associated with realistically sized software projects, and learn to apply appropriate software engineering and collaboration practices to overcome them, in a course without significant extra staffing. Data from the development logs showed that most commits take place outside synchronous class hours, and the project operates as a temporally distributed team even though the students are geographically co-located. Since 2015, a course adapted from this format has also been taught at the University of New England (UNE), an Australian regional university that is also a longstanding provider of distance education. In this course, most students study online, and the class has to be able to work globally, because as well as students taking part from around Australia, there are also typically a small number of students taking part from overseas. Transferring the course to a smaller but predominantly online institution has allowed us to evaluate the distributed nature of the course, by considering what aspects of the course needed to change to support students who are geographically distributed, and comparing how the two cohorts behave. This has produced an overall course design, to teach professional distributed software engineering practices, that is adaptable from large classes to small, and from local to global.

A learning algorithm for optimizing continuous integration development and testing practice

SummaryContinuous integration, at its core, includes a set of practices that aim to prevent and reduce the cost of software integration issues by merging working software copies often. Regression testing is considered a good practice in software development with continuous integration, which ensures that code changes are not negatively affecting software functionality. As, nowadays, software development is carried out iteratively, with small code increments continuously developed and regression tested, it is of critical importance that continuous regression testing is time efficient. However, in practice, regression testing is often long lasting and faces scalability problems as software grows larger or as software changes are made more frequently. One contributing factor to these issues is test redundancy, which causes the same software functionality being tested multiple times across a test suite. In large‐scale software, especially highly configurable software, redundancy in continuous regression testing can significantly grow the size of test suites and negatively affect the cost effectiveness of continuous integration. This paper presents a practical learning algorithm for optimizing continuous integration testing by reducing ineffective test redundancy in regression suites. The novelty of the algorithm lies in learning and predicting the fault‐detection effectiveness of continuous integration tests using historical test records and combining this information with coverage‐based redundancy metrics. The goal is to identify ineffective redundancy, which is maximally reduced in the resulting regression test suite, thus reducing test time and improving the performance of continuous integration. We apply and evaluate the algorithm in two industrial projects of continuous integration. The results show that the proposed algorithm can improve the efficiency of continuous integration practice in terms of decreasing test execution time by 38% on average compared to the industry practice of our case study and by 40% on average compared to the retest‐all approach. The results further demonstrate no significant reduction in fault‐detection effectiveness of continuous regression testing. This suggests that the proposed algorithm contributes to the state of the practice in the continuous integration development and testing of highly configurable systems.

The continuity of continuous integration: Correlations and consequences

Metrics of the continuity of continuous integration proposed and discussed.Organizational size found to correlate with CI continuity.Evidence of correlation between continuity and organization composition discovered.Findings discussed in the context of architectural styles and manufacturability. The practice of continuous integration has firmly established itself in the mainstream of the software engineering industry, yet many questions surrounding it remain unanswered. Prominent among these is the issue of scalability: continuous integration has been reported to be possible to scale, but with difficulties. Understanding of the underlying mechanisms causing these difficulties is shallow, however: what is it about size that is problematic, which kind of size, and what aspect of continuous integration does it impede? Based on quantitative data from six industry cases encompassing close to 2000 engineers, complemented by interviews with engineers from five companies, this paper investigates the correlation between the continuity of continuous integration and size. It is found that not only is there indeed a correlation between the size and composition of a development organization and its tendency to integrate continuously; there is evidence that the size of the organization influences ways of working, which in turn correlate with the degree of continuity, raising the question of software manufacturability. It is further observed that developer behavior in ostensibly continuously integrating cases does not necessarily match expectations, and that frequent integration of the product itself does not automatically imply that each individual developer commits frequently.

The Tarpit – A general theory of software engineering

ContextRecent years have seen an increasing interest in general theories of software engineering. As in other academic fields, these theories aim to explain and predict the key phenomena of the discipline. ObjectiveThe present article proposes a general theory of software engineering that we have labeled the Tarpit theory, in reference to the 1982 epigram by Alan Perlis. MethodAn integrative theory development approach was employed to develop the Tarpit theory from four underlying theoretical fields: (i) languages and automata, (ii) cognitive architecture, (iii) problem solving, and (iv) organization structure. Its applicability was explored in three test cases. ResultsThe theory demonstrates an explanatory and predictive potential for a diverse set of software engineering phenomena. It demonstrates a capability of explaining Brooks’s law, of making predictions about domain-specific languages, and of evaluating the pros and cons of the practice of continuous integration. ConclusionThe presented theory appears capable of explaining and predicting a wide range of software engineering phenomena. Further refinement and application of the theory remains as future work.

Modeling continuous integration practice differences in industry software development

Continuous integration is a software practice where developers integrate frequently, at least daily. While this is an ostensibly simple concept, it does leave ample room for interpretation: what is it the developers integrate with, what happens when they do, and what happens before they do? These are all open questions with regards to the details of how one implements the practice of continuous integration, and it is conceivable that not all such implementations in the industry are alike. In this paper we show through a literature review that there are differences in how the practice of continuous integration is interpreted and implemented from case to case. Based on these findings we propose a descriptive model for documenting and thereby better understanding implementations of the continuous integration practice and their differences. The application of the model to an industry software development project is then described in an illustrative case study.

Supply chain management practices for improving patient‐oriented care

PurposeThe purpose of the present paper is to discuss organisational problems that occur in situations that are complex because the treatment of patients requires input from multiple health care providers, and to argue conceptually how to resolve these problems by using SCM practices.Design/methodology/approachFirst SCM, being related to settings where several companies contribute to the production of one particular product, will be discussed in general. Since patient care is about service provision, the next to be examined will be service supply chains. Subsequently, major challenges in patient‐oriented care provision follow in settings where several health care providers are involved, based on which opportunities for applying SCM in patient care will be presented.FindingsBased on literature addressing country comparisons of patient experiences, four major problem categories are distinguished: communication, patient safety, waiting times, and integration. Although problems also occur within organisational boundaries, the steps from one provider to the next generally represent the weakest spots in a system of health care providers. By applying insights from SCM, these problems can be tackled.Practical implicationsProblems with communication and integration might well benefit from the nomination of care coordinators. Information gathering and processing, i.e. both the availability of medical records of individual patients and information on provider performance, has to be improved. Breaking down functional barriers between care “silos”, within health care providers as well as inter‐organisationally, is a necessary condition for enhanced patient‐centred integration. Policy should also stimulate the provision of more coordinated services, for example, through integral cost prices for separate diseases (“case‐mixed accounting”).Originality/valueThis paper contributes to the emerging literature on using industrial processes or applying business concepts in health care. More specifically, insights from SCM are presented that contribute to patient‐oriented integration in situations where patients' needs cannot be fulfilled by one single (type of) institute. A supply chain perspective on patient care, combined with cross‐functional and cross‐organisational teams, continuous integration practices, lead time control, and appropriate information technology, shows to be promising.