Search

DevOps, an advanced software engineering methodology widely adopted in the software development industry, facilitates the rapid release of features and versions to production environments. The term "DevOps" is a fusion of "Development" and "Operations." It is implemented through a series of processes known as Continuous Integration and Continuous Delivery, which form the core of DevOps operations. Continuous Integration involves the seamless integration of small code increments into the version control system. This practice initiates a continuous integration environment where ongoing code changes are merged and tested. To optimize this environment, the study and analysis of related metrics are essential. The primary goal of this research is to identify interdependent key metrics that significantly influence the outcomes of builds within a continuous integration environment. This study introduces four interdependent metrics relevant to the continuous integration environment, positively impacting its effectiveness. A set of rules is derived, and a hypothesis is formulated, substantiating the interdependence of these metrics. To validate the metric rules and their association with build success a hybrid LSTM-GRU model is employed. CI build outcome data exhibits temporal dependencies and a sequential nature, making it suitable for time series analysis. Leveraging time series techniques can provide valuable insights into the dynamics of the CI process, enabling better decision-making and optimization of software development workflows. So we introduce hybrid LSTM-GRU model for predicting the build outcome and validating the DKMR. The analysis underscores that metrics such as TSC (Time between Successive Commits), BBFT (Build Breakage Fixing Time), LC (Long Commit), and BT (Build Time) are mutually dependent and have a constructive influence on build outcomes. In culmination, an algorithm called the "Dynamic Build Success Optimization Algorithm," based on these interdependent key metrics, has been developed. This algorithm is designed to enhance the efficiency and reliability of the continuous integration environment, contributing to the overall success of DevOps practices. [ABSTRACT FROM AUTHOR]

Summary: Continuous integration and continuous delivery (CI/CD) automate software integration and reduce repetitive engineering work. While the use of CI/CD presents efficiency gains, in database application development, this potential has not been fully exploited. We explore the state of the art in this area, with a focus on current practices, common software tools, challenges, and preconditions that apply to database applications. The work is grounded in a synoptic literature review and contributes a novel generic CI/CD pipeline for database system application development. Our generic pipeline was tailored to three industrial development use cases in which we measured the benefits of integration and deployment automation. The measurements demonstrate clearly that introducing CI/CD had significant benefits. It reduced the number of failed deployments, improved their stability, and increased the number of deployments. Interviews with the developers before and after the implementation of the CI/CD show that the pipeline brings clear benefits to the development team (i.e., a reduced cognitive load). These findings put current database release practices driven by business expectations, such as fixed release windows, in question. While the use of continuous integration and continuous delivery (CI/CD) presents efficiency gains, in database application development, this potential has not been fully exploited. We explore the state of the art in this area, with a focus on current practices, common software tools, challenges, and preconditions that apply to database applications. The work is grounded in a synoptic literature review and contributes a novel generic CI/CD pipeline for database system application development. [ABSTRACT FROM AUTHOR]

The software development cycle involves testing and deployment stages that can be laborious and time consuming, especially in collaborative projects that involve several developers. Implementing Continuous Integration (CI) and Continuous Delivery (CD) offers a solution to streamline this process. This study presents a case study of the Cloversy.id RESTful API project, highlighting challenges encountered during development and the implementation of a new system using GitHub Actions as the DevOps tool. The research resulted in the adoption of a new system, which replaces the conventional practices previously employed by the Cloversy.id development team. Using flow charts, the study meticulously mapped out the development flow, pinpointing bottlenecks and areas for optimization within the cycle. In particular, the implementation of a CI/CD pipeline resulted in a notable improvement, with a 35% increase in speed for CI and a remarkable 39% enhancement for CD. GitHub Actions played a pivotal role in automating critical tasks, reducing the reliance on manual intervention, and minimizing the dependency on team leaders. The platform's features, including detailed logs and email notifications, empowered team leaders and developers alike to take informed actions swiftly. Furthermore, the study highlights the novelty of integrating CI / CD considering factors such as branching strategy, code review practices, testing methodologies, deployment methods, and infrastructure.

