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]

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]

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]

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]

The discipline of enterprise architecture (EA) is an established approach to model and manage the interaction of business processes and IT in an organization. Thereby, the EA model as a central artifact of EA is subject to a continuous evolution caused by multiple sources of changes. The continuous evolution requires a lot of effort in controlling and managing the evolution of the EA model. This is especially true when merging the induced changes from different sources in the EA model. Additionally, the lack of tool and automation support makes this a very time-consuming and error-prone task. The evolutionary character and the automated quality assessment of artifacts is a well-known challenge in the software development domain as well. To meet these challenges, the discipline of continuous delivery (CD) has emerged to be very useful. The evolution of EA model artifacts shows similarities to the evolution of software artifacts. Therefore, we leveraged practices of CD to practices of EA maintenance. Thus, we created a conceptual framework for automated EA model maintenance. The concepts were realized in a first prototype and were evaluated in a fictitious case study against equivalence classes based on EA model metrics and a set of several requirements for automated EA model maintenance from research. Overall, the concepts prove to be a promising basis for further refinement, implementation, and evaluation in research in an industrial context. [ABSTRACT FROM AUTHOR]

Background: Extensive scientific and clinical evidence indicates that continuous delivery of a dopaminergic agent is associated with significant reduction in motor complications compared with intermittent oral dosing with the same agent. There has been an intensive effort to develop a method of providing continuous plasma levels of a dopaminergic agent that avoids the need for surgical therapy or an infusion system. Studies in MPTP-treated monkeys demonstrate that once-weekly injections of polymer-linked rotigotine provide continuous plasma levels and antiparkinsonian benefits.Methods: We performed a multicenter open-label, multiple-ascending-dose-ranging cohort study to evaluate the safety, tolerability, and pharmacokinetics of polymer-linked rotigotine in PD patients.Results: A total of 19 patients were evaluated in 4 cohorts in doses of 20 50, 100, and 200 mg of polymer-linked rotigotine, administered subcutaneously once weekly. The study demonstrated remarkably stable dose-related plasma levels of total and free rotigotine with no accumulation or dumping. Treatment was generally safe and well tolerated. One subject in the 50-mg group discontinued because of hives, which cleared rapidly with antihistamine treatment.Conclusions: This study demonstrates that once-a-week subcutaneous administration of polymer-linked rotigotine provides relatively constant plasma levels of rotigotine and is safe and well tolerated. These findings suggest that this convenient method of delivery of rotigotine has the potential to treat or prevent motor complications in PD patients without the need for a surgical procedure or an infusion system. This approach may also prove applicable to other agents such as apomorphine that can be linked to this polymer © 2020 International Parkinson and Movement Disorder Society. [ABSTRACT FROM AUTHOR]

This article explores applying User-Experience (UX) research and a software development approach called Continuous Delivery (CD) to the process of designing, developing, and maintaining online courses. We will illustrate how readers can use our PARS (personal, accessible, responsive, strategic) framework, UX best practices, and CD to create more accessible content for the users of their online courses. [ABSTRACT FROM AUTHOR]

As part of a Finnish research program, researchers interviewed 15 information and communications technology companies to determine the extent to which the companies adopted continuous deployment. They also aimed to find out why continuous deployment is considered beneficial and what the obstacles are to its full adoption. The benefits mentioned the most often were the ability to get faster feedback, the ability to deploy more often to keep customers satisfied, and improved quality and productivity. Despite understanding the benefits, none of the companies adopted a fully automatic deployment pipeline. The companies also had higher continuous-deployment capability than what they practiced. In many cases, they consciously chose to not aim for full continuous deployment. Obstacles to full adoption included domain-imposed restrictions, resistance to change, customer desires, and developers' skill and confidence. [ABSTRACT FROM PUBLISHER]

Three release engineers share their perspectives on quality metrics for releases and on continuous delivery's benefits and limitations. They also discuss release-engineering job skills, the required mind-set, the role of education, and cultural change, and they recommend future research areas. The Web extra at http://youtu.be/O3cJQTZXAI8 is an audio recording of Davide Falessi speaking with Guest Editors Bram Adams and Foutse Khomh about release engineering and its value to the software industry. [ABSTRACT FROM PUBLISHER]

