Siga este enlace para ver otros tipos de publicaciones sobre el tema: Continuous integration and development.
Tesis sobre el tema "Continuous integration and development"
Crea una cita precisa en los estilos APA, MLA, Chicago, Harvard y otros
Consulte los 50 mejores tesis para su investigación sobre el tema "Continuous integration and development".
Junto a cada fuente en la lista de referencias hay un botón "Agregar a la bibliografía". Pulsa este botón, y generaremos automáticamente la referencia bibliográfica para la obra elegida en el estilo de cita que necesites: APA, MLA, Harvard, Vancouver, Chicago, etc.
También puede descargar el texto completo de la publicación académica en formato pdf y leer en línea su resumen siempre que esté disponible en los metadatos.
Explore tesis sobre una amplia variedad de disciplinas y organice su bibliografía correctamente.
1
Amaradri, Anand Srivatsav y Swetha Bindu Nutalapati. "Continuous Integration, Deployment and Testing in DevOps Environment". Thesis, Blekinge Tekniska Högskola, Institutionen för programvaruteknik, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-13334.
Texto completoResumen
Context. Owing to a multitude of factors like rapid changes in technology, market needs, and business competitiveness, software companies these days are facing pressure to deliver software rapidly and on a frequent basis. For frequent and faster delivery, companies should be lean and agile in all phases of the software development life cycle. An approach called DevOps, which is based on agile principles has come into play. DevOps bridges the gap between development and operations teams and facilitates faster product delivery. The DevOps phenomenon has gained a wide popularity in the past few years, and several companies are adopting DevOps to leverage its perceived benefits. However, the organizations may face several challenges while adopting DevOps. There is a need to obtain a clear understanding of how DevOps functions in an organization. Objectives. The main aim of this study is to provide a clear understanding about how DevOps works in an organization to researchers and software practitioners. The objectives of the study are to identify the benefits of implementing DevOps in organizations where agile development is in practice, the challenges faced by organizations during DevOps adoption, to identify the solutions/ mitigation strategies, to overcome the challenges,the DevOps practices, and the problems faced by DevOps teams during continuous integration, deployment and testing. Methods. A mixed methods approach having both qualitative and quantitative research methods is used to accomplish the research objectives.A Systematic Literature Review is conducted to identify the benefits and challenges of DevOps adoption, and the DevOps practices. Interviews are conducted to further validate the SLR findings, and identify the solutions to overcome DevOps adoption challenges, and the DevOps practices. The SLR and interview results are mapped, and a survey questionnaire is designed.The survey is conducted to validate the qualitative data, and to identify the other benefits and challenges of DevOps adoption, solutions to overcome the challenges, DevOps practices, and the problems faced by DevOps teams during continuous integration, deployment and testing. Results. 31 primary studies relevant to the research are identified for conducting the SLR. After analysing the primary studies, an initial list of the benefits and challenges of DevOps adoption, and the DevOps practices is obtained. Based on the SLR findings, a semi-structured interview questionnaire is designed, and interviews are conducted. The interview data is thematically coded, and a list of the benefits, challenges of DevOps adoption and solutions to overcome them, DevOps practices, and problems faced by DevOps teams is obtained. The survey responses are statistically analysed, and a final list of the benefits of adopting DevOps, the adoption challenges and solutions to overcome them, DevOps practices and problems faced by DevOps teams is obtained. Conclusions. Using the mixed methods approach, a final list of the benefits of adopting DevOps, DevOps adoption challenges, solutions to overcome the challenges, practices of DevOps, and the problems faced by DevOps teams during continuous integration, deployment and testing is obtained. The list is clearly elucidated in the document. The final list can aid researchers and software practitioners in obtaining a better understanding regarding the functioning and adoption of DevOps. Also, it has been observed that there is a need for more empirical research in this domain.
2
Nilsson, Samuel. "Implementation of a Continuous Integration and Continuous Delivery System for Cross-Platform Mobile Application Development". Thesis, Linköpings universitet, Interaktiva och kognitiva system, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-129922.
Texto completoResumen
When working in software development teams, there are challenges when it comes to always keeping the software stable and reliable. Continuous integration are frequently used to increase the stability and reliability. Extensive research has been performed on the matter of development processes of continuous integration, but there are no consensus on how systems to support continuous integration should be implemented for best results. In this report a continuous integration system is implemented based on best practices and to support the general continuous integration development process, by using Jenkins and other open source tools. The system is adapted to work well with the cross-platform mobile development framework CoffeeMaker developed by VISIARC AB and the general needs of the company. In order to roughly estimate the increased developer productivity and product quality when introducing the system, a questionnaire that discusses the system and working habits was sent out to the developers. The evaluation lead to the conclusion that the productivity would improve by approximately 30-60 minutes per week and developer. It also lead to the conclusion that the quality of their developed applications would most probably increase by introducing such a system.
3
Hagsten, Per. "Evaluation of a qualitative model for a company's technical maturity within Continuous Integration, Continuous Delivery and DevOps". Thesis, KTH, Skolan för elektroteknik och datavetenskap (EECS), 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-233554.
Texto completoResumen
The purpose of this study is to continue development of a benchmarking model to help companies assess their technical maturity when it comes to adopting Continuous Integration, Continuous Delivery and DevOps in their organization. The goal of the research is to assess how to improve the quality of qualitative models. Which conclusions can be drawn from comparing companies using benchmark and to assess which actions are the most effective to take to reach higher Continuous Integration, Continuous Delivery and DevOps maturity. The benchmark consisted of a questioner of two hundred statements that were answered for level of agreement with a current situation analysis and an ought-to-be analysis to be able to draw conclusions from the possible discrepancy between these categories. The questioner was answered during an interview study with chosen clients. Conclusions drawn from this study were that a lot can be done to improve the quality of qualitative models for examining Continuous Integration, Continuous Delivery and DevOps maturity. Different actions are necessary but the most important seems to be to ask open ended questions as well ass questions about different aspects of the same problem to promote discussion. It was also showed to be important to peer review the questions in the interview material beforehand to increase quality. The study also showed that it is possible to see trends in Continuous Integration, Continuous Delivery and DevOps maturity when comparing qualitative results for research subjects. The study showed that the most effective method for increasing Continuous Integration, Continuous Delivery and DevOps maturity is to use extensive automated testing suites that covers all testing disciplines.Syftet med studien är att vidareutveckla ett benchmarkingverktyg för att hjälpa företag att bedöma sin tekniska mognad när det gäller att anta Continuous Integration, Continuous Delivery och DevOps i sin organisation. Målet med forskningen är att bedöma hur man kan förbättra kvaliteten på kvalitativa modeller för att mäta detta, samt vilka slutsatser som kan dras av att jämföra företags resultat som nyttjat studien. Samt att undersöka vilka åtgärder som är effektivast att ta för att nå en högre mognadsgrad inom Continuous Integration, Continuous Delivery och DevOps. Benchmarken bestod av ett frågebatteri av tvåhundra påståenden som besvarades av kunden i hur mycket de instämde till ett påstående. Resultatet samanställdes till en aktuell nulägesanalys och en börlägesanalys, med målet att dra slutsatser i vilka skillnaden som fanns mellan dessa två kategorier. Kunden besvarade frågebatteriet under en intervjustudie med utvalda anställda. Slutsatser som härrör från denna studie var att mycket kan göras för att förbättra kvaliteten på kvalitativa modeller för att undersöka Continuous Integration, Continuous Delivery och DevOps mognadsgrad. Olika åtgärder är möjliga, men det viktigaste förefaller vara att fråga öppna frågor för att främja diskussion samt att ställa frågor om olika aspekter av samma problem. Samt att opponera frågorna internt i intervjuundersökningen innan det utförs hos en kund, för att öka kvaliteten. Studien visade också att det även är möjligt att se trender i Continuous Integration, Continuous Delivery och DevOps mognad hos deltagarna när man jämför de kvalitativa resultaten. Studien visade att de mest effektiva metoderna för att öka Continuous Integration, Continuous Delivery och DevOps mognadsgrad är att använda omfattande automatiserade testsviter för samtliga testmetoder.
4
Seppänen, V. (Vili). "Enhancing continuous integration processes in agile development using project management tools". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201809062759.
Texto completoResumen
This thesis presents a concept to enhance the continuous integration processes in agile development, by utilising the combination of project management tools and user stories. First, the reader is introduced to the fields of continuous integration, agile, feature toggles and version control to provide a good basic understanding of the context. Related work on release engineering is presented from the perspective of release planning and constructing. Problems with current, commonly used continuous integration processes are identified and analysed, and then solutions for these problems are designed and proposed. This includes listing the requirements for implementing the solutions, describing the designs of the solutions and discussing the expected benefits of the solutions. These solutions form the concept to enhance the continuous integration processes in agile development. This new concept is evaluated in a user-study among seasoned IT professionals. The study includes applicable elements from Expectation Disconfirmation Theory to examine the validity and the likely future adoption of the proposed approach in the information technology sector. The evaluation results suggest that the solution, when implemented in a production environment, will be easy to use; have the capability, functions and features needed to accomplish its tasks; will be reliable and beneficial for its purpose and would be likely to improve the overall performance of the software projectTämä diplomityö esittelee konseptin jatkuvan integraation prosessien tehostamiseen ketterässä ohjelmistokehitysympäristössä. Konsepti perustuu projektinhallintatyökalujen ja käyttäjätarinoiden uudentyyppiseen ja älykkäämpään linkittämiseen. Aluksi työssä esitellään jatkuva integraatio, ketterä ohjelmistokehitys, liput sekä versionhallinta aihealueen perusteiden ymmärtämiseksi. Lisäksi esitellään julkaisunhallinta julkaisusuunnittelun ja julkaisun koostamisen näkökulmasta niiltä osin kuin se on diplomityön kannalta olennaista. Nykyisten yleisesti käytettävien jatkuvan integraation prosessien ongelmat tunnistetaan ja analysoidaan, ja näihin ongelmiin suunnitellaan ja esitetään ratkaisut. Esitellyt ratkaisut sisältävät niiden toteuttamista koskevien vaatimusten luetteloinnin, suunnitellun toteutuksen kuvauksen sekä pohdinnan ratkaisuista odotettavista hyödyistä. Nämä ratkaisut muodostavat konseptin jatkuvan integraation prosessien tehostamiseksi ketterässä ohjelmistokehityksessä. Esitelty uusi konsepti arvioidaan kokeneiden IT-ammattilaisten keskuudessa tehdyn käyttäjätutkimuksen avulla. Käyttäjätutkimuksessa käytetään soveltuvia elementtejä odotusten kumoamisen mallista, minkä avulla tarkastellaan ehdotetun lähestymistavan soveltuvuutta sekä tulevan käyttöönoton todennäköisyyttä tietotekniikka-alalla. Arvioinnin tulokset viittaavat siihen, että tuotantoympäristöön toteutettuna, ratkaisu on helppokäyttöinen, pitää sisällään valmiudet, toiminnallisuuden ja ominaisuudet sille annettujen tehtävien suorittamiseksi, on luotettava ja hyödyllinen, ja parantaa todennäköisesti ohjelmistoprojektin yleistä tehokkuutta
5
Lindström, Gustav. "The Challenges of adopting DevOps". Thesis, KTH, Skolan för industriell teknik och management (ITM), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-264179.
Texto completoResumen
In traditional Software Development Life Cycle, medium and large organizations tend to divide the activities of Operations and Development into separate departments. These groups often have a troublesome relationship because of different incentives during the software delivery process. As a result, conflicts occur between development and operations personnel as they blame each other to be the cause of long lead times and inefficient software delivery processes. The concept of DevOps emerged trying to resolve the problem that arises when separating the work of Development and Operations into organizational silos. The term DevOps is a combination of the abbreviations of Development (Dev) and Operations (Ops). DevOps aim to create a coalition that spans between Development (software developers and quality assurance) and Operation (experts responsible to roll out software to production and managing the infrastructure, e.g. system, network and database administrators and technicians). The idea is to increase the speed of the software delivery process and to quickly solve critical issues, enable organizations to better serve their customers. DevOps means that development teams who previously were solely responsible for the development of their applications now have to manage and govern both development and operational responsibilities. Thus, the adoption of DevOps might introduce new type of challenges and implications for the traditional development teams. Current literature and research about DevOps focus mainly on the challenges that DevOps attempts to overcome. There is a lack of literature on the challenges that practitioners encounter during the adoption of DevOps. As more organizations and companies tend to adopt the concept of DevOps, it increases the need to understand potential challenges and effects of adopting DevOps. Therefore, the aim of this study is to investigate the challenges that development teams encounter during the adoption of DevOps. This research was conducted by an inductive research approach through a single qualitative case study, with the use of semi-structured interviews. In total, four main challenges and fourteen sub-challenges were identified in this study. The four main challenges identified was, lack of awareness, lack of support for DevOps, implementing DevOps technology and adapting organizational processes to DevOps. This study concludes that the adoption of DevOps has a profound impact on the role of a software developer, and that the traditional role of a software developer needs to be evolved. The research provides four recommendations and means to overcome the challenges identified in this research, establishing common ways of working and spreading the knowledge, building commitment and trust by smarter seating, allocate time and resources to transition and trying out with one team and one application.I traditionell livscykel för mjukvaruutveckling tenderar medelstora och stora organisationer att dela upp verksamheten i drift och utveckling i separata avdelningar. Dessa grupper har ofta en besvärlig relation på grund av olika incitament under mjukvaruleveransprocessen. Som ett resultat uppstår konflikter mellan utvecklings- och driftpersonal eftersom de beskyller varandra för att vara orsaken till långa ledtider och ineffektiva mjukvaruleveransprocesser. Konceptet DevOps uppstod för att försöka lösa det problem som uppstår när man separerar utveckling och drift i organisationella silosar. Termen DevOps är en kombination av förkortningarna för utveckling (Dev) och drift (Ops). DevOps syftar till att skapa en koalition som sträcker sig mellan utveckling (mjukvaruutvecklare och kvalitetssäkring) och drift (system-, nätverks- och databasadministratörer och tekniker). Idén är att öka hastigheten av mjukvaruleveranser och att snabbt lösa kritiska problem för att förbättra organisationens förmåga att betjäna sina kunder. DevOps innebär att utvecklingsgrupper som tidigare enbart ansvarade för utvecklingen av sina applikationer nu även har driftansvar. Således kan antagandet av DevOps introducera nya typer av utmaningar och konsekvenser för de traditionella utvecklingsgrupperna. Aktuell litteratur och forskning kring DevOps fokuserar främst på de utmaningar som DevOps försöker övervinna. Därav finns det brist på litteratur kring de utmaningar som utövare stöter på under antagandet av DevOps. Eftersom fler organisationer och företag tenderar att adoptera begreppet DevOps ökar behovet av att förstå potentiella utmaningar och effekter av att anta DevOps. Därav är syftet med denna studie att undersöka de utmaningar som utvecklingsgrupper bemöter under antagandet av DevOps. Denna forskning utfördes genom en induktiv forskningsinriktning, en kvalitativ fallstudie och datainsamling genom halvstrukturerade intervjuer. Totalt identifierades fyra huvudutmaningar och fjorton sub utmaningar i denna studie. De fyra huvudsakliga utmaningar som identifierades var, brist på medvetenhet, brist på stöd för DevOps, implementering av DevOps-teknik och anpassning av organisationsprocesser till DevOps. Den här studien drar slutsatsen att antagandet av DevOps har en djupgående inverkan på rollen som en mjukvaruutvecklare och att den traditionella rollen som en mjukvaruutvecklare behöver utvecklas. Studien ger fyra rekommendationer och medel för att övervinna de utmaningar som identifierats, etablering av gemensamma sätt att arbeta och sprida kunskapen, bygga upp engagemang och förtroende genom smartare sittplatser, fördela tid och resurser till övergången samt prova med ett lag och en applikation.
6
Christensen, Jens y Jonatan Ekstedt. "Evaluation of Plugin Frameworks for the Jenkins Continuous Integration Build Server". Thesis, Linköpings universitet, Institutionen för datavetenskap, 2012. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-77181.
Texto completoResumen
Begreppet Continuous Integration (CI) är idag centralt för många företag i deras produktutveckling. Kraven dessa företag ställer på denna programvara skiljer sig, beroende på vad de använder den till och hur deras miljö ser ut. Jenkins är en programvara som används för CI, det är öppen källkod och har ett brett stöd för pluginer. Det finns ett stort urval av pluginer redan idag, men det är inte säkert att specifika önskemål från företag uppfylls av dessa. Därför är det intressant att på ett snabbt sätt ta fram specifika pluginer för dessa företag. Vi har i denna rapport utrett möjligheterna att utveckla pluginer till Jenkins i Ruby. Det senaste året har utveckling av pluginer i Ruby vuxit fram för Jenkins. Ramverket är fortfarande i ett tidigt stadium, men är utformat för att kunna falla tillbaka på det programmeringsspråk som Jenkins är skrivet i; Java. Det är på så sätt fullt möjligt att nu skriva pluginer i Ruby. Ruby är ett expressivt språk som är lätt att ta till sig, och den komplexitet som följer pluginutveckling i Java är till stor del gömd i Rubys ramverk. Vår slutsats är att Ruby är tillräckligt moget för att användas till pluginutveckling för Jenkins. Examensarbetet är uppdelat i två delar: en utvärdering av ramverken och deras verktyg för Ruby och Java, och en utvecklingsfas där vi fastställer vår analys. Den Rubyplugin som utvecklats kan ses som ett ‘proof-of-concept’, denna kan även användas som en slags mall vid framtida pluginutveckling vid Autoliv.The concept Continuous Integration (CI) is vital to many companies today in their product development. These companies may have specific demands on their CI-software, depending on how they are using it and what their development environment looks like. Jenkins is a software that is used for CI, it is open source and it has a wide support for plugins. There is a great selection of plugins available today, but it is not certain these plugins satisfy the specific requirements. It is therefore interesting to, in a quick way, develop plugins that meet these conditions. In this report, we have evaluated the possibility to develop plugins for Jenkins in Ruby. In the last year or so, plugin development in Ruby has been growing to become a viable option. The framework is still at a very early stage, but it is constructed in such a way so that one can always fall back on the language Jenkins was made in;; Java. Because of this it’s definitely possible to write plugins in Ruby. Ruby is an expressive language and it is easy to learn, the complexity that comes with writing plugins in Java for Jenkins is largely hidden in the Ruby framework. Our conclusion is that Ruby is ready to be used for plugin development for Jenkins. This thesis is divided into two parts, an evaluation of the frameworks and the tools for Java and Ruby, and a development phase where we concrete our analysis. The Ruby plugin that is developed in this thesis can be seen as proof-of-concept, it can also be used as a kind of template for future plugin development at Autoliv.
7
Gawell, Anders y Anton Kallin. "Teaching software testing in a modern development environment". Thesis, KTH, Skolan för elektroteknik och datavetenskap (EECS), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-261162.
Texto completoResumen
All developers understand the benefits of testing their code to ensure its functionality. Today’s market is moving further towards design principles where testing is a central or driving force during development. This puts a certain pressure on academia to supply these skills to their students.Recently the course II1302 Projects and project methods at the Royal Institute of Technology in Kista made a concerted effort to introduce the students of the course to these modern concepts. This thesis investigates how areas of testing can effectively be introduced to the students in the course, utilizing a tailored example that takes the area of testing into particular consideration and how to automate it via DevOps-tools provided by a cloud-based service. Further, it also makes an attempt to provide additional material to be used for teaching testing in conjunction with the example provided.The case study covers the development of an example application, meant to mirror a typical student project. It also covers how this was used for teaching the students about the testing areas considered. The covered testing areas include unit testing, integration testing and UI testing. With these given testing areas, the application and an associated learning module was developed for each area in question. Relevant standards, strategies and approaches was also identified for each of these areas.The thesis also presents important properties to take into consideration when developing similar examples in the future, based on the experiences obtained during the study. These include needs such as understandable by inexperienced students, applicability outside the course, adherence to established standards, tools that are simple to use and an architectural structure that allows for testing.Some improvements are also recommended: the students would benefit from learning software testing from an early stage of their studies. The content of the learning modules should also be brought to the students earlier in the course, so it can be applied in their projects at an early stage as well.Further research is also recommended to evaluate the suitability of using other cloud-based environments instead, and to evaluate the applicability of the learning modules for students of varying disabilities.Alla utvecklare förstår fördelarna med att testa kod för att garantera dess funktionalitet. Dagens industri går i en riktning där testning spelar en central del av design under utveckling av mjukvara. Denna tendens lägger en viss press på högskolan att lära ut dessa erfarenheter till dess studenter.På senare tid har kursen II1302 Projekt och projektmetoder på Kungliga Tekniska Högskolan i Kista tagit en stor ansats för att introducera sina studenter inför dessa moderna koncept. Denna uppsats undersöker hur testningsområdet effektivt kan introduceras till studenterna inom denna kurs, genom att utnyttja ett egengjort exempel som har området i fokus, samt att automatisera detta via DevOps-verktyg tillhandahållna av molnbaserade tjänster. Dessutom görs även en ansats för att tilldela ytterligare material som kan användas för att lära ut testning av mjukvara i samband med det givna exemplet.Fallstudien omfattar utvecklingen av en exempelapplikation, som var avsedd att likna ett typiskt studentprojekt. Den täcker även hur denna användes för att lära ut de betraktade testningsområdena till studenterna. De täckta områdena av testning inkluderar enhetstestning, integrationstestning och testning av användargränssnitt. Med dessa givna testningsområden utvecklades både applikationen och dess associerade lärmoduler för vardera testningområde i fråga. Relevanta standarder, strategier och metoder var också identifierade för vardera av dessa områden.Denna uppsats presenterar även ett antal viktiga egenskaper att hålla i åtanke vid utveckling av liknande exempel i framtiden, baserat på erfarenheterna från studien. Detta inkluderar behov som tillgänglighet för mindre erfarna studenter, applicerbarhet utanför själva kursen, tillämpning av etablerade standarder, utnyttjande av lättanvända verktyg och en arkitektur som tillåter testning.Några förbättringar föreslås även: studenterna skulle gynnas av att lära sig om mjukvarutestning i ett tidigt skede av sina studier. Innehållet i lärmodulerna bör även presenteras för studenterna tidigare i kursen för att kunna appliceras i deras projekt.Ytterligare forskning rekommenderas även för att utvärdera andra lämpliga molnbaserade miljöer, samt för att utvärdera tillämpbarheten av lärmodulerna hos studenter med inlärningssvårigheter.
8
Salomonsson, Tigerström Andreas y Sebastian Algrim. "Mjukvaruutveckling med Continuous Delivery : En kvalitativ fallstudie om Continuous Practices med fokus på Continuous Delivery". Thesis, Linnéuniversitetet, Institutionen för informatik (IK), 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:lnu:diva-76357.
Texto completoResumen
Denna uppsats studerar förutsättningarna för att implementera mjukvaruutvecklings - metoden Continuous Delivery (CDE). Problemställningen som lade grunden för studien, var att det inte finns någon enhetlig standard för CDE. Studien ämnade att undersöka om detta innebar att metoden har varierande innebörd inom olika företag och om de således, i viss mån tillämpar skilda tillvägagångssätt med metoden. Ytterligare en aspekt var att se vilka utmaningar företagen upplevde vid övergången till CDE. Att undersöka om det var främst organisatoriska eller utvecklingsrelaterade problem som upplevts. Samt hur de hanterade kommunikation och tillit till medarbetarna och arbetet inom verksamheten under förändringen. För att belysa problemen, beskrevs teori med fokus på organisatoriska och tekniska utmaningar med Continuous - metoderna: Continuous Integration (CI), Continuous Delivery (CDE) och Continuous Deployment (CD). Teorikapitlet samt tidigare studier inkluderade även forskning om kringliggande koncept som DevOps och LEAN. Metoder, vilka kan underlätta implementationen av CDE. Datainsamlingen genomfördes med öppna individuella intervjuer med representanter från sex stycken företag, där de delade med sig av deras erfarenheter av och syn på CDE. Studien visar att anledningen till att företag väljer att arbeta med CDE, är att de vill gå från utvecklingsmetoder, vilka kräver många beslut inför varje förändring, till ett mer flexibelt arbetssätt där de funnit fördelar som: bättre kvalitet på det som levereras, snabbare leverans av affärsvärde till kunder samt kortare feedback - loopar. Företag som gör en övergång till CDE väljer dessutom ofta att inte automatisera hela vägen ut till produktion, enligt CD, då de ser utmaningar med att säkra kvalitén. Studien har identifierat ett antal faktorer som viktiga för en framgångsrik implementering av CDE, samt faktorer som kan resultera i en svår övergång.This thesis studies the conditions needed for implementing the software development method Continuous Delivery (CDE). The problem identified for the study, is that there is no standardized approach for CDE as of today. The intentions of the study were to determine whether this means that the method will have a shifting tenor within different companies, and if so, will these companies implement the method with different approaches. Another aspect was to determine which types of challenges the companies were faced with during the transition towards CDE. To review whether the challenges were foremost organisational or development related. And how the organisations handled the communication and trust towards the co-workers and the development work within the organisation during the change towards the method. To highlight these issues, we presented theories with focus on organisational and technical challenges with the different Continuous practices were made. The practices being: Continuous Integration (CI), Continuous Delivery (CDE) and Continuous Deployment (CD). The theory chapter and former studies also contains research about surrounding concepts such as DevOps and LEAN methods, which can aim to facilitate the implementation of CDE. The empirical data collection was performed using open individual interviews with informants from six different companies, where they shared their experience and views on the method CDE. The study demonstrates that the reason organisations chose to implement CDE, is that they want to transform from software development methods, which requires a lot of decision making for any change, to a more flexible work procedure, in order to experience benefits such as: better quality of what is delivered, faster deliveries of business value to the customers and faster feedback-loops. Organisations that make the transition towards CDE also tend not to automate all the way to production, as in agreement with CD, this because the organisations identify challenges with assuring that the quality is sufficient. The study has identified a number of factors that are essential for a successful implementation of CDE, along with factors that may result in a less successful implementation.
9
Karvonen, T. (Teemu). "Continuous software engineering in the development of software-intensive products:towards a reference model for continuous software engineering". Doctoral thesis, Oulun yliopisto, 2017. http://urn.fi/urn:isbn:9789526216560.
Texto completoResumen
Abstract Continuous software engineering (CSE) has instigated academic debate regarding the rapid, parallel cycles of releasing software and customer experimentation. This approach, originating from Web 2.0 and the software-as-a-service domain, is widely recognised among software-intensive companies today. Earlier studies have indicated some challenges in the use of CSE, especially in the context of business-to-business and product-oriented, embedded systems development. Consequently, research must address more explicit definitions and theoretical models for analysing the prerequisites and organisational capabilities related to the use of CSE. This dissertation investigates various approaches to conducting empirical evaluations related to CSE. The study aims to improve existing models of CSE and to empirically validate them in the context of software companies. The study also aims to accumulate knowledge regarding the use of CSE, as well as its impacts. The case study method is applied for the collection and analysis of empirical data. Twenty-seven interviews are conducted at five companies. In addition, a systematic literature review is used to synthesise the empirical research on agile release engineering practices. Design science research is used to portray the model design and the evaluation process of this dissertation. Three approaches for evaluating CSE are constructed: (1) LESAT for software focuses on enterprise transformation using an organisational self-assessment approach, (2) STH+ extends the “Stairway to Heaven” model and evaluates company practices with respect to evolutionary steps towards continuous experimentation-driven development, and (3) CRUSOE defines 7 key areas and 14 diagnostic questions related to the product-intensive software development ecosystem, strategy, architecture, and organisation, as well as their continuous interdependencies. This dissertation states the relevance of CSE in the context of product-intensive software development. However, more adaptations are anticipated in practices that involve business and product development stakeholders, as well as company external stakeholdersTiivistelmä Jatkuva ohjelmistotuotanto on herättänyt keskustelua nopeasta, samanaikaisesta ohjelmistojulkaisemisesta ja asiakaskokeiluista. Toimintatapa on peräisin Web 2.0 ja software-as-a-service yhteydestä, mutta se tunnetaan nykyään yleisesti ohjelmistoja kehittävissä yrityksissä. Aiemmat tutkimukset ovat osoittaneet haasteita jatkuvan ohjelmistotuotannon käytössä. Erityisesti haasteita on havaittu yritykseltä yritykselle liiketoiminnassa ja tuotepainotteisten sulautettujen järjestelmien yhteydessä. Näin ollen on havaittu tarve tutkimuksen avulla kehittää täsmällisempiä määritelmiä ja teoreettisia malleja, joilla voidaan analysoida jatkuvan ohjelmistotuotannon käyttöön liittyviä edellytyksiä ja organisaatioiden kyvykkyyksiä. Tässä väitöskirjassa tutkitaan malleja, joilla voidaan empiirisesti arvioida jatkuvaa ohjelmistotuotantoa. Tutkimuksella pyritään parantamaan nykyisiä malleja ja arvioimaan niiden käyttöä ohjelmistoyrityksissä. Lisäksi tutkimuksella pyritään kasvattamaan tietoa jatkuvasta ohjelmistotuotannosta ja sen vaikutuksista. Tiedon keräämiseen ja analysointiin käytettiin tapaustutkimus menetelmää. Kaksikymmentäseitsemän haastattelua tehtiin viidessä yrityksessä. Lisäksi tehtiin ketterään ohjelmistojulkaisuun keskittyvä systemaattinen kirjallisuuskatsaus. Väitöskirjassa käytetään Design Science Research menetelmää kuvaamaan tutkimuksen eri vaiheita, joissa malleja suunniteltiin ja arvioitiin. Tutkimuksessa rakennettiin kolme tapaa jatkuvan ohjelmistotuotannon arvioimista varten: (1) LESAT for Software keskittyy organisaation muutoskyvykkyyden arviointiin käyttäen itsearviointimenetelmää, (2) STH+, laajentaa ”Stairway to Heaven” mallia ja arvioi yrityksen käytäntöjä eri evoluutioaskelmilla matkalla kohti kokeilupainotteista tuotekehitystä, (3) CRUSOE määrittelee seitsemän pääaluetta ja 14 kysymystä liittyen tuotekehityksen ekosysteemiin, strategiaan, arkkitehtuuriin, organisointiin sekä näiden välisiin jatkuviin riippuvuuksiin. Väitöskirja osoittaa jatkuvan ohjelmistokehityksen olevan merkityksellinen myös tuotepainotteisessa ohjelmistokehityksessä. Nähtävissä kuitenkin on, että useita nykykäytäntöjä on tarvetta muokata. Erityisesti muokkaustarvetta on tuotekehityksen ja liiketoiminnan sidosryhmiin ja yrityksen ulkoisiin sidosryhmiin liittyvissä käytännöissä
10
Koivuniemi, J. (Jarmo). "Shortening feedback time in continuous integration environment in large-scale embedded software development with test selection". Master's thesis, University of Oulu, 2017. http://urn.fi/URN:NBN:fi:oulu-201704121470.
Texto completoResumen
Continuous integration is one of the Extreme Programming practices and is used in agile software development to provide rapid feedback and to have a working system at all times. In continuous integration, a developer commits code to projects mainline at least once a day which triggers automated build and tests. Large projects can struggle with continuous integration because with growing code base the number of tests that need to execute after a developer checks in code also gets bigger. The growing number of tests means that the build times can become long. With embedded systems, the problem can be even bigger as the testing is dependent on target hardware. With long builds, feedback becomes longer thus making it harder to practice continuous integration.
Long feedback leads to infrequent integrations which can result in continuous integration becoming a bottle-neck to the development process and can even affect an ability to release software frequently. To shorten the feedback this thesis implements an automated test selection tool to work in continuous integration environment. The test selection tool selects the tests that are relevant for a specific code change instead of executing all tests for each commit. The case company is suffering from long feedbacks and the expensiveness of testing has become a problem. This thesis hopes to solve that problem with the implemented test selection tool. The tool is evaluated using three metrics; feedback time improvement, reduction in number of executed test cases and fault finding capability.
The test selection tool was tested with two test suites with different size by collecting data from continuous integration system. “Shock” suite consisted of about 30 test cases and regression suite about 800 test cases. The average improvement in feedback time for Shock tests was 29.3% and 55.7% for regression suite. The test selection tool reduced the number of test cases executed in Shock by 67.1% and 78.2% for regression suite. Fault finding capability was measured for Shock suite and the tool was able to find same faults as the full suite in 97.8% of the cases. Statistical tests show that the test selection has a significant impact on feedback time. By being able to safely shorten the feedback, the test selection tool can potentially help developers in the case company to practice continuous integration.
11
Ilebode, Terry y Annwesh Mukherjee. "FROM CHAOS TO ORDER: A study on how data-driven development can help improve decision-making". Thesis, Malmö universitet, Fakulteten för teknik och samhälle (TS), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:mau:diva-20070.
Texto completoResumen
AbstractThe increasing amount of data available from software systems has given a unique opportunity for software development organizations to make use of it in decision-making. There are several types of data such as bug reports, website interaction information, product usage extent or test results coming into software-intensive companies and there is a perceived lack of structure associated with the data. The data is mostly scattered and not in an organized form to be utilized further. The data, if analyzed in an effective way, can be useful for many purposes, especially in decision-making. The decisions can be on the level of business or on the level of product execution. In this paper, through a literature review, an interview study and a qualitative analysis we categorize different types data that organizations nowadays collect. Based on the categorization we order the different types of decisions that are generally taken in a software development process cycle. Combining the two we create a model to explain a recommended process of handling the surge of data and making effective use of it. The model is a tool to help both practitioners and academicians who want to have a clearer understanding of which type of data can best be used for which type of decisions. An outline of how further research can be conducted in the area is also highlighted.
12
Standar, Magnus. "Continuous architecture in a large distributed agile organization : A case study at Ericsson". Thesis, Linnéuniversitetet, Institutionen för datavetenskap (DV), 2017. http://urn.kb.se/resolve?urn=urn:nbn:se:lnu:diva-65014.
Texto completoResumen
Agile practices have become norm, also in large scale organizations. Applying agile methods includes introducing continuous practices, including continuous architecture. For web scale applications microservices is a rising star. This thesis investigates if microservices could be an answer also for embedded systems to tackle the synchronizing problem of many parallel teams.
13
Karlsson, Johan. "A practical approach to implementing Continuous Delivery : A case study at the Swedish Board of Agriculture". Thesis, Tekniska Högskolan, Högskolan i Jönköping, JTH, Datateknik och informatik, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:hj:diva-39035.
Texto completoResumen
This thesis has been carried out at the Swedish Board of Agriculture. The client wants to orientate towards a development environment and architecture that allows for more frequent software deliveries than in the current situation, to increase the business benefits of the development work carried out. The purpose of this thesis is to develop a process to iteratively move towards an architecture and development environment that enable Continuous Delivery. Continuous delivery aims to a very high extent to treat a developer's code as part of a potential release candidate. This in turn causes high demands on being able to secure the reliability of both the infrastructure and the individual developers’ contributions. The work has been carried out in cooperation with developers, infrastructure engineers, architects and team leaders on The Swedish Board of Agriculture. Theories have been tested within the IT organization to ensure their reliability and applicability in the organization. A process has been developed with the limitation that it has not been tested in a production environment because of the limited timeframe available. However, it has been demonstrated that the process is feasible for the systems that acted as the main testing candidates during the thesis.Detta examensarbete har utförts vid Statens Jordbruksverk. Uppdragsgivaren önskar att orientera sig mer mot en utvecklingsmiljö och arkitektur som möjliggör tätare leveranser än i dagsläget, för att öka verksamhetsnyttan av det utvecklingsarbete som genomförs. Syftet med detta examensarbete är att ta fram en process för att iterativt kunna gå mot en arkitektur som möjliggör för Continuous Delivery, eller kontinuerlig leverans. Kontinuerlig leverans syftar till att i mycket hög mån behandla en utvecklares kod som en del av en potentiell releasekandidat. Detta för i sin tur med sig höga krav på att kunna säkra tillförlitligheten av både infrastruktur samt den individuelle utvecklarens bidrag. Arbetet har utförts i samarbete med utvecklare, infrastrukturtekniker, arkitekter samt teamledare på Jordbruksverket. Teorier har testats inom IT-organisationen för att se dess tillförlitlighet samt tillämplighet på just Jordbruksverkets organisation. Arbetet påvisar att det är möjligt att dela upp monolitiska system och gå närmare något som liknar kontinuerlig leverans, utan att behöva genomföra stora förändringar inom organisationen. En process har tagits fram med begräsning att den inte testats i produktionsmiljö på grund av tidsbrist. Det har dock påvisats att processen är gångbar för det system som varit testkandidat genom arbetets gång.
14
Azizi, Maral. "Application of Adaptive Techniques in Regression Testing for Modern Software Development". Thesis, University of North Texas, 2019. https://digital.library.unt.edu/ark:/67531/metadc1538762/.
Texto completoResumen
In this dissertation we investigate the applicability of different adaptive techniques to improve the effectiveness and efficiency of the regression testing. Initially, we introduce the concept of regression testing. We then perform a literature review of current practices and state-of-the-art regression testing techniques. Finally, we advance the regression testing techniques by performing four empirical studies in which we use different types of information (e.g. user session, source code, code commit, etc.) to investigate the effectiveness of each software metric on fault detection capability for different software environments. In our first empirical study, we show the effectiveness of applying user session information for test case prioritization. In our next study, we apply learning from the previous study, and implement a collaborative filtering recommender system for test case prioritization, which uses user sessions and change history information as input parameter, and return the risk score associated with each component. Results of this study show that our recommender system improves the effectiveness of test prioritization; the performance of our approach was particularly noteworthy when we were under time constraints. We then investigate the merits of multi-objective testing over single objective techniques with a graph-based testing framework. Results of this study indicate that the use of the graph-based technique reduces the algorithm execution time considerably, while being just as effective as the greedy algorithms in terms of fault detection rate. Finally, we apply the knowledge from the previous studies and implement a query answering framework for regression test selection. This framework is built based on a graph database and uses fault history information and test diversity in attempt to select the most effective set of test cases in term of fault detection capability. Our empirical evaluation of this study with four open source programs shows that our approach can be effective and efficient by selecting a far smaller subset of tests compared to the existing techniques.
15
Lundsten, David y Alexander Timander. "De fyra Hörnstenarna : En fallstudie om kontinuerliga leveranser av mjukvara i agil systemutveckling". Thesis, Umeå universitet, Institutionen för informatik, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:umu:diva-147912.
Texto completoResumen
When the traditional approach to system development transitioned over to agile methods the demand for ways to continuously deliver valuable software increased. With the increasing interest in these methods the umbrella term DevOps were introduced in 2008. DevOps is the practice to shorten the time, as well as streamlining the process, between changes in the source code and when it reaches the customer. This study aimed at investigating the process of adopting DevOps practices and identify success factors and challenges in this transition. We conducted a quality approached case study on a DevOps team in a multinational IT-consulting firm. Four explorative interviews were conducted based on categories identified in relevant literature as well as basis provided by the case company. We discovered that an implementation of continuous practices is far more complex than we initially thought. It is related to more fields outside the technical aspect that must be considered during a transition. Our findings include four critical success factors for a successful DevOps implementation; conscious staff, conscious organization, functional infrastructure and adapted business model. Embedded in these critical success factors we were able to identify challenging fields that should be considered when adopting DevOps. These critical success factors and challenges was the basis for our model presented in the study.
16
Beatham, Simon. "Development of an integrated business improvement system for construction". Thesis, Loughborough University, 2003. https://dspace.lboro.ac.uk/2134/792.
Texto completoResumen
The construction industry has inherent problems due to its structure and fragmentation. Its poor performance has been challenged by its client base and it has been forced to seek ways to deliver improved performance. This project was initiated as a response to this challenge and represents one organisation's attempt to deliver improvements. This organisation provides both design and construction solutions, offering ‘total life of asset support' from business consultancy through to decommissioning, in a neutral contractual environment. Initial investigations of the integration of design and construction and of the use of the EFQM Excellence Model concluded that a holistic view of the organisation's performance was needed. Most organisations use traditional, easily quantifiable measures, such as time and cost, whilst neglecting the softer cultural issues, as a way of assessing overall business performance. This prompted further research into the use of performance measurement and also a review of the culture that existed within the organisation. It became clear that many performance initiatives failed because of the lack of ‘Change Action driven by Results (CAR)'. The failure to initiate change or implement action based on the results achieved, means that performance measures are not being integrated into the management systems of the organisations. Based on the conclusions of this work, this project has developed and implemented the Integrated Business Improvement System (IBIS) within the primary case study unit and also two other organisations, all of which are part of AMEC Plc. The project details the barriers that were experienced during the development and implementation of the system and concludes that it is the human component that is critical for the successful implementation and use of any improvement system. The findings of this work have been presented in five peer- reviewed papers.
17
Wallström, Andreas. "Guidance on Implementing Agile Software Development Methods within a Traditional Environment". Thesis, KTH, Industriell ekonomi och organisation (Inst.), 2021. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-296990.
Texto completoResumen
Agile software development methods keep increasing in popularity. Many organizations who are using traditional software development methods, such as water-fall and stagegate based methods are switching to agile software development methods. This transition can be challenging, especially for organizations using project governance models that hinder the adoption of agile practices. This study aims to provide guidance to managers on how to introduce agile software development methods in such traditional organizations. The study is a single-case study on a large governmental agency in Sweden. Eight interviews with developers, team-leads and managers were conducted. The study identifies practical tools and ideas that managers can use to introduce a shared definition of agile, adopting an agile mindset, dedicated teams, and CI&CD. Together, this guidance supports managers with the introduction of agile software development methods in organizations utilizing traditional project governance structures and traditional software development methods.Agila systemutvecklingsmetoder fortsätter öka i popularitet. Många organisationer som använder sig av traditionella systemutvecklingsmetoder så som vattenfallsmodellen byter till agila systemutvecklingsmetoder. Denna övergång kan vara utmanande, speciellt för organisationer som använder sig av projektbaserade förvaltningsmodeller som hindrar implementeringen av agila metoder. Den här studien syftar till att ge vägledningen till chefer kring hur de kan introducera agila systemutvecklingsmetoder iden nyss nämnda typen av traditionella organisationer. Studien är en fallstudie gjort på en stor myndighet i Sverige. Åtta intervjuer med systemutvecklare, lag-ledare och chefer har utförts. Studien identifierar verktyg och idéer som chefer kan använda sig avför att introducera en delad gemensam definition av agilt, anamma ett agilt tankesätt, introducera dedikerade teams och CI&CD. Tillsammans hjälper de här verktygen med introduktionen av agila systemutvecklingsmetoder i organisationer som använder sig av traditionella systemutvecklingsmetoder och förvaltningsmodeller.
18
Bacha, Kirill. "DevOps compliant guidelines for project inception-elaboration phases". Thesis, Linnéuniversitetet, Institutionen för datavetenskap och medieteknik (DM), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:lnu:diva-84853.
Texto completoResumen
DevOps is an ill-defined but trending approach to software development. Many companies are seduced by its promises of reduced costs and risks. DevOps life-cycle is often represented as a continuous everything, but very little is said about how to get the ball rolling. This report examines how DevOps definitions are represented in the initiation of Agile projects. By interviewing developers and mapping their project initiation activities in a DevOps context, a set of guidelines was formed. Continuous Integration and Deployment were found most prominent DevOps attributes from a developer’s perspective. The operational responsibility is skewed toward maintenance, with low interest in further adjustment.
19
Ryd, Jonatan y Jeffrey Persson. "Development of a pipeline to allow continuous development of software onto hardware : Implementation on a Raspberry Pi to simulate a physical pedal using the Hardware In the Loop method". Thesis, KTH, Hälsoinformatik och logistik, 2021. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-296952.
Texto completoResumen
Saab want to examine Hardware In the Loop method as a concept, and how an infrastructure of Hardware In the Loop would look like. Hardware In the Loop is based upon continuously testing hardware, which is simulated. The software Saab wants to use for the Hardware In the Loop method is Jenkins, which is a Continuous Integration, and Continuous Delivery tool. To simulate the hardware, they want to examine the use of an Application Programming Interface between a Raspberry Pi, and the programming language Robot Framework. The reason Saab wants this examined, is because they believe that this method can improve the rate of testing, the quality of the tests, and thereby the quality of their products.The theory behind Hardware In the Loop, Continuous Integration, and Continuous Delivery will be explained in this thesis. The Hardware In the Loop method was implemented upon the Continuous Integration and Continuous Delivery tool Jenkins. An Application Programming Interface between the General Purpose Input/Output pins on a Raspberry Pi and Robot Framework, was developed. With these implementations done, the Hardware In the Loop method was successfully integrated, where a Raspberry Pi was used to simulate the hardware.Saab vill undersöka metoden Hardware In the Loop som ett koncept, dessutom hur en infrastruktur av Hardware In the Loop skulle se ut. Hardware In the Loop baseras på att kontinuerligt testa hårdvara som är simulerad. Mjukvaran Saab vill använda sig av för Hardware In the Loop metoden är Jenkins, vilket är ett Continuous Integration och Continuous Delivery verktyg. För attsimulera hårdvaran vill Saab undersöka användningen av ett Application Programming Interface mellan en Raspberry Pi och programmeringsspråket Robot Framework. Anledning till att Saab vill undersöka allt det här, är för att de tror att det kan förbättra frekvensen av testning och kvaliteten av testning, vilket skulle leda till en förbättring av deras produkter. Teorin bakom Hardware In the Loop, Continuous Integration och Continuous Delivery kommer att förklaras i den här rapporten. Hardware In the Loop metoden blev implementerad med Continuous Integration och Continuous Delivery verktyget Jenkins. Ett Application Programming Interface mellan General Purpose Input/output pinnarna på en Raspberry Pi och Robot Framework blev utvecklat. Med de här implementationerna utförda, så blev Hardware Inthe Loop metoden slutligen integrerat, där Raspberry Pis användes för att simulera hårdvaran.
20
Vakilalroayayi, Ahmadreza. "Automating the monotonous workflow : Mobile application development and deployment". Thesis, Linnéuniversitetet, Institutionen för datavetenskap och medieteknik (DM), 2021. http://urn.kb.se/resolve?urn=urn:nbn:se:lnu:diva-106205.
Texto completoResumen
To create, update, or deploy a mobile application, a collection of hand-operated works must be satisfied. In this project, regardless of the mobile application's code and its core functionalities, which can be an e-book, an application, or even a mobile game, we will study how to automate, visualize and simplify the following manual procedures: 1.Create a remote Git repository for the mobile application. 2.Constructing or altering the mobile application's configuration or graphical contents. 3.Push all changes to the remote Git repository. 4.Deploy or distribute the mobile application from its Git repository after each push.För att skapa, uppdatera eller distribuera en mobilapplikation måste en samling handstyrda verk uppfyllas. I detta projekt, oavsett mobilapplikationens kod och dess kärnfunktioner, som kan vara en e-bok, en applikation eller till och med ett mobilspel, kommer vi att studera hur man automatiserar, visualiserar och förenklar följande manuella procedurer: 1. Skapa ett avlägset Git -arkiv för mobilapplikationen. 2.Konstruera eller ändra mobilapplikationens konfiguration eller grafiska innehåll. 3.Push alla ändringar i det externa Git -arkivet. 4. Distribuera mobilappen från sitt Git -arkiv efter varje ändring.
21
Setlhaku, Mpho [Verfasser]. "Development of a Novel Two-stage Butanol Production Process: Integrating Continuous and Fed-batch Fermentation / Mpho Setlhaku". Aachen : Shaker, 2014. http://d-nb.info/1053361548/34.
Texto completo
22
Vlk, Tomáš. "Využití Nix/NixOps pro průběžnou integraci a nasazení software při vývoji". Master's thesis, Vysoké učení technické v Brně. Fakulta informačních technologií, 2020. http://www.nusl.cz/ntk/nusl-417202.
Texto completoResumen
This thesis deals with the application of the functional packaging system Nix and its ecosystem (NixOS, NixOps) for CI/CD in agile development. When using these technologies, the problems caused by different environments are virtually eliminated without the need of containerization. The thesis contains a description of the possibilities and the shortcomings of Nix/NixOps and it proposes a general procedure for the use of these technologies in individual phases of agile development and CI/CD. Thanks to Nix/NixOps, the implementation of CI/CD is very simple and the whole process is also reproducible. The output of the work is a set of the examples demonstrating the use of Nix/NixOps in various projects, which is available as open-source. Thanks to this set, the developers can use Nix quickly and easily in any project, without having to study a large amount of materials.
23
Schröter, Jens [Verfasser] y A. [Akademischer Betreuer] Albers. "Das erweiterte X-in-the-Loop-Framework zur durchgängigen Integration von Optimierungsverfahren in den Produktentwicklungsprozess am Beispiel der Entwicklung energieeffizienter Fahrzeuge = The advanced X-in-the-Loop-Framework for continuous integration of optimization procedures into the product development process using examples of the development of fuel efficient vehicles / Jens Schröter. Betreuer: A. Albers". Karlsruhe : KIT-Bibliothek, 2013. http://d-nb.info/1043258000/34.
Texto completo
24
Momenan, Bahareh. "Development of a Thick Continuum-Based Shell Finite Element for Soft Tissue Dynamics". Thesis, Université d'Ottawa / University of Ottawa, 2017. http://hdl.handle.net/10393/35908.
Texto completoResumen
The goal of the present doctoral research is to create a theoretical framework and develop a numerical implementation for a shell finite element that can potentially achieve higher performance (i.e. combination of speed and accuracy) than current Continuum-based (CB) shell finite elements (FE), in particular in applications related to soft biological tissue dynamics. Specifically, this means complex and irregular geometries, large distortions and large bending deformations, and anisotropic incompressible hyperelastic material properties.
The critical review of the underlying theories, formulations, and capabilities of the existing CB shell FE revealed that a general nonlinear CB shell FE with the abovementioned capabilities needs to be developed. Herein, we propose the theoretical framework of a new such CB shell FE for dynamic analysis using the total and the incremental updated Lagrangian (UL) formulations and explicit time integration. Specifically, we introduce the geometry and the kinematics of the proposed CB shell FE, as well as the matrices and constitutive relations which need to be evaluated for the total and the incremental UL formulations of the dynamic equilibrium equation. To verify the accuracy and efficiency of the proposed CB shell element, its large bending and distortion capabilities, as well as the accuracy of three different techniques presented for large strain analysis, we implemented the element in Matlab and tested its application in various geometries, with different material properties and loading conditions. The new high performance and accuracy element is shown to be insensitive to shear and membrane locking, and to initially irregular elements.
25
Ochei, Laud Charles. "Architecting the deployment of cloud-hosted services for guaranteeing multitenancy isolation". Thesis, Robert Gordon University, 2017. http://hdl.handle.net/10059/2448.
Texto completoResumen
In recent years, software tools used for Global Software Development (GSD) processes (e.g., continuous integration, version control and bug tracking) are increasingly being deployed in the cloud to serve multiple users. Multitenancy is an important architectural property in cloud computing in which a single instance of an application is used to serve multiple users. There are two key challenges of implementing multitenancy: (i) ensuring isolation either between multiple tenants accessing the service or components designed (or integrated) with the service; and (ii) resolving trade-offs between varying degrees of isolation between tenants or components. The aim of this thesis is to investigate how to architect the deployment of cloud-hosted service while guaranteeing the required degree of multitenancy isolation. Existing approaches for architecting the deployment of cloud-hosted services to serve multiple users have paid little attention to evaluating the effect of the varying degrees of multitenancy isolation on the required performance, resource consumption and access privilege of tenants (or components). Approaches for isolating tenants (or components) are usually implemented at lower layers of the cloud stack and often apply to the entire system and not to individual tenants (or components). This thesis adopts a multimethod research strategy to providing a set of novel approaches for addressing these problems. Firstly, a taxonomy of deployment patterns and a general process, CLIP (CLoud-based Identification process for deployment Patterns) was developed for guiding architects in selecting applicable cloud deployment patterns (together with the supporting technologies) using the taxonomy for deploying services to the cloud. Secondly, an approach named COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) was developed together with supporting algorithms and then applied to three case studies to empirically evaluate the varying degrees of isolation between tenants enabled by multitenancy patterns for three different cloud-hosted GSD processes, namely-continuous integration, version control, and bug tracking. After that, a synthesis of findings from the three case studies was carried out to provide an explanatory framework and new insights about varying degrees of multitenancy isolation. Thirdly, a model-based decision support system together with four variants of a metaheuristic solution was developed for solving the model to provide an optimal solution for deploying components of a cloud-hosted application with guarantees for multitenancy isolation. By creating and applying the taxonomy, it was learnt that most deployment patterns are related and can be implemented by combining with others, for example, in hybrid deployment scenarios to integrate data residing in multiple clouds. It has been argued that the shared component is better for reducing resource consumption while the dedicated component is better in avoiding performance interference. However, as the experimental results show, there are certain GSD processes where that might not necessarily be so, for example, in version control, where additional copies of the files are created in the repository, thus consuming more disk space. Over time, performance begins to degrade as more time is spent searching across many files on the disk. Extensive performance evaluation of the model-based decision support system showed that the optimal solutions obtained had low variability and percent deviation, and were produced with low computational effort when compared to a given target solution.
26
Bložoňová, Barbora. "Správa testů s podporou scénářů BDD". Master's thesis, Vysoké učení technické v Brně. Fakulta informačních technologií, 2019. http://www.nusl.cz/ntk/nusl-403121.
Texto completoResumen
This thesis focuses on test management tools and automated testing. The project covers analysis of existing open source tools and proposes its own BDD orientated test management tool in the form of a web service. The project aims to specify and design this application based on the process of Behaviour driven development. The resulting application TestBuDDy allows for test library management. Changes on the test library are projected onto a remote repository of software under test (SUT) and triggers a test run (the test library is being run against SUT by the BDD framework). TestBuDDy is able to save the test run results, parse them into a report and generate and group found issues. The application also allows requirement management and user management. The application is integrated with the CI/CD tool Gitlab CI, the BDD framework JBehave and the issue tracker JIRA. The application is designed to help testers during their work and also to be expandable within the open source community.
27
Shpak, Yuliia. "Sledovaní současného stavu testovacích technik ve vybrané společnosti". Master's thesis, Vysoké učení technické v Brně. Fakulta podnikatelská, 2020. http://www.nusl.cz/ntk/nusl-417645.
Texto completoResumen
S vývojem informací, komunikací a technologií se moderní průmyslové řídicí systémy (ICS) potýkají čím dál více s otázkami automatického testováni pro zabezpečení stability a bezpečnosti systému. Z tohoto důvodu se testování stalo jednou z nejdůležitějších částí životního cyklu všech softwarů. V této diplomové práci budu zvažovat možnost využití stávajících zkušebních metod a nástrojů pro získání dostatečné jakosti a bezpečnosti softwaru v kontinuálních integračních systémech.
28
Šmerda, Jakub. "Zdokonalení procesu automatického testování softwarových aplikací". Master's thesis, Vysoké učení technické v Brně. Fakulta informačních technologií, 2014. http://www.nusl.cz/ntk/nusl-236078.
Texto completoResumen
The dissertation covers the process of automatic software testing. It describes fundamental principles of tests creation and presents common tools for concurrent integration. The main objective of the dissertation is improvement of the automatic testing process in the Department Corporate Technology Development Center of the Company Siemens Ltd., which was realized through the plug-in module for the TeamCity tool that makes reporting of test results more transparent. At the end of the dissertation, there are designed extensions of the plug-in module that could have a further benefit for automatic testing process by means of the TeamCity tool. The dissertation also includes the manual for easy installation of the implemented solution.
29
García, Díaz Vicente. "MDCI: Model-Driven Continuous Integration". Doctoral thesis, Universidad de Oviedo, 2011. http://hdl.handle.net/10803/80298.
Texto completoResumen
El propósito de esta Tesis es llevar a cabo un proceso en el que se aplique la práctica de la integración continua en un desarrollo de software dirigido por modelos de forma eficiente, mediante el cual los desarrollos de software puedan beneficiarse conjuntamente de las mejoras y ventajas que proporcionan la aproximación de desarrollo de la ingeniería dirigida por modelos y la práctica de la integración continua.
La aproximación de la ingeniería dirigida por modelos es el último salto natural de la ingeniería del software en cuanto a la búsqueda de métodos de desarrollo que elevan el nivel de abstracción hasta el punto en el que los expertos de un dominio de conocimiento, ajenos al mundo informático, son capaces de guiar y cambiar la lógica de los sistemas informáticos.
La práctica de la integración continua es una recomendación de las principales metodologías de desarrollo, que tiene como objetivo la realización de integraciones automáticas del software en etapas tempranas del desarrollo, ofreciendo ventajas como la reducción del riesgo intrínseco que, dado su carácter temporal y único, tienen todos los proyectos.
Con la unión de la ingeniería dirigida por modelos y de la práctica de la integración continua se busca ofrecer, a los equipos de desarrollo que trabajan utilizando algún tipo de iniciativa de la ingeniería dirigida por modelos, la posibilidad de integrar de forma continua y distribuida sus desarrollos. Al mismo tiempo, los clientes, verdaderos expertos del dominio de conocimiento en su ámbito de negocio, se benefician del aumento del nivel de abstracción de las técnicas de desarrollo para que ellos mismos, y de forma transparente, sean capaces de modificar su propio sistema informático sin la ayuda de personal técnico ajeno a su negocio, ahorrando así tiempo y costes.
Para cumplir con el objetivo de esta Tesis doctoral se construye un prototipo que salva los impedimentos actuales que no permiten la unión entre estos dos nuevos activos de la ingeniería del software. Los principales problemas encontrados están relacionados con la selección de una iniciativa de desarrollo apropiada, los sistemas de control de versiones especialmente adaptados para trabajar con modelos, la generación incremental de artefactos a partir de modelos y la adaptación a las herramientas actuales de integración continua de forma optimizada. La separación del trabajo realizado en diferentes bloques permite ofrecer soluciones de forma tanto aislada como en conjunto, dando lugar a un trabajo iterativo e incremental de comienzo a fin. Para analizar las ventajas que ofrece la propuesta de este trabajo frente a otras posibilidades de desarrollo, se realiza una evaluación mediante la creación de diferentes casos de prueba en los que la medición de diferentes parámetros ofrecen una estimación numérica de las ventajas reales obtenidas. El análisis descriptivo, el contraste de hipótesis y las técnicas de regresión permiten una mejor interpretación de los resultados. Finalmente, se define el proceso, objetivo último de este trabajo, mediante la respuesta a diferentes preguntas planteadas, que facilitan su comprensión y entendimiento.The purpose of this Thesis is to create a process in which the continuous integration practice can be applied to a model-driven software development in an e ective way, through which software developments can bene t jointly and simultaneously from the improvements and advantages provided by the model-driven engineering development approach and the continuous integration practice. The model-driven engineering approach is the last natural step of software engineering in the search for development approaches that raise the level of abstraction to the point that experts in a domain of knowledge, outside the computer world, are able to guide and change the logic of computer systems. The continuous integration practice is a recommendation of the most widely accepted development methodologies that aims to carry out automatic software integrations in early stages of development, o ering bene ts such as reducing the inherent risk that, given its unique nature, every project has. By merging the model-driven engineering and the continuous integration practice, the aim is to provide to development teams that work using some kind of model-driven engineering initiative, the possibility to integrate their developments in a continuous and distributed way. At the same time, customers, the real experts in the domain of knowledge in their eld of business, can bene t from the increased level of abstraction in developing techniques. Thus, they, in a transparent manner, are able to modify their own computer system without the help of external technical sta , so saving time and costs. To meet the objective of this Thesis, a prototype which saves all the current constraints that do not allow the union between these two new tools of software engineering is build. The main problems found were related to the selection of an appropriate development initiative, the version control systems specially adapted to working with models, the incremental generation of artifacts from models, and the optimized adaptation to existing continuous integration tools. The separation of work in di erent blocks can provide solutions, both in isolation or in conjunction, resulting in an iterative and incremental work from beginning to end. To analyze the bene ts of the proposal in this work compared to other development possibilities, an evaluation is performed by creating di erent test cases in which the measurement of di erent parameters can give a numerical estimate of the real bene ts obtained. The descriptive analysis, the hypothesis testing, and regression techniques allow a better interpretation of results. Finally, the process, the main objective of this work, is de ned by answering various questions posed to facilitate its comprehension and understanding.
30
Saari, M. (Marko). "Implementing new continuous integration tool". Master's thesis, University of Oulu, 2017. http://urn.fi/URN:NBN:fi:oulu-201706022481.
Texto completoResumen
This thesis studied the implementation of new Continuous Integration tool by focusing on existing problems and possible arising problems when implementing the new Continuous Integration tool. The thesis supported a project run by one international software development company with the main goal of replacing the current Continuous Integration tool from CruiseControl.NET with some more suitable alternative tool. The purpose of this thesis was to research about the topic and the existing tool to support the project in the implementation of the new Continuous Integration tool.
On the literature review, first the current state of Continuous Integration tool in the company was discussed. Then the literature review focused on the research about Continuous Integration, Continuous Delivery and Continuous Deployment. Alternative Continuous Integration tools were also studied as the company had two Continuous Integration tools to choose from: Bamboo and Jenkins.
The problems of the current Continuous Integration tool in the company were studied by conducting a survey. This survey was based on existing studies on the problems of Continuous Integration tools. Pilot testing and reviews also had impact on the final survey. 37 people out of the target population (89) participated in the survey. Survey results showed that those 37 people had different background but most of them had a long history in the company. Some participants did not answer all of the questions.
Two lists of issues were created by analyzing the survey results: Issues of current Continuous Integration tool and Issues when implementing new Continuous Integration tool. Two biggest issues from the list of issues of the current Continuous Integration tool were Lack of hardware and Build duration. Solution for these is that better hardware solves the Lack of hardware and improves the build duration with better hardware capacity and parallelization. Two biggest issues from the list of issues when implementing new Continuous Integration tool were Resistance to change and Lack of knowledge. The findings from past research suggest that implementing new Continuous Integration tool requires change of work of everyone to actually work. The solution for Lack of knowledge was that training is required for employees to actually know the way of using the new Continuous Integration tool. Suggested solutions were based on existing research and on the survey results.
The study provided two lists of Continuous Integration tool problems and proposals for possible solutions for those. The results can be used for selecting Continuous Integration tool as the study compared the results between Bamboo and Jenkins. Comprehensive study on the problems of Continuous Integration tool and the comparison of Continuous Integration tools provided reasoned support for the project of the company.
31
Kerkelä, J. (Joni). "Continuous Integration server performance monitoring". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201805091678.
Texto completoResumen
Continuous Integration (CI) is standard practice in Agile software development for source code management, including handling changes between development branches and master branch, and providing feedback for stakeholders. In the Continuous Integration the desirable practice is for development branches the be merged in to master branch daily. Before development branches is to be merged to master branch, the automated test tests builds are run on them and feedback of the tests is provided to developer and possible other stakeholders. If the tests are run without errors, the development branch is to be merged to master branch. The problems may arise, when the automated test build durations have variance. This leads developers to experience volatile service level causing irregularity to development process. The cause for the build duration variance can be the variance in the available system resources in the CI server. In some cases, the resource variation can cause false failures on the test build results as for example when there is defined maximum test build duration time limiter or when individual build step operation produces timeouts. To be able to resolve the resource starvation on the CI server, there needs to be means for identifying the resource starvation events in relation to test build statistics. By being able to identify relation between build statistics and resource starvation events, root cause, as starving resource, can be identified. By identifying the starving resource or resources, the system resources can be updated by adding more specific resource or handling the starvation through reserving the specific resource for key processes. The objective for this research is to implement monitoring tool for monitoring the Jenkins server’s builds and system resources during the builds. The thesis was conducted in the case company’s CI project including large-scale development project as customer project. The problem with case company was volatile test build durations and very insufficient data about system resources in the starvation events. The implemented monitoring tool achieved for providing extensive system resource data with combining it with the test build statistics to provide information about system resource availability in relation to test build statistics. The results indicate that the monitoring tool can be used for identifying resource starvation events and possible root causes for the events. The limitation of the implemented monitoring tool is the dependency for the database server as Elasticsearch. Elasticsearch was chosen to be used as database to establish adaptive monitoring data presenting functionality via Kibana server. This restricts portability of the monitoring tool to Jenkins instances as the monitoring tool needs mentioned instances for full functionality.
32
Kiendys, Petrus y Shadi Al-Zara. "Minimumkrav för ett CI-system". Thesis, Malmö högskola, Fakulteten för teknik och samhälle (TS), 2015. http://urn.kb.se/resolve?urn=urn:nbn:se:mau:diva-20216.
Texto completoResumen
När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas.En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”.Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel.When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.
33
Zhao, Xuhui. "Automatic analysis for continuous integration test failures". Thesis, Högskolan i Gävle, Elektronik, 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:hig:diva-30187.
Texto completoResumen
CI (Continuous Integration) is a software development practice which became more and more popular in last decade. Ericsson followed the trends and used CI several years. Because of the complexity of RBS (Radio Base Station) software few levels of CI have been implemented there. In RCS (RBS Control System) module CI there are many automatic JCAT (Java Common Auto Tester) test loops running every day and some of them failed. This thesis tries to find a way to classify these test failures automatically, so efficiency and lead time can be improved. Two methods are presented and investigated in this report, rule matching and machine learning. After analysis and comparisons rule matching approach is selected because it does not require huge effort in the initial phase and rule matched data can be used as labeled data for machine learning. This approach requires manual work to add new rules continuously but with correctly defined rules the accuracy is 100%, if the rule is general it can classify one type of issue including the ones which never happen before. One analysis system is designed and implemented, and only small update is required to the result report block of the CI flow. One matching example is showed and according to estimation this method could save many man hours every year.
34
Nyholm, Tobias. "Effektiv Mjukvaruutveckling Med Continuous Integration Och Automatisering". Thesis, KTH, Skolan för datavetenskap och kommunikation (CSC), 2013. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-142385.
Texto completoResumen
Effektiv utveckling kan göra lika stor skillnad som en eller kanske två extra utvecklare till teamet. För att ligga i framkant i effektiv mjukvaruutveckling så måste man definiera hur man är effektiv och vad det innebär. Man kan med stor framgång se sig om kring hur andra företag och organisationer har uppnått högre effektivitet. I rapporten diskuteras best practice och hur R2Meton AB jobbade i början av 2013. Sedan presenteras en utvecklingsmodell som R2Meton AB har implementerat för att bli mer effektiva. Modellen innefattar bland annat automatiserat bygge, tester, analyser och distribution. En högre grad av automatisering och analyser innebär en större enhetlighet och kvalitet. Hjärtat i hela modellen är givetvis en continuous integration server som stegvis tar processen framåt. Det är även den som ger feedback till utvecklarna om något har gått fel eller om dem brutit mot de förutbestämda kvalitetskraven. Med hög kvalitet, enhetlighet och tydliga policys så blir koden lättare att underhålla och vidareutveckla samt mer pålitlig.Effective software development may increase the productivity of the team as much as one or maybe two extra programmers. If you want to work efficiently you have to define what efficiency is and what it really means. You should study examples from other businesses and companies to see what they have done and try to understand why some of them succeeded and why some failed. The report will discuss best practices in software development and how R2Meton AB used to do their development. A model will be presented that R2Meton AB has implemented to improve their efficiency. The model describes how to automate builds, tests, analysis and deployment of the software to a testing environment. The increased automation and code analysis will provide more standardization and higher quality. Continuous integration is the heart of the model. The continuous integration server is the core that makes sure the process is moving forward. It does also give the developers feedback when the build breaks or when they fail to comply with the quality profile. With a high quality codebase, standards and clear policies you will get software that is easy to maintain, further develop and is more reliable.
35
VANGALA, SHIVAKANTHREDDY. "Pattern Recognition applied to Continuous integration system". Thesis, Blekinge Tekniska Högskola, Institutionen för datalogi och datorsystemteknik, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-15936.
Texto completoResumen
Context: Thisthesis focuses on regression testing in the continuous integration environment which is integration testing that ensures that changes made in the new development code to thesoftware product do not introduce new faults to the software product. Continuous integration is software development practice which integrates all development, testing, and deployment activities. In continuous integration,regression testing is done by manually selecting and prioritizingtestcases from a larger set of testcases. The main challenge faced using manual testcases selection and prioritization is insome caseswhereneeded testcases are ignored in subset of selected testcasesbecause testers didn’t includethem manually while designing hourly cycle regression test suite for particular feature development in product. So, Ericsson, the company in which environment this thesis is conducted,aims at improvingtheirtestcase selection and prioritization in regression testing using pattern recognition. Objectives:This thesis study suggests prediction models using pattern recognition algorithms for predicting future testcases failures using historical data. This helpsto improve the present quality of continuous integration environment by selecting appropriate subset of testcases from larger set of testcases for regression testing. There exist several candidate pattern recognition algorithms that are promising for predicting testcase failures. Based on the characteristics of the data collected at Ericsson, suitable pattern recognition algorithms are selected and predictive models are built. Finally, two predictive models are evaluated and the best performing model is integrated into the continuous integration system. Methods:Experiment research method is chosen for this research because discovery of cause and effect relationships between dependent and independent variables can be used for the evaluation of the predictive model.The experiment is conducted in RStudio, which facilitates to train the predictive models using continuous integration historical data. The predictive ability of the algorithms is evaluated using prediction accuracy evaluation metrics. Results: After implementing two predictive models (neural networks & k-nearest means) using continuous integration data, neural networks achieved aprediction accuracy of 75.3%, k-nearest neighbor gave result 67.75%. Conclusions: This research investigated the feasibility of an adaptive and self-learning test machinery by pattern recognition in continuous integration environment to improve testcase selection and prioritization in regression testing. Neural networks have proved effective capability of predicting failure testcase by 75.3% over the k-nearest neighbors.Predictive model can only make continuous integration efficient only if it has 100% prediction capability, the prediction capability of the 75.3% will not make continuous integration system more efficient than present static testcase selection and prioritization as it has deficiency of lacking prediction 25%. So, this research can only conclude that neural networks at present has 75.3% prediction capability but in future when data availability is more,this may reach to 100% predictive capability. The present Ericsson continuous integration system needs to improve its data storage for historical data at present it can only store 30 days of historical data. The predictive models require large data to give good prediction. To support continuous integration at present Ericsson is using jenkins automation server, there are other automation servers like Team city, Travis CI, Go CD, Circle CI which can store data more than 30 days using them will mitigate the problem of data storage.
36
Johansson, Aina. "Obstacles to Continuous Integration for autonomous vehicles". Thesis, KTH, Maskinkonstruktion (Inst.), 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-187734.
Texto completoResumen
Detta examensarbete studerar de hinder som uppstår vid implementation av Continuous Integration (CI), en agil utvecklingsmetod, på autonoma fordon. I och med att CI har blivit allt mer populärt, så är det aktuellt att utvärdera om det finns hinder för att använda sig av CI även för system som inte bara är rena mjukvarusystem.Studien har två frågeställningar:Vilka hinder existerar för att implementera Continuous Integration för fordon?Vilka hinder existerar för att implementera Continuous Integration för autonoma fordon?Studien visar på att det finns ett antal hinder, som kan sorteras in i nivåer, för att implementera CI: de man kan förvänta sig vid användning av CI, av CI för Cyber-Fysiska System, och CI för fordon. Det visade sig att dessa hinder ackumulerar vid helsystemstestning, och även om CI upplevs som fördelaktig av programmerare så blir det en tung belastning för helsystemstestare. Gällande CI för autonoma fordon, så är mycket okänt, men mycket tyder på att det som redan upplevs som svårt vid utveckling av fordon, såsom komplexitet, kommer förvärras.För att lösa dessa problem föreslår den här studien att man i framtiden fokuserar både på tekniska och organisationsrelaterade aspekter av utvecklingsprocesser, t.ex. genom att definiera övergripande planer för test och testanalys, samt vad som skall kommuniceras och på vilket sätt.This master thesis studies the obstacles that arise when implementing Continuous Integration (CI), an agile development method, for autonomous vehicles. As CI has become increasingly popular it has become a point of interest to examine whether there are obstacles to Continuous Integration for systems, which are not pure software systems. The study aims to answer the two questions:What are the obstacles for Continuous Integration for vehicles? What are the obstacles for Continuous Integration for autonomous vehicles? This study shows that there are a number of obstacles, sortable into levels, for CI: Continuous Integration for SW, Continuous Integration for Cyber-Physical Systems and CI for vehicles. The study shows that the obstacles accumulate for full system testing, and that although CI is viewed as positive for the individual coder, it creates a heavy burden for the testers, especially the full system testers. Even if much is unknown with regard to autonomous vehicles, the study points to the fact that what is experienced as difficulties or obstacles today, such as system complexity, will likely be aggravated.In the future focus should lie on improving both technical and organizational aspects of development processes, e.g. by defining comprehensive test analysis and plans, and what should be communicated, to whom, and how.
37
Persson, Staffan. "Introducing Continuous Integration in an Enterprise Scale Environment". Thesis, Uppsala University, Department of Information Technology, 2008. http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-88744.
Texto completoResumen
This thesis investigates how continuous integration best should be incorporated into a current development environment in order to acquire a shorter time for the regression testing feedback loop. The product in target is a high availability enterprise scale software product within mobile telecom. It utilizes a large commercial relational database for customer associated data and employs approximately one hundred designers.
A continuous integration system needs automatic database integration, compilation, testing, inspection, deployment, and feedback. Measures that are valuable to the build process regardless of build time should be given the highest priorities of implementation. Feedback has been developed in the form of Continuous Integration Web. The first priority at this stage is to introduce unit testing of the database which also has to be automatically built whenever updated or changed.
The amount of time used to integrate should be as close to ten minutes as possible. This goal is reachable if the build process is split into at least two integrations by differentiating unit tests from component tests and, if the software’s functionally divided parts are built separately on local integration servers.
Starting integrations automatically could potentially allow broken source code to reside in the source code repository. This problem can however be mitigated with the aid of good routines and sufficient communication between developers and the continuous integration server. If the latter is possible it is recommended to make use of a continuous integration server. Otherwise it is recommended to perform integrations manually.
38
Laurell, Thomas. "Microdialysis and continuous glucose monitoring towards wafer integration /". Lund : Lund Institute of Technology, Dept. of Electrical Measurements, 1995. http://catalog.hathitrust.org/api/volumes/oclc/37932770.html.
Texto completo
39
Tummala, Akhil. "Self-learning algorithms applied in Continuous Integration system". Thesis, Blekinge Tekniska Högskola, Institutionen för datalogi och datorsystemteknik, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-16675.
Texto completoResumen
Context: Continuous Integration (CI) is a software development practice where a developer integrates a code into the shared repository. And, then an automated system verifies the code and runs automated test cases to find integration error. For this research, Ericsson’s CI system is used. The tests that are performed in CI are regression tests. Based on the time scopes, the regression test suites are categorized into hourly and daily test suits. The hourly test is performed on all the commits made in a day, whereas the daily test is performed at night on the latest build that passed the hourly test. Here, the hourly and daily test suites are static, and the hourly test suite is a subset of the daily test suite. Since the daily test is performed at the end of the day, the results are obtained on the next day, which is delaying the feedback to the developers regarding the integration errors. To mitigate this problem, research is performed to find the possibility of creating a learning model and integrating into the CI system, which can then create a dynamic hourly test suite for faster feedback. Objectives: This research aims to find the suitable machine learning algorithm for CI system and investigate the feasibility of creating self-learning test machinery. This goal is achieved by examining the CI system and, finding out what type data is required for creating the learning model for prioritizing the test cases. Once the necessary data is obtained, then the selected algorithms are evaluated to find the suitable learning algorithm for creating self-learning test machinery. And then, the investigation is done whether the created learning model can be integrated into the CI workflow to create the self-learning test machinery. Methods: In this research, an experiment is conducted for evaluating the learning algorithms. For this experimentation, the data is provided by Ericsson AB, Gothenburg. The dataset consists of the daily test information and the test case results. The algorithms that are evaluated in this experiment are Naïve Bayes, Support vector machines, and Decision trees. This evaluation is done by performing leave-one-out cross-validation. And, the learning algorithm performance is calculated by using the prediction accuracy. After obtaining the accuracies, the algorithms are compared to find the suitable machine learning algorithm for CI system. Results: Based on the Experiment results it is found that support vector machines have outperformed Naïve Bayes and Decision tree algorithms in performance. But, due to the challenges present in the current CI system, the created learning model is not feasible to integrate into the CI. The primary challenge faced by the CI system is, mapping of test case failure to its respective commit is no possible (cannot find which commit made the test case to fail). This is because the daily test is performed on the latest build which is the combination of commits made in that day. Another challenge present is low data storage. Due to this low data storage, problems like the curse of dimensionality and class imbalance has occurred. Conclusions: By conducting this research, a suitable learning algorithm is identified for creating a self-learning machinery. And, also identified the challenges facing to integrate the model in CI. Based on the results obtained from the experiment, it is recognized that support vector machines have high prediction accuracy in test case result classification compared to Naïve Bayes and Decision trees.
40
Mattasantharam, R. (Rubini). "3D web visualization of continuous integration big data". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201812063239.
Texto completoResumen
Continuous Integration (CI) is a practice that is used to automate the software build and its test for every code integration to a shared repository. CI runs thousands of test scripts every day in a software organization. Every test produces data which can be test results logs such as errors, warnings, performance measurements and build metrics. This data volume tends to grow at unprecedented rates for the builds that are produced in the Continuous Integration (CI) system. The amount of the integrated test results data in CI grows over time. Visualizing and manipulating the real time and dynamic data is a challenge for the organizations.
The 2D visualization of big data has been actively in use in software industry. Though the 2D visualization has numerous advantages, this study is focused on the 3D representation of CI big data visualization and its advantage over 2D visualization. Interactivity with the data and system, and accessibility of the data anytime, anywhere are two important requirements for the system to be usable. Thus, the study focused in creating a 3D user interface to visualize CI system data in 3D web environment.
The three-dimensional user interface has been studied by many researchers who have successfully identified various advantages of 3D visualization along with various interaction techniques. Researchers have also described how the system is useful in real world 3D applications. But the usability of 3D user interface in visualizations in not yet reached to a desirable level especially in software industry due its complex data.
The purpose of this thesis is to explore the use of 3D data visualization that could help the CI system users of a beneficiary organization in interpreting and exploring CI system data. The study focuses on designing and creating a 3D user interface for providing a more effective and usable system for CI data exploration. Design science research framework is chosen as a suitable research method to conduct the study. This study identifies the advantages of applying 3D visualization to a software system data and then proceeds to explore how 3D visualization could help users in exploring the software data through visualization and its features. The results of the study reveal that the 3D visualization help the beneficiary organization to view and compare multiple datasets in a single screen space, and to see the holistic view of large datasets, as well as focused details of multiple datasets of various categories in a single screen space. Also, it can be said from the results that the 3D visualization help the beneficiary organization CI team to better represent big data in 3D than in 2D.
41
Sandberg, Martin. "Continuous Integration - A comparison between theory and practice". Thesis, Linköpings universitet, Institutionen för datavetenskap, 2015. http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-117033.
Texto completoResumen
To develop software in a larger scale, some kind of software development method is needed to organize the development. Many different software development methods have emerged since the beginning of software development, and Continuous Integration (CI) is one of them. Many companies have applied, or tried to apply CI in their business. Some companies were successful, some were not. This thesis examines what CI is in the theory, and compare it to how it works in the practice in the department ”Product Development Traffic Control” (PD TC) which is a part of the ”Product Development Unit LTE Multistandard Radio” (PDU LMR) within Ericsson. The theory of CI is examined mostly through literature studies. CI in practice was examined through interviews with developers and employees working with the CI-machinery at PD TC. The comparison between the theory and the studied company revealed that it is difficult to adapt CI perfectly to a large organization. This does not imply that CI is implemented in the wrong way, but the benefits of implementing CI in large projects may not be as enormous in comparison with smaller projects.
42
Heyd, Miriam. "Continuous production of rhamnolipids by means of process integration". [S.l. : s.n.], 2009. http://digbib.ubka.uni-karlsruhe.de/volltexte/1000010438.
Texto completo
43
Heikkilä, V. (Ville). "Optimizing continuous integration testing using dynamic source code analysis". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201802131229.
Texto completoResumen
The amount of different tools and methods available to perform software testing is massive. Exhaustive testing of a project can easily take days, weeks or even months. Therefore, it is generally advisable to prioritize and optimize the performed tests. The optimization method chosen to be studied in this thesis was Dynamic Source Code Analysis (DSCA). In DSCA a piece of target software is monitored during testing to find out what parts of the target code get executed. By finding and storing this information, further code changes can be triggered to execute the stored test cases that caused execution in the modified parts of code. The test setup for this project consisted of three open-source software targets, three fuzz testing test suites, and the DSCA software. Test runs of different lengths were triggered by code changes of varying size. The durations of these test runs and the sizes of the code changes were stored for further analysis. The purpose of this thesis was to create a method for the fuzz testing suite to reliably communicate with the DSCA software. This was done to find out how much time can be saved if CI-testing is optimized by scanning every source code change to obtain a targeted test set as opposed to running a comprehensive set of tests after each change. The data analysis demonstrates with certainty that using DSCA reduces the average run-time of a test by up to 50%Ohjelmistotestauksessa käytettävien työkalujen ja metodien määrä on massiivinen. Ohjelmistoprojektin läpikotainen testaus saattaa kestää päiviä, viikkoja tai jopa kuukausia. Tämän takia on yleisesti suositeltavaa priorisoida ja optimoida suoritetut testit. Tässä opinnäytetyössä tarkasteltavaksi optimointimetodiksi valittiin dynaaminen lähdekoodianalyysi (DSCA), jossa ohjelmistoa monitoroidaan ajonaikaisesti, jotta saadaan selville mitä osia lähdekoodista mikäkin testi suorittaa. Tämä projekti koostui kolmesta avoimen lähdekoodin ohjelmistoprojektista, kolmesta fuzz-testaustyökalusta sekä DSCA-ohjelmistosta. Erikokoisilla lähdekoodin muutoksilla saatiin aikaan erikokoisia testimääriä uudelleenajettaviksi. Näiden ajojen suuruudet ja kestot tallennetiin, ja niitä vertailtiin. Tämän opinnäytetyön tarkoituksena oli löytää keino saada fuzz-testaustyökalu keskustelemaan DSCA-ohjelmiston kanssa luotettavasti, sekä selvittää kuinka paljon aikaa pystytään säästämään optimoimalla CI-testausta skannaamalla jokainen lähdekoodimuutos kohdennettujen testien saamiseksi verrattuna siihen että jokainen lähdekoodimuutos aiheuttaisi kokonaisvaltaisen testiajon. DSCA-ohjelmistoja käyttämällä saatiin varmuus siitä, että CI-järjestelmien testiajojen pituutta pystytään pienentämään huomattavasti. Keskimääräisen testiajon pituus pystyttiin testeissä jopa puolittamaan
44
Lindblom, William y Jesper Johnsson. "The Effects of Parallelizing Builds in Continuous Integration Software". Thesis, Blekinge Tekniska Högskola, Institutionen för programvaruteknik, 2018. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-16438.
Texto completoResumen
Quick feedback in regards to build times is important in Continuous Integration. If builds become too long, it can hurt the rate of software development. There are multiple methods to reduce build times. One commonly suggested method is to parallelize builds. This thesis aims to investigate the effects of parallelizing builds in Continuous Integration software and provide support for whether parallelizing is a good way of reducing build times or not. We conducted an experiment consisting of running tests on different Continuous Integration software with different configurations. These configurations changed how many tests were executed and how many parallel build agents were used. The aspects that were observed and analyzed was how build time, average CPU usage and CPU time were affected. What we found was that parallelizing a Continuous Integration build drastically improves build time, while RAM usage and CPU time remains similar. This entails that there are no major consequences to parallelizing other than utilizing more threads and therefore using more of the available CPU resources.
45
Wilén, J. (Juhani). "Code change based selective testing in continuous integration environment". Master's thesis, University of Oulu, 2018. http://urn.fi/URN:NBN:fi:oulu-201806062460.
Texto completoResumen
Continuous integration (CI) is a software engineering practice in which new code is integrated to existing codebase continuously. Integration testing ensures that the changes in code function as intended together with the other parts of the code. The number of tests tend to grow and at some point performing them all becomes infeasible due to limited time between consecutive test executions. Therefore, the traditional retest-all approach becomes inoperative and test optimization techniques are required. Test selection is one of those techniques and it encompasses selecting tests which are relevant to recent changes in the code. The purpose of this thesis is to analyze existing test selection methods, and to implement an initial continuous test selection method in CI environment that reduces duration of integration testing stage and provides faster feedback. The method is aimed to be safe that no additional faults are let through the testing. The test selection is based on changes submitted to version control system (VCS), which are compared with source code file coverages of different hardware variants reported by compilers. In addition, other possible dependencies between variants and code changes are investigated. Those are related to test codes and interfaces. Now the testing of change independent variants can be ignored, and only testing change dependent variants is conducted. At the beginning the implemented test selection method was used in a single software development branch for testing purposes. The results indicate that utilizing the method accomplished slight but statistically significant reduction of integration testing duration with significance level of 0.05. The mean of the testing duration was decreased by 15.2% and the median by 22.2%. However, the implementation still has some inaccuracies in dependency detection, and further improvements are needed to make the test selection method more efficientJatkuva integraatio on ohjelmistotuotannon käytäntö, jossa muutokset ohjelmakoodiin integroidaan osaksi jo olemassa olevaa ohjelmistoa jatkuvasti. Integraatiotestauksella varmistetaan, että muutokset koodiin toimivat sen muiden osien kanssa kuten on tarkoitettu. Suoritettavien testien määrä usein kasvaa ajan mittaan, ja jossakin vaiheessa niiden kaikkien suorittaminen ei ole enää järkevää, koska perättäisten testiajojen välinen aika on rajallinen. Siksi perinteinen kaikkien testien uudelleenajaminen tulee haastavaksi ja tarvitaan testien optimointitekniikoita. Testien valinta on yksi näistä tekniikoista. Se sisältää sellaisten testien valinnan, jotka ovat oleellisia testaamaan viimeaikaisia muutoksia koodiin. Tämän diplomityön tarkoituksena on analysoida olemassa olevia testien valintamenetelmiä ja luoda alustava toteutus jatkuvasta testien valintamenetelmästä jatkuvan integraation ympäristössä, millä vähennetään testien kestoaikaa integraatiotestausvaiheessa ja nopeutetaan palautteen saamista. Tavoitteena on, ettei testauksen läpäisseiden vikojen määrä kuitenkaan kasva. Testien valinta perustuu versionhallintajärjestelmään toimitettuihin muutoksiin, joita verrataan kääntäjien raportoimiin lähdekoodikattavuuksiin eri laiteversioille. Lisäksi laiteversioiden riippuvuus testikoodien ja rajapintojen muutoksiin tutkitaan. Ne laiteversiot, jotka eivät ole riippuvaisia mistään muutoksista, jätetään testaamatta, ja ainoastaan muutoksista riippuvaisten laiteversioiden ohjelmakoodit testataan. Testien valintaan toteutettu menetelmä otettiin käyttöön aluksi yhdessä ohjelmistokehityshaarassa sen toiminnan testaamiseksi. Saadut tulokset näyttävät, että menetelmän hyödyntämisellä saavutettiin vähäinen mutta tilastollisesti merkittävä integraatiotestauksen kestoajan lyheneminen merkitsevyystasolla 0,05. Testauksen keston keskiarvo laski 15,2 % ja mediaani 22,2 %. Toteutuksessa on vielä epätarkkuuksia riippuvuuksien havaitsemisessa, ja sitä pitää kehittää paremman tehokkuuden saavuttamiseksi
46
Hramyka, Alena y Martin Winqvist. "Traceability in continuous integration pipelines using the Eiffel protocol". Thesis, Malmö universitet, Fakulteten för teknik och samhälle (TS), 2019. http://urn.kb.se/resolve?urn=urn:nbn:se:mau:diva-20634.
Texto completoResumen
The current migration of companies towards continuous integration and delivery as well all service-oriented business models brings great benefits but also challenges. One challenge that a company striving to establish continuous practices is the need for pipeline traceability, which can bring great enhancements to continuous integration and delivery pipelines as well as offer a competitive edge. This exploratory case study looks at the current and desired states at Axis Communications, a global leader in network video solutions based in Lund, Sweden. It further evaluates the practical and organizational aspects of the adoption of the Eiffel protocol in the company’s pipeline tools through developing a proof-of-concept Eiffel plugin for Artifactory. Based on the discovered technical and organizational needs and obstacles, it draws conclusions and makes recommendations on a possible strategy when introducing Eiffel in a company.
47
Bhattacharya, Arka. "Impact of Continuous Integration on Software Quality and Productivity". The Ohio State University, 2014. http://rave.ohiolink.edu/etdc/view?acc_num=osu1410945557.
Texto completo
48
Leitao, Joao. "Continuous states conditional random fields training using adaptive integration". Thesis, University of Exeter, 2010. http://hdl.handle.net/10036/3095.
Texto completoResumen
The extension of Conditional Random Fields (CRF) from discrete states to continuous states will help remove the limitation of the number of states and allow new applications for CRF. In this work, our attempts to obtain a correct procedure to train continuous state conditional random fields through maximum likelihood are presented. By deducing the equations governing the extension of the CRF to continuous states it was possible to merge with the Particle Filter (PF) concept to obtain a formulation governing the training of continuous states CRFs by using particle filters. The results obtained indicated that this process is unsuitable because of the low convergence of the PF integration rate in the needed integrations replacing the summation in CRFs. So a change in concept to an adaptive integration scheme was made. Based on an extension of the Binary Space Partition (BSP) algorithm an adaptive integration process was devised with the aim of producing a more precise integration while retaining a less costly function evaluation than PF. This allowed us to train continuous states conditional random fields with some success. To verify the possibility of increasing the dimension of the states as a vector of continuous states a scalable version was also used to briefly assess its fitness in two-dimensions with quadtrees. This is an asymmetric two-dimensional space partition scheme. In order to increase the knowledge of the problem it would be interesting to have further information of the relevant features. A feature selection embedded method was used based on the lasso regulariser with the intention of pinpointing the most relevant feature functions indicating the relevant features.
49
Nečas, Radek. "Systém pro kontinuální integraci projektu k-Wave". Master's thesis, Vysoké učení technické v Brně. Fakulta informačních technologií, 2016. http://www.nusl.cz/ntk/nusl-255473.
Texto completoResumen
The main goal of this thesis is to describe the implementation of continuous integration into the k-Wave project. The thesis focuses primarily on the version written in the C/C++ language with the usage of the OpenMP library which typically runs on supercomputers. Accordingly, many of popular workflows and approaches ought to be adapted, a few more created. The outcome of the thesis is a complete solution with real and practical usage. The author provides design, tools selection, runtime environment administration and configuration for each one of the used services. Software implementation of the basic framework is used in order to utilize running tests on the supercomputers. Furthermore, the implementation of chosen types of regression and unit tests are performed. Realisation is based on Gitlab and Jenkis services that are running on separated Docker containers.
50
Hämäläinen, Thomas y Hillevi Strömberg. "Vägen till kontinuerliga leveranser : En fallstudie om continuous delivery och DevOps i en offentlig organisation". Thesis, Umeå universitet, Institutionen för informatik, 2016. http://urn.kb.se/resolve?urn=urn:nbn:se:umu:diva-120739.
Texto completoResumen
Information system development projecs are often considered a costly and uncertain process were projects often exceed the scheduled time and budget. By continuously integrating source code and do regular builds problems can be discovered almost directly and thus minimizing the cost to fix them. In this qualitative study we have focused on which challenges a large public organization who cooperate with an external provider can face when adopting continuous integration and continuous delivery. We have interviewed six employees within the organisation and two employees from the external provider, who are all in some way connected to the software development process. The results showed that our interviewees are interested in agile software development and to be able to deliver high quality software continuously. We also found that the software development process is complex and has a lot of barriers and handovers that slows the process down. Our conclusion is that the organization needs to change their approach to software development. To achieve this the organisation needs to adopt Devops, which means erasing the barriers between development and operations.