Background: Double‐blind studies have demonstrated that motor complications in Parkinson's disease (PD) can be reduced with continuous delivery of levodopa. The DopaFuse system is a novel, intraoral micropump that attaches to a retainer and uses a propellant to deliver levodopa/carbidopa (LD/CD) continuously into the mouth. Objectives: Evaluate the safety, pharmacokinetics, and efficacy of LD/CD delivered via the DopaFuse system compared to treatment with intermittent doses of standard oral LD/CD in PD patients with motor fluctuations. Methods: This was a 2‐week, open‐label study (NCT04778176) in 16 PD patients treated with ≥4 levodopa doses/day and experiencing motor fluctuations. On Day 1 (clinic setting) patients received their usual dose of standard LD/CD; DopaFuse therapy was initiated on Day 2, and on Day 3 patients received DopaFuse plus a morning oral LD/CD dose. Patients returned home on Days 4–14 and returned for in‐clinic assessment on Day 15. Results: Continuous DopaFuse delivery of LD/CD was associated with reduced variability in plasma levodopa levels compared to oral LD/CD (mean ± SD levodopa Fluctuation Index reduced from 2.15 ± 0.59 on Day1 to 1.50 ± 0.55 on Day 2 (P = 0.0129) and to 1.03 ± 0.53 on Day 3 (P < 0.0001)). This pharmacokinetic improvement translated into significantly reduced OFF time with DopaFuse therapy (reduction of −1.72 ± 0.37 h at Day 15; P = 0.0004) and increased ON time without severe dyskinesias (increase of 1.72 ± 0.37 h at Day 15; P = 0.0004) versus oral LD/CD administration. DopaFuse therapy was not associated with any clinically significant adverse events. Conclusions: Continuous delivery of LD/CD using the DopaFuse system was associated with significantly less variability in plasma levodopa concentrations and reductions in OFF time compared to treatment with standard oral LD/CD therapy and was well tolerated. © 2024 International Parkinson and Movement Disorder Society. [ABSTRACT FROM AUTHOR]

Atoms of Confusion (AoC) are indivisible code patterns that may confuse developers when trying to understand them, and that have less confusing equivalent patterns. Previous works suggest it is a good practice to avoid them. While there are studies on AoC relating them to bugs, there is not much about their relationship with the practices of Continuous Integration and Continuous Delivery (CI/CD). Since CI/CD is generally praised as a group of good practices, related to better code being released reliably and faster to clients, there is a possibility that the presence of CI/CD would also impact the presence of AoC, possibly making them less prevalent since they can be problematic to development processes. To clarify this relationship, we analyzed 10 open-source long-lived Java libraries and 10 open-source Java projects for Android, to see if there was any difference in the AoC rate, diffusion, and density before and after the implementation of CI/CD when comparing each project, the average total. We also analyzed the atoms separately, checking for the most and least prevalent. Our results show the metrics have considerably changed for all projects when checked separately, and less so on average, but we could not find a statistically relevant relationship between most of these changes and CI/CD. We found a significant relation when checking the growth rate on one of the metrics. We also found that the most prevalent atom is the Logic as Control Flow, and the least is the Arithmetic as Logic. [ABSTRACT FROM AUTHOR]

Continuous integration and continuous deployment (CI/CD) are best practices for automating the software development process. People leverage them to ensure rapid iteration and delivery of product development. The rapid lifecycle makes traditional security management vulnerable to its lack of agility, exposing the urgent need to put security into DevOps processes. Development, security, and operation, quoted as DevSec Ops, advocates shift-left security, promotes people to implant security best practices into all DevOps stages, and builds continuous security analysis, testing, and management with automation. Based on CI/CD, this study defines continuous security practices and applies application security processes on a DevSecOps pipeline to implement shift-left security. The CodeHawk platform, based on the proposed secure pipeline and open source software, is developed to free the development team from testing manually, enable them to focus on development, gain the corresponding security assurance, and lower the operating costs. Experiments show that our DevSecOps pipeline design significantly improves the efficiency of the DevSecOps process. [ABSTRACT FROM AUTHOR]

