In mature software development organizations the ci/cd pipeline is the only route to deploy software into production. While the workflow of this process seems straightforward, the reality is different since exceptions and deviations are the norm in actual industry practice. In this context, Process Mining appears as a promising technique to uncover deviations and check compliance with standardized DevOps processes, and highlight bottlenecks and potential improvement areas. This paper presents a case study designed to assess the potential of using Process Mining techniques to provide visibility into the deployment pipeline. This research uses raw event data extracted from the continuous practices toolchain, which is then used to compute a comprehensive set of DevOps-specific metrics, thus supporting objective monitoring of the quality and efficiency of the deployment workflow. The study focuses on different development units in the Engineering team, each working in a distinct business context but sharing standard practices. We verified that even though there are standards for the deployment pipelines, each team’s workflow denotes local variations with unique points for improvement that are highly coupled to their business unit context. We observed that each team’s pipeline has different temporal profiles that reflect their context and work practices. Additionally, we identified a set of deployment pipeline metrics focusing on process compliance, efficiency, and deployment stability. The main contributions of this paper include (1) the description of an actual application of Process Mining to the deployment pipeline of a highly complex e-commerce platform, (2) how this approach provided an objective understanding of the efficiency and quality of the development workflow, (3) how this process-centric view, combined with domain-specific DevOps metrics, supports continuous practices, and (4) how Developers can analyse their workflows by applying Process Mining while using standard tools like GitLab and PM4Py.

Through software analytics, raw data with low value originates information that is valuable and able to provide insights, enabling the support of claims that would otherwise not be possible to verify. The software development ecosystem has plenty of sources that can help understanding the quality of processes and products but, to reach that goal, it is necessary to collect and store the data. This paper describes an infrastructure to allow the collection, storage and analysis of data from software repositories. The scope of the research is an industrial case study, which encompasses several specificities: tools and work methodology. The current solution is able to collect information from the continuous delivery & deployment pipeline, which includes data sources such as the source code repository (SVN), the static analysis tool (SonarQube), the continuous integration server (from Jenkins jobs) and the continuous testing tool (an in-house tool called Cerberus). Future work also includes the implementation of components that will allow the collection of unstructured data from the bug-tracking system and incident management tool. As stated in the literature, correlating the history of issues and incidents will allow the team to address, or at least identify, areas of improvement.

Exception-handling structures provide a means to recover from unexpected or undesired flows that occur during software execution, allowing the developer to put the program in a valid state. Still, the application of proper exception-handling strategies is at the bottom of priorities for a great number of developers. Studies have already discussed this subject pinpointing that, frequently, the implementation of exception-handling mechanisms is enforced by compilers. As a consequence, several anti-patterns about Exception-handling are already identified in literature. In this study, we have picked several releases from different Java programs and we investigated one of the most well-known anti-patterns: the empty catch handlers. We have analysed how the empty handlers evolved through several releases of a software product. We have observed some common approaches in terms of empty catches' evolution. For instance, often an empty catch is transformed into a empty catch with a comment. Moreover, for the majority of the programs, the percentage of empty handlers has decreased when comparing the first and last releases. Future work includes the automation of the analysis allowing the inclusion of data collected from other software artefacts: test suites and data from issue tracking systems.

One characteristic that impedes software from achieving good levels of maintainability is the increasing complexity of software. Empirical observations have shown that typically, the more complex the software is, the bigger the test suite is. Thence, a relevant question, which originated the main research topic of our work, has raised: "Is there a way to correlate the complexity of the test cases utilized to test a software product with the complexity of the software under test?". This work presents a new approach to infer software complexity with basis on the characteristics of automatically generated test cases. From these characteristics, we expect to create a test case profile for a software product, which will then be correlated to the complexity, as well as to other characteristics, of the software under test. This research is expected to provide developers and software architects with means to support and validate their decisions, as well as to observe the evolution of a software product during its life-cycle. Our work focuses on object-oriented software, and the corresponding test suites will be automatically generated through an emergent approach for creating test data named as Evolutionary Testing.