Continuous Integration (CI) and Continuous Delivery (CD) are widespread in both industrial and open-source software (OSS) projects. Recent research characterized build failures in CI and identified factors potentially correlated to them. However, most observations and findings of previous work are exclusively based on OSS projects or data from a single industrial organization. This paper provides a first attempt to compare the CI processes and occurrences of build failures in 349 Java OSS projects and 418 projects from a financial organization, ING Nederland. Through the analysis of 34,182 failing builds (26% of the total number of observed builds), we derived a taxonomy of failures that affect the observed CI processes. Using cluster analysis, we observed that in some cases OSS and ING projects share similar build failure patterns (e.g., few compilation failures as compared to frequent testing failures), while in other cases completely different patterns emerge. In short, we explain how OSS and ING CI processes exhibit commonalities, yet are substantially different in their design and in the failures they report.@en

ING Bank, a large Netherlands-based internationally operating bank, implemented a fully automated continuous delivery pipeline for its software engineering activities in more than 300 teams, that perform more than 2500 deployments to production each month on more than 750 different applications. Our objective is to examine how strong metrics for agile (Scrum) DevOps teams can be set in an iterative fashion. We perform an exploratory case study that focuses on the classification based on predictive power of software metrics, in which we analyze log data derived from two initial sources within this pipeline. We analyzed a subset of 16 metrics from 59 squads. We identified two lagging metrics and assessed four leading metrics to be strong.@en

Continuous Delivery is an agile software develop- ment practice in which developers frequently integrate changes into the main development line and produce releases of their software. An automated Continuous Integration infrastructure builds and tests these changes. Claimed advantages of CD include early discovery of (integration) errors, reduced cycle time, and better adoption of coding standards and guidelines. This paper reports on a study in which we surveyed 152 developers of a large financial organization (ING Netherlands), and investigated how they adopt a Continuous Integration and delivery pipeline during their development activities. In our study, we focus on topics related to managing technical debt, as well as test automation practices. The survey results shed light on the adoption of some agile methods in practice, and sometimes confirm, while in other cases, confute common wisdom and results obtained in other studies. For example, we found that refactoring tends to be performed together with other development activities, technical debt is almost always “self-admitted”, developers timely document source code, and assure the quality of their product through extensive automated testing, with a third of respondents dedicating more than 50% of their time to do testing activities.@en

Recent studies have shown that the violation of the Interface Segregation Principle (ISP) is critical for maintaining and evolving software systems. Fat interfaces (i.e., interfaces violating the ISP) change more frequently and degrade the quality of the components coupled to them. According to the ISP the interfaces' design should force no client to depend on methods it does not invoke. Fat interfaces should be split into smaller interfaces exposing only the methods invoked by groups of clients. However, applying the ISP is a challenging task when fat interfaces are invoked differently by many clients. In this paper, we formulate the problem of applying the ISP as a multi-objective clustering problem and we propose a genetic algorithm to solve it. We evaluate the capability of the proposed genetic algorithm with 42,318 public Java APIs whose clients' usage has been mined from the Maven repository. The results of this study show that the genetic algorithm outperforms other search based approaches (i.e., random and simulated annealing approaches) in splitting the APIs according to the ISP.@en

Analyzing the Change-Proneness of APIs and web APIs APIs and web APIs are used to expose existing business logic and, hence, to ease the reuse of functionalities across multiple software systems. Software systems can use the business logic of legacy systems by binding their APIs and web APIs. With the emergence of a new programming paradigm called service-oriented, APIs are exposed as web APIs hiding the technologies used to implement legacy systems. As a consequence, web APIs establish contracts between legacy systems and their consumers and they should stay as stable as possible to not break consumers’ systems. This dissertation aims at better understanding the change-proneness of APIs and web APIs. Specifically to that end, we investigated which indicators can be used to highlight change-prone APIs and web APIs and we provided approaches to assist practitioners in refactoring them. To perform this analysis we adopted a research approach consisting of three different tracks: analysis of change-prone APIs, analysis of change-prone web APIs, and refactoring of change-prone APIs and web APIs. Change-Prone APIs Service-oriented systems are composed by web services. Each web service is implemented by an implementation logic that is hidden to its clients through its web APIs. Along the history of a software system the implementation logic can be changed and its changes can be propagated and affect web APIs. Among all the software units composing the implementation logic, APIs are likely to be mapped directly into web APIs. This scenario is likely to happen especially if a legacy API is made available through a web service. In this first track we focused on analyzing the change-proneness of APIs (i.e., the set of public methods declared in a software unit). Among all the metrics we analyzed, we have shown that the Interface Usage Cohesion (IUC) metric is the most suitable metric to highlight change-prone Java interfaces. This result suggests that software engineers should design interfaces with high external cohesion (measured with the IUC metric) to avoid frequent changes. Moreover, we analyzed the impact of specific antipatterns on the changeproneness of APIs. We showed empirically that changes to APIs are more likely to appear if APIs are affected by the ComplexClass, SpaghettiCode, and SwissArmyKnife antipatterns. As a consequence software engineers should refactor APIs affected by these antipatterns. Change-Prone Web APIs In the second track we analyzed the change-proneness of web APIs. First, we developed two tools to analyze software systems composed of web APIs. The first tool is called WSDLDiff and extracts fine-grained changes between subsequent versions of WSDL APIs. The second tool extracts the full chains of dependencies among web APIs at run time. Second, we performed an empirical study to investigate which scenarios can cause changes to web APIs. We showed that low externally cohesive APIs change frequently to 1) improve understandability and 2) ease maintainability and reduce clones in the APIs. Low internally cohesive APIs change frequently to 1) reduce the impact of changes on the many clients they have, 2) avoid that all the clients lead the APIs to be changed frequently, and 3) improve understandability. Moreover, we proposed a new internal cohesion metric (DTC) to measure the internal cohesion of WSDL APIs. Refactoring APIs and Web APIs Based on the results of the studies performed in the first and second track, we defined two approaches to refactor APIs and web APIs. The first approach assists software engineers in refactoring APIs with low external cohesion based on the Interface Segregation Principle (ISP). We defined the problem of splitting low externally cohesive APIs into smaller APIs specific for each client (i.e., ISP) as a multi-objective clustering optimization problem. To solve this problem we proposed a genetic algorithm that outperforms other search based approaches. The second approach assists software engineers in refactoring fine-grained web APIs. These APIs should be refactored into coarse-grained web APIs to reduce the number of remote invocations and avoid performance problems. To achieve this goal we proposed a genetic algorithm that looks for Façade APIs that cluster together the fine-grained methods of the original API. Conclusion We believe that these results advance the state-of-the-art in designing, analyzing, and refactoring software systems composed of web APIs (i.e., serviceoriented systems) and provide to the research community new insights into the change-proneness of APIs and web APIs.@en