Saat ini setiap organisasi membutuhkan aplikasi untuk memberikan layanan pada pelanggan mereka. Faktanya, 62% organisasi mengatakan aplikasi itu penting untuk bisnis mereka, dan 36% lebih lanjut mengatakan aplikasi memberikan keunggulan kompetitif. Hal ini membuat perusahaan dituntut untuk memberikan inovasi secara cepat demi memberikan kepuasan dan kenyamanan bagi pelanggannya. Untuk merespons tuntutan tersebut, maka organisasi perlu melakukan pengiriman pembaruan aplikasi lebih sering. Dalam proses pengiriman tradisional, setiap proses pengiriman dimulai dengan persyaratan yang ditentukan oleh pelanggan dan berakhir pada produksi. Kelemahan pada pengiriman tradisional adalah lambannya proses pengiriman, dimana proses pengiriman dilakukan secara manual dan berbasis langkah berpotensi menyebabkan titik kegagalan serta kesalahan manusia yang berdampak pada penundaan atau penghentian total sistem. Teknik Countinuous Delivery hadir untuk membantu organisasi mempercepat proses pengiriman aplikasi mereka ke pelanggan. Salah satu perangkat lunak yang dapat digunakan untuk membangun Continuous Delivery dengan zero-downtime adalah Ansible. Berdasarkan hasil pengujian, Ansible berhasil menjaga ketersediaan layanan dengan persentase uptime sebesar 100%. Serta mampu mempercepat waktu deployment sebesar 48%. Dari pengujian beban didapatkan bahwa 1 buah server mampu menangani beban sebesar 2000 user per 5 menit dengan persentase keberhasilan sebesar 99%.

Purpose: The purpose of this work is to draw future research directions on how to ease adoption of continuous delivery (CD) for business-to-business (b2b) critical infrastructure products. CD is a recognized software lifecycle management practice reducing go-to-market time, strengthening customer feedback loop, and improving product quality. Telecommunication networks, considered critical infrastructure, are sensitive to changes in delivery models. Design/methodology/approach: Literature review was performed by combining bibliometric analysis and the own model gauging telecom software vendors’ interest in shaping CD practices across the industry. Findings: The research is skewed toward engineering practices excellence. Little is spent on the customer challenges. Transformation slowdowns are attributed to product teams. Research limitations/implications: Some software vendors, especially smaller ones, may prefer not to publish the outcomes before validating them with the customers. This work looked at publicly available materials therefore not capturing the picture of internal corporate experimentation on continuous delivery. Practical implications: Scientists should seek access to customer perspective. Sales, services, and business managers may be invaluable proxies of such information. Originality/value: This work nudges the community to shift focus from R&D excellence to change management at customer interface, and to deal with CD model industrialization aspects. [ABSTRACT FROM AUTHOR]

Software architecture is critical in succeeding with Development and Operations (DevOps). However, designing software architectures that enable and support DevOps (DevOps‐driven software architectures) is a challenge for organizations. We assert that one of the essential steps towards characterizing DevOps‐driven architectures is to understand architectural design issues raised in DevOps. At the same time, some of the architectural issues that emerge in the DevOps context (and their corresponding architectural practices or tactics) may stem from the context (i.e., domain) and characteristics of software organizations. To this end, we conducted a mixed‐methods study that consists of a qualitative case study of two teams in a company during their DevOps transformation and a content analysis of Stack Overflow and DevOps Stack Exchange posts to understand architectural design issues in DevOps. Our study found eight specific and contextual architectural design issues faced by the two teams and classified architectural design issues discussed in Stack Overflow and DevOps Stack Exchange into 11 groups. Our aggregated results reveal that the main characteristics of DevOps‐driven architectures are being loosely coupled and prioritizing deployability, testability, supportability, and modifiability over other quality attributes. Finally, we discuss some concrete implications for research and practice. [ABSTRACT FROM AUTHOR]

The characteristics of the test environment are of vital importance to its ability to support the organizations testing objectives. This paper seeks to address the need for a structured and reliable approach, which can be used by companies and other organizations to optimize their test environments in each individual case. The reported study included a series of interviews with 30 individuals, a series of focus groups with in total 31 individuals and a cross‐company workshop with 30 participants from five large‐scale companies, operating in different industry segments. The study resulted in a list of success factors, including not only characteristics and capabilities existing within a test environment (intrinsic success factors) but also properties not inherent to the test environment, but still vital for a successfully implemented test environment (extrinsic success factors). This distinction is important, as the root causes differ and as addressing them requires distinct approaches—not only of technology but also of organization, communication and collaboration. We find that successful implementations of test environments for large‐scale software systems depend primarily on how they support the company's business strategy, test organization and product testability (extrinsic success factors). Based on this, test environments can then be optimized to improve test environment capabilities, usability and stability (intrinsic success factors). The list of intrinsic and extrinsic success factors was well received by all five companies included in the study, supporting that the intrinsic and extrinsic success factors for test environments can be applied to a large segment of the software industry. [ABSTRACT FROM AUTHOR]