Continuous delivery (CD) has emerged as an auspicious alternative to traditional release engineering, promising to provide the capability to release valuable software continuously to customers. Paddy Power has been implementing CD for the past two years. This article explains why Paddy Power decided to adopt CD, describes the resulting CD capability, and reports the huge benefits and challenges involved. These experiences can provide fellow practitioners with insights for their adoption of CD, and the identified challenges can provide researchers valuable input for developing their research agendas. [ABSTRACT FROM PUBLISHER]

Continuous delivery and deployment are dramatically shortening release cycles from months to hours. Cloud applications with high-frequency releases often rely heavily on automated tools and cloud infrastructure APIs to deploy new software versions. The authors report on reliability issues and how these tools and APIs contribute to them. They also analyze the trade-offs between using heavily baked and lightly baked virtual-image approaches, on the basis of experiments with Amazon Web Service OpsWorks APIs and the Chef configuration management tool. Finally, they propose error-handling practices for continuous-delivery facilities. [ABSTRACT FROM PUBLISHER]

“Lean Software Development” has become a popular term over the last few years. This tutorial describes where it comes from, what it means, how it relates to well-known agile development practices, and how it will evolve in the future. [ABSTRACT FROM PUBLISHER]

Abstract: We previously showed that continuous infusion of rotigotine resulted in less dyskinesia than repeated pulsatile rotigotine administration or repeated oral administration of l-DOPA in MPTP-treated marmosets. Now we investigate whether continuous rotigotine delivery modifies established dyskinesia induced by prior exposure to repeated pulsatile administration of l-DOPA or rotigotine in MPTP-treated common marmosets. Repeated oral administration of l-DOPA or subcutaneous bolus administration of rotigotine over 28 days improved motor deficits but resulted in the onset of dyskinesia of moderate intensity. When these animals were switched to a 28-day continuous infusion of rotigotine, the reversal of motor disability was maintained. In those animals initially treated with l-DOPA, there was a small reduction in dyskinesia intensity but a significant reduction in the duration of dyskinesia. However, in animals initially treated with repeated bolus administration of rotigotine, dyskinesia intensity was significantly reduced. Initial treatment with a continuous infusion of rotigotine for 28 days reversed motor disability and resulted in a low incidence of dyskinesia. On switching to repeated oral administration of l-DOPA, the improvement in motor disability was maintained but the propensity of l-DOPA to provoke dyskinesia was not affected. In addition, while the continuous delivery of rotigotine prevented the expression of dyskinesia, the previously demonstrated ability of dopamine agonists to prime for dyskinesia could not be avoided. These data suggest that dyskinesia induced by pulsatile drug treatment may be improved by switching to continuous rotigotine delivery. In addition, while continuous delivery of rotigotine may prime for dyskinesia, it does not lead to its expression. [Copyright &y& Elsevier]

Abstract: Rotigotine is a novel, non-ergoline dopamine D3/D2/D1-receptor agonist for the treatment of Parkinson''s disease that can be continuously delivered by the transdermal route to provide stable plasma levels. Continuous drug delivery should reduce the risk of dyskinesia induction in comparison to pulsatile dopaminergic treatment. Thus the aim of the study was to compare the reversal of motor disability and induction of dyskinesia produced by continuous compared to pulsatile rotigotine administration in MPTP-treated common marmosets. The study also investigated whether pulsatile or continuous rotigotine administration in combination with l-DOPA prevented l-DOPA-induced dyskinesia. Animals were treated for 28 days with vehicle or pulsatile (twice daily) or continuous delivery of rotigotine (via an osmotic minipump). Subsequently, l-DOPA was then co-administered for a further 28 days. Animals were assessed for locomotor activity, motor disability and dyskinesia induction. The study showed that both continuous and pulsatile administration of rotigotine improved motor deficits and normalized motor function in MPTP-treated monkeys. However, continuous rotigotine delivery reduced dyskinesia expression compared to pulsatile treatment. Both pulsatile and continuous rotigotine administration produced less dyskinesia than administration of l-DOPA alone. The addition of l-DOPA to either pulsatile or continuous rotigotine treatment resulted in the induction of marked dyskinesia similar to that produced by treatment with l-DOPA alone. These data further support the hypothesis that continuous delivery of a dopaminergic agent reduces the risk of dyskinesia induction. However, continuous rotigotine administration did not prevent l-DOPA from inducing dyskinesia suggesting that l-DOPA may induce dyskinesia by mechanisms different from dopamine agonist drugs. [Copyright &y& Elsevier]

