Implementing agile practices in software development processes promises improvements in product quality and process productivity. However, there are few reports of failures from which to learn, and it is not always clear which practices are effective in specific contexts. This paper investigates how the use of DevOps and agile methodologies affects code quality in open-source projects hosted on GitHub. A total of 57 Java repositories, obtained through queries to the GitHub GraphQL API, were analyzed and categorized into four groups: i) projects that do not use agile nor DevOps, ii) projects that use agile but not DevOps, iii) projects that use both agile and DevOps, and (iv) projects that use DevOps but not agile. The results indicate that the majority of analyzed projects belong to group iii. Furthermore, the absolute number of code smells and their proportion relative to the number of lines of code are highest in group iii, suggesting a positive correlation between the use of both agile and DevOps practices and an increase in code smells.
The CI/CD pipeline configuration is a challenging and error-prone task. Its misconfiguration threatens the project’s security, maintenance, and quality. Such configuration problems called “configuration smells” are patterns in the configuration that, while not necessarily incorrect, indicate potential issues that could compromise the pipeline efficiency, reliability, or security. Detecting these smells is key to managing and addressing them for maintaining high-quality and secure CI/CD workflows. This paper introduces GASH (GitHub Actions Smell Hunter), a Pythonic tool devoted to detecting configuration smells in GitHub Actions CI/CD pipelines. Our tool can detect nine configuration smells categorized into three groups: security (5), maintenance and reliability (3), and code quality (1). GASH provides features to support researchers in performing large-scale studies regarding configuration smells and practitioners in continuously analyzing their own pipelines. We evaluate GASH against a manually labeled “gold standard” based on 15 open-source projects comprising 66 CI/CD pipeline configurations. The results show that GASH performed well, achieving F1-score greater than 0.8 for most configuration smells.
Software development has evolved over decades, transitioning from traditional models such as the waterfall approach and the unified process to more flexible methodologies like agile methods and collaborative development strategies of Free/Libre/Open Source Software (FLOSS) projects. Alongside this trend, the global distribution of software development work has increased. This phenomenon is particularly evident in the development of FLOSS projects, where contributors from various regions worldwide collaborate asynchronously on projects. In this context, the organization of interactions among developers can significantly influence a project success or failure. An example is the Linux kernel community, which has been actively discussing the models and workload of project maintainers – a topic that has received limited attention in scientific literature. This study investigated the new maintenance methods used in the Linux kernel project. With over 30 years of development, the Linux kernel has become a benchmark for FLOSS development. We discuss how the maintainers’ workload is addressed in academic literature and by practitioners in the Linux kernel community. To achieve this, we conducted a multivocal literature review to examine the evolution of maintenance models over the years.
Electronic Shelf Labels are devices used to dynamically display sales price tags and other product information on the retail shop floor. It is an Internet of Things (IoT) technology that defines a new system domain; the Electronic Shelf Labels (ESL) Domain. Developing solutions for this domain is challenging due to the distributed nature of these applications, and the high degree of variabilities and features. Software Product Lines is an approach that is able to model a domain so that one can facilitate the generation of specific products from this domain. Although the development of this kind of application is complex, currently there are no proposed approaches for making the development easier by means of tools/methodologies. The goal of this paper is to present our initial steps towards the definition of a product line for ESL solutions. The approach we are following for domain analysis is based on two main sources: i) white and grey literature and ii) an existing ESL solution. These two sources provide us with theoretical and technical information from the domain. Our preliminary results include a feature diagram and a mapping table that can be used for generating products from the SPL.
