DOCSLIB.ORG

Trade-Offs in Continuous Integration:Assurance, Security, And

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Trade-Offs in Continuous Integration:Assurance, Security, And Trade-Os in Continuous Integration: Assurance, Security, and Flexibility Michael Hilton Nicholas Nelson Timothy Tunnell Oregon State University, USA Oregon State University, USA University of Illinois, USA mhilton@cmu:edu nelsonni@oregonstate:edu tunnell2@illinois:edu Darko Marinov Danny Dig University of Illinois, USA Oregon State University, USA marinov@illinois:edu digd@oregonstate:edu 1 INTRODUCTION Continuous integration (CI) systems automate the compilation, ABSTRACT building, and testing of software. CI usage is widespread throughout Continuous integration (CI) systems automate the compilation, the software development industry. For example, the “State of Agile” building, and testing of software. Despite CI being a widely used industry survey [51], with 3,880 participants, found half of the activity in software engineering, we do not know what motivates respondents use CI. The “State of DevOps” report [33], a survey developers to use CI, and what barriers and unmet needs they face. of over 4,600 technical professionals from around the world, nds Without such knowledge, developers make easily avoidable errors, CI to be an indicator of “high performing IT organizations”. We tool builders invest in the wrong direction, and researchers miss previously reported [19] that 40% of the 34,000 most popular open- opportunities for improving the practice of CI. source projects on GitHub use CI, and the most popular projects We present a qualitative study of the barriers and needs devel- are more likely to use CI (70% of the top 500 projects). opers face when using CI. We conduct semi-structured interviews Despite the widespread adoption of CI, there are still many unan- with developers from dierent industries and development scales. swered questions about CI. In one study, Vasilescu et al. [50] show We triangulate our ndings by running two surveys. We nd that that CI correlates with positive quality outcomes. In our previous developers face trade-os between speed and certainty (Assurance), work [19], we examine the usage of CI among open-source projects between better access and information security (Security), and be- on GitHub, and show that projects that use CI release more fre- tween more conguration options and greater ease of use (Flexi- quently than projects that do not. However, these studies do not bility). We present implications of these trade-os for developers, present what barriers and needs developers face when using CI, or tool builders, and researchers. what trade-os developers must make when using CI. To ll in the gaps in knowledge about developers’ use of CI, CCS CONCEPTS we ask the following questions: What needs do developers have • Software and its engineering → Agile software develop- that are unmet by their current CI system(s)? What problems have ment; Software testing and debugging; developers experienced when conguring and using CI system(s)? How do developers feel about using CI? Without answers to these KEYWORDS questions, developers can potentially nd CI more obstructive than helpful, tool builders can implement unneeded features, and re- Continuous Integration, Automated Testing searchers may not be aware of areas of CI usage that require further ACM Reference Format: examination and solutions that can further empower practitioners. Michael Hilton, Nicholas Nelson, Timothy Tunnell, Darko Marinov, and Danny To answer these questions, we employ complementary estab- Dig. 2017. Trade-Os in Continuous Integration: Assurance, Security, and lished research methodologies. Our primary methodology is inter- Flexibility. In Proceedings of 2017 11th Joint Meeting of the European Software views with 16 software developers from 14 dierent companies of Engineering Conference and the ACM SIGSOFT Symposium on the Foun- all sizes. To triangulate [15] our ndings, we deploy two surveys. dations of Software Engineering, Paderborn, Germany, September 4–8, 2017 The Focused Survey samples 51 developers at Pivotal1. The Broad (ESEC/FSE’17), 11 pages. Survey samples 523 participants, of which 95% are from industry, https://doi:org/10:1145/3106237:3106270 and 70% have seven or more years of software development experi- ence. The interviews provide the content for the surveys, and the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed Focused Survey provides depth, while the Broad Survey provides for prot or commercial advantage and that copies bear this notice and the full citation breadth. Analyzing all this data, we answer four research questions: on the rst page. Copyrights for components of this work owned by others than ACM RQ1: What barriers do developers face when using CI? (see §4.1) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specic permission and/or a RQ2: What unmet needs do developers have with CI tools? (see §4.2) fee. Request permissions from [email protected]. RQ3: Why do developers use CI? (see §4.3) ESEC/FSE’17, September 4–8, 2017, Paderborn, Germany RQ4: What benets do developers experience using CI? (see §4.4) © 2017 Association for Computing Machinery. ACM ISBN 978-1-4503-5105-8/17/09...$15.00 https://doi:org/10:1145/3106237:3106270 1pivotal.io 197 ESEC/FSE’17, September 4–8, 2017, Paderborn, Germany M. Hilton, N. Nelson, T. Tunnell, D. Marinov, and D. Dig Based on our ndings, we identify three trade-os developers We asked our interview participants to describe their CI usage face when using CI. Other researchers [32, 34, 53] have identied pipeline. While not all pipelines are the same, they generally share similar trade-os in dierent domains. We name these trade-os some common elements. Assurance, Security, and Flexibility. Changesets are a group of changes that a developer makes to the Assurance describes the trade-o between increasing the added code. They may be a single commit, or a group of commits, but they value that extra testing provides, and the extra cost of perform- should be a complete change, so that after the changeset is applied, ing that testing. Rothermel et al. [34] identify this trade-o as a it should not break the program. motivation for test prioritization. When a CI system observes a change made by developers, this Security describes the trade-o between increased security mea- triggers a CI event. How and when the CI is triggered is based on sures, and the ability to access and modify the CI system as needed. how the CI is congured. One common way to trigger CI is when a Post and Kagan [32] found a third of knowledge workers report commit is pushed to a repository. security restrictions hinder their ability to perform their jobs. We For the CI to test the code without concern for previous data or observe this issue also applies to CI users. external systems, it is important that CI runs in a clean environment. Flexibility describes the trade-o that occurs when developers The automated build script should be able to start with a clean want systems that are both powerful and highly congurable, yet environment and build the product from scratch before executing at the same time, they want those systems to be simple and easy to tests. Many developers use containers (e.g., Docker2) to implement use. Xu et al. [53] identify the costs of over-congurable systems clean environments for builds. and found that these systems severely hinder usability. We also An important step in the CI pipeline is conrming that the observe the tension from this trade-o among developers using CI. changeset was integrated correctly into the application. One com- In the context of these three trade-os, we present implications mon method is a regression test suite, including unit tests and for three audiences: developers, tool builders, and researchers. For integration tests. The CI system can also perform other analyses, example, developers face dicult choices about how much testing such as linting or evaluating test coverage. is enough, and how to choose the right tests to run. Tool builders The last step is to deploy the artifact. We found some develop- should create UIs for CI users to congure their CI systems, but ers consider deployment to be a part of CI, and others consider these UIs should serialize congurations out to text les so that continuous deployment (CD) to be a separate process. they can be kept in version control. Researchers have much to bring to the CI community, such as helping with fault localization and 3 METHODOLOGY test parallelization when using CI, and examining the security Inspired by established guidelines [24, 28, 31, 41, 48], the primary challenges developers face when using CI. methodologies we employ in this work are interviews with soft- This paper makes the following contributions: ware developers and two surveys of software developers to trian- (1) We conduct exploratory semi-structured interviews with 16 gulate [15] our ndings. developers, then triangulate these ndings with a Focused Survey Interviews are a qualitative method and are eective at discover- of 51 developers at Pivotal and a Broad Survey of 523 developers ing the knowledge and experiences of the participants. However, from all over the world. they often have a limited sample size [41]. Surveys are a quantita- (2) We provide an empirically justied set of developers’ motiva- tive technique that summarizes information over a larger sample tions for using CI. size and thus provides broader results. Together, they provide a (3) We expose gaps between developers’ needs and existing tooling much clearer picture than either can provide alone. for CI. We rst use interviews to elicit developers experiences and ex- (4) We present actionable implications that developers, tool builders, pectations when working with CI, and we build a taxonomy of and researchers can build on.
Load more

