In this paper, we study the benefits and challenges of monitoring Continuous Integration (CI) practices in software development. Our aim is to evaluate the impact of monitoring seven CI practices in industry using three organizations in Brazil as case studies. We developed a tool for monitoring CI practices and conducted a multiple case study, applying a mixedmethods strategy. We combined surveys, interviews, log data, and repositories data from software projects and their CI services. We gauged the organization's interest in monitoring CI practices. The act of monitoring CI provided an overview of the organizational state of practice in terms of CI, motivated further improvement of CI practices, increased perceived quality of software, and improved project communication. We recommend that companies adopt the practice monitoring of CI practices and that CI services integrate monitoring functionalities into their dashboards.

Background: Much research has been conducted to investigate the impact of Continuous Integration (CI) on the productivity and quality of open-source projects. Most of studies have analyzed the impact of adopting a CI server service (e.g, Travis-CI) but did not analyze CI sub-practices. Aims: We aim to evaluate the impact of five CI sub-practices with respect to the productivity and quality of GitHub open-source projects. Method: We collect CI sub-practices of 90 relevant open-source projects for a period of 2 years. We use regression models to analyze whether projects upholding the CI sub-practices are more productive and/or generate fewer bugs. We also perform a qualitative document analysis to understand whether CI best practices are related to a higher quality of projects. Results: Our findings reveal a correlation between the Build Activity and Commit Activity sub-practices and the number of merged pull requests. We also observe a correlation between the Build Activity, Build Health and Time to Fix Broken Builds sub-practices and number of bug-related issues. The qualitative analysis reveals that projects with the best values for CI sub-practices face fewer CI-related problems compared to projects that exhibit the worst values for CI sub-practices. Conclusions: We recommend that projects should strive to uphold the several CI sub-practices as they can impact in the productivity and quality of projects.

This paper presents an exploratory study that analyzes the complexity to integrate existing merge conflicts of a cloned large-scale web system.The study is supported by an existing tool that focuses on the identification of merge conflicts that can arise during the integration of cloned systems.The approach addresses the merge conflict analysis through the extraction and comparison of the issues and code history of cloned systems using mining software repository and static analysis techniques.The main aims of our study are: (i) to quantify the kind of conflicts defined by our approach that happen when evolving cloned systems; (ii) to evaluate if they are being correctly detected by our tool; and finally (iii) to analyze the difficult to integrate them from one cloned system to another.The study findings show: (i) a predominance of semantic conflicts between issues of source and target cloned systems; and (ii) the feasibility to use merge analysis approaches to integrate tasks from one clone to another.Clone-and-own approach, web-based information systems, software merge, code merge conflicts I.

Software product line engineering is about producing a set of related products that share more commonalities than variabilities. This approach promotes benefits such as cost reduction, product quality, productivity and time to market, but it brings new challenges that must be considered during the evolution of the software product line. In this context, recent research has explored and proposed automated approaches based on code analysis and traceability techniques for change impact analysis. This paper presents Squid, an extensible infrastructure for analyzing software product line implementations. The approach uses information from variability modeling, variability mapping to code assets, and dependency relationships between code assets to perform analysis of SPL implementations. A Squid instantiation example is presented to illustrate the usage of the tool in practical scenarios.