• A case study highlighting the effects of the adoption of continuous delivery on the code and product quality in a Brazilian company. • The code quality is measured in terms of number of bugs, vulnerability, code smells, duplicate codes and code complexity. • The product quality is explored in terms of defects, demands delivered and user satisfaction. • The adoption of continuous delivery practices did not favor the number of bugs, security vulnerabilities, code smells, duplicated code, and code complexity. • The use of continuous delivery has improved the quality of delivered products that undergo frequent evolutions. Continuous delivery has been adopted by organizations to make software available to their users at any time. The transition from traditional software delivery methodologies to continuous delivery can impact on the results generated by organizations, e.g., the quality of source code and products. Although widely adopted, little is known about its effects. To account for this, this article reports a case study on the effects of continuous delivery on the quality of source code and products produced. Our case study was carried out for 12 months within a software development company in Brazil. Our findings indicate that the adoption of continuous delivery practices improved the quality of delivered products, mainly considering the number of defects reported by customers, the number of demands delivered per month, and user satisfaction. However, the adoption of continuous delivery did not favor the quality of source code, including the number of bugs, security vulnerabilities, code smells, duplicated code, and code complexity. Researchers and practitioners may benefit from our findings typically when delivering software products, designing and seeking to improve deployment pipeline practices. Finally, our study draws up some implications and shows the potential of adopting continuous delivery for developing enterprise applications that are constantly evolving. [ABSTRACT FROM AUTHOR]

Abstract: L-DOPA treatment of Parkinson''s disease induces a high incidence of motor complications, notably dyskinesia. Longer acting dopamine agonists, e.g. ropinirole, are thought to produce more continuous dopaminergic stimulation and less severe dyskinesia. However, standard oral administration of dopamine agonists does not result in constant plasma drug levels, therefore, more continuous drug delivery may result in both prolonged reversal of motor deficits and reduced levels of dyskinesia. Therefore, we compared the effects of repeated oral administration of ropinirole to constant subcutaneous infusion in MPTP-treated common marmosets. Animals received oral administration (0.4 mg/kg, BID) or continuous infusion of ropinirole (0.8 mg/kg/day) via osmotic minipumps for 14 days (Phase I). The treatments were then switched and continued for a further 14 days (Phase II). In Phase I, locomotor activity was similar between treatment groups but reversal of motor disability was more pronounced in animals receiving continuous infusion. Dyskinesia intensity was low in both groups however there was a trend suggestive of less marked dyskinesia in those animals receiving continuous infusion. In Phase II, increased locomotor activity was maintained but animals switched from oral to continuous treatment showing an initial period of enhanced locomotor activity. The reversal of motor disability was maintained in both groups, however, motor disability tended towards greater improvement following continuous infusion. Importantly, dyskinesia remained low in both groups suggesting that constant delivery of ropinirole neither leads to priming nor expression of dyskinesia. These results suggest that a once-daily controlled-release formulation may provide improvements over existing benefits with standard oral ropinirole in Parkinson''s disease patients. [Copyright &y& Elsevier]