The majority of enterprises today still maintain their mission-critical systems with their outdated on-premises apps. These outdated on-premises (legacy) systems do, however, have a number of serious flaws, including maintainability and scalability problems. With reference to this, the businesses using cloud services provide a more flexible and costefficacious platform solution for fortifying many immensely colossal business applications and IT infrastructure. Due to increased academic research on cloud migration, cloud adoption also increases. The purpose of this study is to identify, organize, and compare current research work in the field of on-premises to cloud migration in a scientific and methodical manner. The role of the CI/CD pipeline in cloud migration is also discussed in this paper. The cloud migration provides numerous benefits for CI/CD. CI/CD tools helps to make development, operations, testing/quality assurance, and security easier for IT teams. [ABSTRACT FROM AUTHOR]

Although software development teams increasingly use Platform-as-a-Service (PaaS), a minimal amount is known regarding the impact of PaaS on software development. We explored the impact of PaaS on software development through a grounded-theory study, conducting 48 interviews in 16 teams. The data turned our attention to the affordances, or potentials for action, that PaaS provides to software development teams. Two key affordances emerging from our data analysis were self-organizing and triggering continuous feedback. Actualizing these affordances helped accelerate the collective learning processes that underlie software development, thus supporting software development teams in their quest for agility. Our emerging theory explains how, why, and when these affordances arise. The key contribution of our paper lies in unveiling how the use of cloud computing technology can transform technology-mediated collective learning activities by helping to remove barriers to rapid feedback. Our findings also imply that organizations can leverage PaaS to facilitate the transition to agile and continuous software development practices, in particular in conjunction with cross-functional team designs. [ABSTRACT FROM AUTHOR]

Over the past few decades, the substantial growth in enterprise-data availability and the advancements in Artificial Intelligence (AI) have allowed companies to solve real-world problems using Machine Learning (ML). ML Operations (MLOps) represents an effective strategy for bringing ML models from academic resources to useful tools for solving problems in the corporate world. The current literature on MLOps is still mostly disconnected and sporadic. In this work, we review the existing scientific literature and we propose a taxonomy for clustering research papers on MLOps. In addition, we present methodologies and operations aimed at defining an ML pipeline to simplify the release of ML applications in the industry. The pipeline is based on ten steps: business problem understanding, data acquisition, ML methodology, ML training & testing, continuous integration, continuous delivery, continuous training, continuous monitoring, explainability, and sustainability. The scientific and business interest and the impact of MLOps have grown significantly over the past years: the definition of a clear and standardized methodology for conducting MLOps projects is the main contribution of this paper.

DevOps paradigm is widely used in industry to develop software faster, deploy high quality frequent releases of features by integrating and harmonizing the Development and IT Operations activities. Industries are taking strategic decisions to remove the barriers that existed between Development and Operational teams by encouraging collaborations among these teams throughout System Development Life Cycle (SDLC). These strategic decisions to implement DevOps paradigm resulted in the development and emergence of large arrays of tool chains to support, monitor, and automate activities of various SDLC stages. In this paper authors attempt to give practical insights on how the using of DevOps can speed up the management, development and deployment process of a simple web application. Widely used DevOps model consisting of eight stages is used to implement the example application. A toolchain consisting of state of arts tools is used at various DevOps stages. A detailed explanation of each tool, including details to their implementation and a short evaluation concludes the study. The results revealed that the usage of DevOps enables to accelerate the development process of web applications, as most steps during the build and testing process can be automated. Especially the outsourcing of operational overhead to an external cloud provider can lead to economic advantages, which will impact the future of software development. [ABSTRACT FROM AUTHOR]