Recommended publications
  • Rugby - a Process Model for Continuous Software Engineering
    INSTITUT FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rugby - A Process Model for Continuous Software Engineering Stephan Tobias Krusche Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Universitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Helmut Seidl Prufer¨ der Dissertation: 1. Univ.-Prof. Bernd Brugge,¨ Ph.D. 2. Prof. Dr. Jurgen¨ Borstler,¨ Blekinge Institute of Technology, Karlskrona, Schweden Die Dissertation wurde am 28.01.2016 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 29.02.2016 angenommen. Abstract Software is developed in increasingly dynamic environments. Organizations need the capability to deal with uncertainty and to react to unexpected changes in require- ments and technologies. Agile methods already improve the flexibility towards changes and with the emergence of continuous delivery, regular feedback loops have become possible. The abilities to maintain high code quality through reviews, to regularly re- lease software, and to collect and prioritize user feedback, are necessary for con- tinuous software engineering. However, there exists no uniform process model that handles the increasing number of reviews, releases and feedback reports. In this dissertation, we describe Rugby, a process model for continuous software en- gineering that is based on a meta model, which treats development activities as parallel workflows and which allows tailoring, customization and extension. Rugby includes a change model and treats changes as events that activate workflows. It integrates re- view management, release management, and feedback management as workflows. As a consequence, Rugby handles the increasing number of reviews, releases and feedback and at the same time decreases their size and effort.
    [Show full text]
  • SIGSOFT CFP-ICSE04.Qxd
    General Chair Richard N. Taylor Call for Participation University of California, Irvine [email protected] ACM SIGSOFT 2004 Program Chair Matthew B. Dwyer Twelfth International Symposium on the Kansas State University Foundations of Software Engineering FSE-12 [email protected] Newport Beach Program Committee Ken Anderson, U Colorado, Boulder, USA October 31 - November 5, 2004 Annie Antón, North Carolina State U, USA Hyatt Newporter Hotel, Newport Beach, California, USA Joanne Atlee, U Waterloo, Canada Prem Devanbu, U California, Davis, USA http://www.isr.uci.edu/FSE-12/ Mary Jean Harrold, Georgia Tech, USA John Hatcliff, Kansas State U, USA Jim Herbsleb, Carnegie Mellon U, USA SIGSOFT 2004 brings together researchers and practitioners from academia and industry to André van der Hoek, U California, Irvine, exchange new results related to both traditional and emerging fields of software engineer- USA ing. SIGSOFT 2004 will feature four workshops, one day of tutorials organized through the Paola Inverardi, U L'Aquila, Italy Educator's Grant Program (EGP), a student resarch forum with posters, along with FSE-12. Gregor Kiczales, U British Columbia, Canada Jeff Kramer, Imperial College London, UK FSE-12 will be held Tuesday-Thursday, November 2-4. We are pleased to announce the Shriram Krishnamurthi, Brown U, USA keynotes: Shinji Kusumoto, Osaka U, Japan Axel van Lamsweerde, U Catholique de Alexander L. Wolf, University of Colorado at Boulder, Tues. Nov. 2 Louvain, Belgium Bashar Nuseibeh, The Open U, UK Joe Marks, Director, Mitsubishi Electric Research Laboratories, Cambridge, Wed. Nov. 3 Mauro Pezzé, U Milano-Bicocca, Italy SIGSOFT Distinguished Research Award winner, Thur.
    [Show full text]
  • Towards Embedded System Agile Development Challenging Verification, Validation and Accreditation
    Towards Embedded System Agile Development Challenging Verification, Validation and Accreditation : Application in a Healthcare Company Clément Duffau, Bartosz Grabiec, Mireille Blay-Fornarino To cite this version: Clément Duffau, Bartosz Grabiec, Mireille Blay-Fornarino. Towards Embedded System Agile Develop- ment Challenging Verification, Validation and Accreditation : Application in a Healthcare Company. ISSRE 2017- IEEE International Symposium on Software Reliability Engineering, Oct 2017, Toulouse, France. pp.1-4. hal-01678815 HAL Id: hal-01678815 https://hal.archives-ouvertes.fr/hal-01678815 Submitted on 9 Jan 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Towards Embedded System Agile Development Challenging Verification, Validation and Accreditation Application in a Healthcare Company Clement´ Duffau Bartosz Grabiec Mireille Blay-Fornarino AXONIC and I3S AXONIC I3S Universite´ Coteˆ d’Azur, CNRS Sophia Antipolis, France Universite´ Coteˆ d’Azur, CNRS Sophia Antipolis, France [email protected] Sophia Antipolis, France [email protected] [email protected] Abstract—When Agile development meets critical embedded to survive. Moreover, with limited human resources, quality systems, verification, validation and accreditation activities are improvement with Agility usage remains to be demonstrated. impacted. Challenges such as tests increase or accreditation The remainder of this paper is organized as follows.
    [Show full text]
  • Devops Point of View an Enterprise Architecture Perspective
    DevOps Point of View An Enterprise Architecture perspective Amsterdam, 2020 Management summary “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”1 Setting the scene Goal of this Point of View In the current world of IT and the development of This point of view aims to create awareness around the IT-related products or services, companies from transformation towards the DevOps way of working, to enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it use the DevOps processes and methods as a part and what is needed to implement DevOps. of their day-to-day organization process. The goal is to reduce the time involved in all the An Enterprise Architecture perspective software development phases, to achieve greater Even though it is DevOps from an Enterprise Architecture application stability and faster development service line perspective, this material has been gathered cycles. from our experiences with customers, combined with However not only on the technical side of the knowledge from subject matter experts and theory from organization is DevOps changing the playing within and outside Deloitte. field, also an organizational change that involves merging development and operations teams is Targeted audience required with an hint of cultural changes. And last but not least the skillset of all people It is specifically for the people within Deloitte that want to involved is changing. use this as an accelerator for conversations and proposals & to get in contact with the people who have performed these type of projects.
    [Show full text]
  • White Paper Getting Started with Continuous Integration in Software
    WHITE PAPER GETTING STARTED WITH CONTINUOUS INTEGRATION IN SOFTWARE DEVELOPMENT Amruta Kumbhar, Madhavi Shailaja & Ravi Shankar Anupindi Introduction DevOps culture is gaining rapid momentum in the IT industry as it enables business to adopt agile software delivery methodologies like Continuous Integration (henceforth referred to as CI) & Continuous Delivery (henceforth referred to as CD) .These methodologies enable quicker issue resolution, instant feedback loops, improved software quality and cost saving to meet the ever- increasing demand to deliver better software faster. It would not be wrong to say that CI-CD practices will soon become the de- facto software delivery standards across the industry. Though both these methodologies (CI and CD) This article compiles insights gained from complement each other, CI is the pre-requisite our practical experiences across various CI phase for enabling CD as the latter is built on enablement programs which we have been Gartner says “By 2016, top of the former. The primary goal of CI is associated with. not only to enable build automation through DevOps will evolve Some of these experiences might vary continuous test and quality checks but also to from a niche to a depending on the choice of tools, provide project insights through reports and infrastructure setup, organization policies mainstream strategy dashboards. Since this phase is all about tools, and project requirements. In spite of the employed by 25 it imposes various integration challenges. differences, we hope, this article will act as Having a good knowledge of the tools Percent of global 2000 a helping guide to all those planning for CI involved, their integration aspects and the organizations” setup in their projects.
    [Show full text]
  • Improving Web Services Maintenance Through Regression Testing Divya Rohatgi, Prof
    Volume 3, Issue 5, May-2016, pp. 261-265 ISSN (O): 2349-7084 International Journal of Computer Engineering In Research Trends Available online at: www.ijcert.org Improving Web Services Maintenance through Regression Testing Divya Rohatgi, Prof. (Col) Gurmit Singh 1. Research Scholar, Computer Science and Engineering Department Sam Higginbottom Institute of Agriculture, Technology and Sciences Deemed University, Allahabad, India 2. Professor, Computer Science and Engineering Department Sam Higginbottom Institute of Agriculture, Technology and Sciences Deemed University, Allahabad, India Abstract: - Software maintenance is considered to be the most expensive activity in software development and is used to ensure quality to the product. Regression Testing is a part of software maintainers which is done every time the software is changed. For software like Web services which represent a class of Service oriented architectures this activity is a challenging task. Since web services incorporate business functionality thus maintaining proper quality is an important concern. Due to inherent distributed, heterogeneous and dynamic in nature, regression testing is difficult and time consuming activity. Thus in order to reduce maintenance cost we have to reduce regression testing cost. Thus in this paper, we have given a comprehensive study of regression testing of web services exploring the challenges, approaches and tools used for them to ensure proper quality and inherently reducing the maintenance costs. Keywords – Software Engineering, Software Maintenance, Regression Testing, Web Service. —————————— —————————— 1. INTRODUCTION implications deriving from the adoption of the standardized stack of technology underlying web In today’s growing and competitive scenario Service– services (e.g., SOAP, WSDL, UDDI, etc.); oriented architectures are having a crucial role in the way in which systems are developed and designed.
    [Show full text]
  • Softwareprozesse: Timeboxing & Continuous Delivery
    Softwareprozesse: Timeboxing & Continuous Delivery BENJAMIN PROJDAKOV The Timeboxing Process Model •Voller Titel: The Timeboxing Process Model for Iterative Software Development •Verfasser: • Professor Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur • Aveejeet Palit, Priya Kurien Infosys Technologies Limited Bangalore Einführung: Wasserfallmodell •Linear •Nicht iterativ •Lange Entwicklungsdauer typisch •Anforderungen: • Müssen vollständig bekannt sein • Änderungen schwierig •Entwicklung in Phasen •Ergebnis: Vollständige Software •Komplexität der Software eher gering Einführung: Iterative Modelle •Linear •Entwicklung: • In Zyklen • Zyklus unterteilt sich in Phasen •Kurze Entwicklungsdauer pro Zyklus •Anforderungen: • Müssen pro Iteration bekannt sein • Änderungen in nächster Iteration möglich •Ergebnis: Funktionierende Software nach jedem Zyklus Timeboxing Modell •Entwicklung: • In Zyklen • Zyklus unterteilt sich in Phasen • Ausführung mit Versatz parallel •Feste Entwicklungsdauer pro Zyklus • Wochen bis Monate •Anforderungen: • Müssen pro Iteration bekannt sein • Änderungen in nächster Iteration •Ergebnis: • Häufige Releases • Funktionierende Software nach jedem Zyklus Timeboxing Modell: Phasen & Teams •Phasen: •Teams: • Anzahl Variabel • Eine Aufgabe pro Team • Gleiche Dauer ideal • Größe abgestimmt auf Dauer Timeboxing Modell: Phasen & Teams •Ungleiche Boxen führen zu ineffizienter Teamauslastung •Lösungen: • “Right-scaling” von Teams • Ressourcenumverteilung •Kann auch durch Verzögerungen
    [Show full text]
  • FINAL PROGRAM University of California, Irvine [email protected] Program Chair Matthew B
    General Chair Richard N. Taylor FINAL PROGRAM University of California, Irvine [email protected] Program Chair Matthew B. Dwyer ACM SIGSOFT 2004 University of Nebraska-Lincoln [email protected] Twelfth International Symposium on the Program Committee Ken Anderson, U Colorado, Boulder, USA Foundations of Software Engineering FSE-12 Annie Antón, North Carolina State U, USA Joanne Atlee, U Waterloo, Canada Prem Devanbu, U California, Davis, USA Mary Jean Harrold, Georgia Tech, USA John Hatcliff, Kansas State U, USA Jim Herbsleb, Carnegie Mellon U, USA André van der Hoek, U Calif., Irvine, USA Paola Inverardi, U L'Aquila, Italy Gregor Kiczales, U British Columbia, Canada Jeff Kramer, Imperial College London, UK Shriram Krishnamurthi, Brown U, USA Shinji Kusumoto, Osaka U, Japan Axel van Lamsweerde, U Catholique de Louvain, Belgium Bashar Nuseibeh, The Open U, UK Mauro Pezzé, U Milano-Bicocca, Italy Gian Pietro Picco, Politecnico di Milano, Italy David Rosenblum, U College London, UK Gregg Rothermel, U Nebraska-Lincoln, USA Wilhelm Schäfer, U Paderborn, Germany Douglas Schmidt, Vanderbilt U, USA Peri Tarr, IBM T.J. Watson, USA Frank Tip, IBM T.J. Watson, USA Willem C. Visser, NASA Ames, USA http://www.isr.uci.edu/FSE-12/ Student and Diversity Programs Co-Chairs October 31 - November 5, 2004 Educators Grant Program and Tutorials Hyatt Newporter Hotel, Newport Beach, California, USA Mary Jean Harrold Georgia Tech [email protected] Mary Lou Soffa SIGSOFT 2004 brings together researchers and practitioners from academia and industry to University of Virginia exchange new results related to both traditional and emerging fields of software engineering.
    [Show full text]
  • Continuous Integration (CI) Needs and Wishes for Developers of Proprietary Code
    Continuous Integration (CI) Needs and Wishes for Developers of Proprietary Code Michael Hilton, Nicholas Nelson, Danny Dig Timothy Tunnell, Darko Marinov School of EECS, Oregon State University CS Department, University of Illinois {hiltonm,nelsonni,digd}@oregonstate.edu {tunnell2,marinov}@illinois.edu Abstract—Continuous integration (CI) systems automate the Open-source projects are often considered fundamentally dif- compilation, building, and testing of software. Despite CI being ferent from proprietary-code projects [6]. Differences between one of the most widely used processes in software engineering, open-source and proprietary-code projects include that open- we do not know what motivates developers to use CI, and what barriers and unmet needs they face. Without such knowledge source projects foster more creativity [7], have fewer defects [7], developers make easily avoidable errors, managers reduce the and assign work differently [8]. However, similarities have also productivity of developers by making misinformed decisions, tool been found, including how GitHub is used [9], overall project builders invest in the wrong direction, and researchers miss many complexity [7], and amount of modularity [7]. opportunities for improving the software engineering practice. There are still many gaps in our knowledge about why Given the large fraction of proprietary code development, un- derstanding how proprietary developers are using CI is vital to developers use CI, and what barriers they face, especially for improving it. projects of proprietary code. What motivates developers to use We present the first study of how CI is used in the proprietary CI? What are the barriers that developers face when using development of software. We conduct 16 semi-structured inter- CI? What needs do developers have that are unmet by their views with developers from different industries and development current CI system(s)? Do proprietary developers have the same scale.
    [Show full text]
  • Curriculum Vitae James A
    Curriculum Vitae James A. Jones General Information Bio Highlights Professor Jones is perhaps best known for the creation of the influential Tarantula technique that spawned a new field of \spectra-based" fault localization. For this work, he was awarded the prestigious ACM SIGSOFT Award in 2015. Also, he is a recipient of the prestigious National Science Foundation Faculty Early Career Development (CAREER) Award, which recognizes outstanding research and excellent education. Jones's research contributions span the duration of his undergrad, professional, graduate, and professorial career. Throughout this time, Jones created tools and techniques for software analysis (static and dynamic), techniques to help manage test suites for safety-critical software systems, techniques to support several aspects of software debugging and comprehension, and has studied the ways that software behaves in order to better model and predict it. Jones received the Ph.D. in Computer Science at Georgia Tech, advised by Professor Mary Jean Harrold. At UC Irvine, Jones leads the Spider Lab (http://spideruci.org) and advises Ph.D., Masters, and undergraduate students to study and improve software development and maintenance processes. Jones is a regular author and reviewer for top-tier research conferences (e.g., ICSE, FSE, ISSTA, ASE) and has co-organized events such as the 1st Working Conference on Software Visualization (VISSOFT) and the 10th Workshop on Dynamic Analysis (WODA). Contact Information University of California, Irvine Bren School of Information and Computer Sciences Department of Informatics Institute for Software Research Spider Lab Research Group (http://spideruci.org) 5214 Bren Hall, Irvine, CA 92697-3440 +1 (949) 824-0942 +1 (949) 824-4056 [email protected] http://jamesajones.com http://spideruci.org Jones, James A.
    [Show full text]
  • Continuous Integration in Salesforce Development By: Diptiman Prusty 1
    Whitepaper Continuous Integration in Salesforce Development By: Diptiman Prusty 1. Introduction In current SFDC software development scenario, it pays to be quick to market and be able to focus on the business requirements rather than the development process details. DevOps culture for software development has gained rapid momentum in SFDC development industry in the last few years. It involves adopting agile software development methodologies like Continuous Deployment, Continuous Integration (CI) and Continuous Delivery (CD). This enables them to resolve issues quicker, get instant feedback on new products and features, improve the quality of software and ultimately save cost and gain market share. As we shall see below, Salesforce platform is very well suited to use the Continuous Integration and Continuous Delivery methodology to enable organizations to be agile. Page - 2 2. Agile Software Development 3. CI and CD In Salesforce Business enterprises today face several Continuous Integration (CI) and challenges starting from highly competitive Continuous Deployment (CD) are environment, rapidly changing business development practice that requires scenarios and the need to scale up. developers to commit code into a common To overcome the shortcomings of lengthy software source every time they have working code. development cycle, enterprises today have embraced Each commit known as a check-in gets verified by an the AGILE methodology for software development. automated build process. This allows the problems to be identified early in the development process. By integrating regularly, the team can detect errors quickly, Task Board Burndown To In Done and take necessary remedial action. In fact in recent Chart Do Progress years it has come to encompass the whole cycle from Product code check-in till the production deployment.
    [Show full text]
  • Agile Automated Software Testing Into Automotive V-Model Process
    Agile automated software testing into automotive V-Model process: A practical case Xavier Martin Artal Software QA Manager [email protected] es.linkedin.com/pub/xavier-martin/6/a89/723/ Agenda • Introduction • Automotive Trends: Car Connectivity • Car Telematics project Challenges • Use Case Solution: From V-Model to Agile Testing • Results and Conclusions Introduction What is this presentation about? • Expose a practical case of adoption of Agile techniques in automotive testing • Converge Spice automotive V-Model to Agile Spice V-Model Agile • Present Technical Solution adopted: Automation Test Framework • Discuss results and Agile adequacy to Automotive industry Automotive Trends: Vehicle Connectivity Car Telematics • Car Manufacturers start to add 3G/4G capabilities • Connectivity opens new opportunities to develop services for both clients and manufacturers Connectivity Services – Emergency Call – Fleet Management – Car Sharing – Remote Car Diagnostics – Stolen Vehicle Tracking (SVT) – WOTA Update – Dealer Services – User Premium Services Car telematics: eCall • Emergency Call Service for Europe • U.E Council proposes eCall obligatory in European Cars for end 2017 • Automatic call in case of accident or emergency will force car manufacturers to add IVTU to every new car for European Service • Similar regulations for Russia, USA, BRA and PRC Car Telematics Project Challenges What is an iVTU? iVTU = in Vehicle Telematics Unit - Electronic Unit in charge of granting 2G/3G/LTE connectivity to vehicles - Two Main processors architecture:
    [Show full text]