The toxicity and pharmacodynamics of leuprolide acetate delivered from subcutaneously implanted DUROS leuprolide implants were examined in sexually mature male beagle dogs. The DUROS leuprolide implant is a sterile, nonpyrogenic, nonerodible, singleuse, implantable, osmotically driven, drug delivery system for the palliative treatment of advanced prostate cancer. It contains 65 mg of leuprolide and is designed to deliver leuprolide continuously at a nominal rate of 120 μg per day for at least 12 months. Serum drug and testosterone concentrations were compared to values from dogs receiving monthly intramuscular injections of Lupron Depot 3.75 mg or no treatment (sham-operated). The local tissue response induced by subcutaneously implanted DUROS leuprolide implants was also evaluated. Beagles were implanted with a DUROS leuprolide implant for 52 weeks followed by removal and implantation of a new DUROS leuprolide implant for an additional 8 weeks. No mortality or morbidity occurred in this study. No treatment-related changes occurred in mean body weights, blood chemistry, or hematology during the study. Treatment-related atrophy of the testes, epididymides, and prostate gland, consistent with the known pharmacological effects of the drug, was observed in all dogs receiving the DUROS leuprolide implant or the Lupron Depot. Histological examination of these organs showed no distinguishable difference between dogs treated with the DUROS leuprolide implant or Lupron Depot. Weekly serum samples from dogs with DUROS leuprolide implants indicated continuous leuprolide delivery over 60 weeks, while some samples from the Lupron Depot group fell below measurable concentrations. Analysis of serum samples collected every 28 days just before Lupron Depot injection showed that 80% of these samples had leuprolide concentrations below the limit of quantitation (0.1 ng/ml). Serum testosterone concentrations were below castrate levels (< 50 ng/dl) by 4 weeks after implantation of DUROS leuprolide implant and remained so for the duration of the study. Lupron Depot 3.75 mg also effectively lowered serum testosterone concentrations, but required reinjection every 28 days. All local tissue reactions to the DUROS leuprolide implant at implant sites were classified as mild following macroscopic examination. Microscopic site scores were mild to moderate. The DUROS leuprolide implant was shown to be safe, to provide continuous leuprolide delivery, and to effectively lower serum testosterone concentrations below castrate levels. [ABSTRACT FROM AUTHOR]

Ensuring a production-ready state of the application under development is the imminent feature of the Continuous Delivery (CD) approach. In a blockchain network, nodes communicate and store data in a distributed manner. Each node executes the same business application but operates in a distinct execution environment. The literature lacks research focusing on continuous practices for blockchain and Distributed Ledger Technology (DLT). Specifically, it lacks such works with support for both design and deployment. The author has proposed a solution that takes into account the continuous delivery of a business application to diverse deployment environments in the DLT network. As a result, two continuous delivery pipelines have been implemented using the Jenkins automation server. The first pipeline prepares a business application whereas the second one generates complete node deployment packages. As a result, the framework ensures the deployment package in the actual version of the business application with the node-specific up-to-date version of deployment configuration files. The Smart Contract Design Pattern has been used when building a business application. The modeling aspect of blockchain network installation has required using Unified Modeling Language (UML) and the UML Profile for Distributed Ledger Deployment. The refined model-to-code transformation generates deployment configurations for nodes. Both the business application and deployment configurations are stored in the GitHub repositories. For the sake of verification, tests have been conducted for the electricity consumption and supply management system designed for prosumers of renewable energy. [ABSTRACT FROM AUTHOR]

Continuous integration has been around for a while now, but the habits it suggests are far from common practice. Automated builds, a thorough test suite, and committing to the mainline branch every day sound simple at first, but they require a responsible team to implement and constant care. What starts with improved tooling can be a catalyst for long-lasting change in your company's shipping culture. Continuous integration is more than a set of practices, it's a mindset that has one thing in mind: increasing customer value. The Web extra at http://youtu.be/tDl_cHfrJZo is an audio podcast of the Tools of the Trade column discusses how continuous integration is more than a set of practices, it's a mindset that has one thing in mind: increasing customer value. [ABSTRACT FROM PUBLISHER]

Based on 25 interviews with participants from four case study companies that develop large‐scale software embedded systems, this paper presents the Test Activity Stakeholders (TAS) model. The TAS model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The model is developed to show how each of the stakeholder interests are best supported by unit/component tests or system tests, by automated testing or manual testing and by tests executed in simulated environments or on real hardware. The TAS model may serve as a starting point for companies when evaluating and designing their continuous integration and delivery pipeline. The validation of the TAS model included twelve individuals from three case study companies. The validation showed that the TAS model is actionable and useful in practice, enabling the identification of stakeholders and showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. The Test Activity Stakeholders (TAS) model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The validation of the TAS model showed that the model is actionable and useful in practice, showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. [ABSTRACT FROM AUTHOR]

In this excerpt from Software Engineering Radio, Stefan Tilkov talks with Adrian Cockcroft about architecture, development, and operations that make the most out of cloud-based offerings, with Cockcroft sharing his experience at Netflix. [ABSTRACT FROM PUBLISHER]