This article presents a process to encourage and support the adoption of DevOps in small and medium software companies. The process was designed through the identification of elements suggested and identified in the literature through systematic mapping. The identified elements were harmonized, compared and integrated, resulting in a clear, homogeneous process without terminological conflicts composed of three sub-processes, roles, activities, artifacts, tools and process flows in BPMN as support for configuration management, integration, continuous deployment and monitoring from a fundamental and complementary approach of suggested practices. The proposed process was evaluated through a focus group made up of DevOps experts, who considered that the process is pertinent, clear, complete and applicable in small and medium-sized software companies. In short, the process describes a total of 82 activities, 16 artifacts, 9 roles and recommends 13 technological tools to support the automation of each of the activities related to each thread, which will guide professionals, companies and stakeholders to reduce the ambiguity and subjectivity in the understanding and adoption of DevOps. [ABSTRACT FROM AUTHOR]

Lately, the software development industry is going through a slow but real transformation. Software is increasingly a part of everything, and, software developers, are trying to cope with this exploding demand through more automation. The pipelining technique of continuous integration (CI) and continuous delivery (CD) has developed considerably due to the overwhelming demand for the deployment and deliverability of new features and applications. As a result, DevOps approaches and Agile principles have been developed, in which developers collaborate closely with infrastructure engineers to guarantee that their applications are deployed quickly and reliably. Thanks to pipeline approach thinking, the efficiency of projects has greatly improved. Agile practices represent the introduction to the system of new features in each sprint delivery. Those practices may contain well-developed features or can contain bugs or failures which impact the delivery. The pipeline approach, depicted in this paper, overcomes the problems of delivery, improving the delivery timeline, the test load steps, and the benchmarking tasks. It decreases system interruption by integrating multiple test steps and adds stability and deliverability to the entire process. It provides standardization which means having an established, time-tested process to use, and can also decrease ambiguity and guesswork, guarantee quality and boost productivity. This tool is developed with an interpreted language, namely Bash, which offers an easier method to integrate it into any platform. Based on the experimental results, we demonstrate the value that this solution currently creates. This solution provides an effective and efficient way to generate, manage, customize, and automate Agile-based CI and CD projects through automated pipelines. The suggested system acts as a starting point for standard CI/CD processes, caches Docker layers for subsequent usage, and implements highly available deliverables in a Kubernetes cluster using Helm. Changing the principles of this solution and expanding it into multiple platforms (windows) will be addressed in a future discussion. [ABSTRACT FROM AUTHOR]

This paper is focused on the process of continuous integration and respective orchestration tooling. It provides a summary on existing tooling with feature analysis and applications. The research explores techniques, processes, and solutions for code orchestration. It includes a comparison of the modern platforms and discusses the topic of extendibility of such products by presenting an architectural model that supports the integration of general-purpose extensions. [ABSTRACT FROM AUTHOR]

A build manager is a tool used to automate the building, testing and delivery of software projets. Porion is a new build manager that was first presented at the FOSDEM 2022 event in the "Continuous Integration and Continuous Deployment Developer Room" [1] and in the "Ada Developer Room" [2]. This paper is a summary of these two presentations and it focuses on the complexity of designing a build manager. It highlights some security issues that apply to a build manager and its implementation. It explains the overall architecture that was chosen and the reason of the choice. Finally it presents the Ada generation tools that have been used in this project. [ABSTRACT FROM AUTHOR]

DevOps, the widely used term in software industry, integrates the Development and IT Operations activities to frequently deliver, deploy, and release quality software features. DevOps approach emphasizes collaboration among Developments and IT operations teams throughout System Development Life Cycle (SDLC). The DevOps process is supported by wide variety of tool chains for various phases of SDLC. There exist many DevOps models. However, in this paper authors use a simple four phase pedagogical models to demonstrate principles of DevOps. In this paper authors attempt to show how DevOps principles can effectively be used to manage and implement business problems in classroom setting. Specifically, DevOps methodology is applied to manage develop and implement a small web application. This pedagogical approach is specially aimed at students who do not have prior experiences and skillsets in applying DevOps methodology and associated toolsets to every stages of SDLC. At the conclusion of the project, students gained valuable insights on how to apply DevOps principles to business problems and to select and use commonly used state of the arts tools to plan, manage, build, test, monitor, deploy tasks at every stages of DevOps. The authors also discuss the limitations and practical issues related to implementing DevOps within classroom settings. [ABSTRACT FROM AUTHOR]