• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 72
  • 13
  • 7
  • 1
  • 1
  • Tagged with
  • 96
  • 96
  • 39
  • 33
  • 32
  • 30
  • 24
  • 22
  • 22
  • 21
  • 19
  • 17
  • 16
  • 15
  • 14
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
1

Vägen till kontinuerliga leveranser : En fallstudie om continuous delivery och DevOps i en offentlig organisation

Hämäläinen, Thomas, Strömberg, Hillevi January 2016 (has links)
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.
2

Using containers in a continuous integration and delivery environment : A performance and scalability comparison

Olle, Emilsson, Marcus, Hrvatin January 2018 (has links)
With a software industry that is moving at a fast pace, continuous integration and delivery is something important for many products today. Moreover, with containers being on the rise since 2013, more companies are moving their CI/CD environment into containers not only for development but also for testing. This thesis begins with giving the reader an introduction to containers, container orchestration, and Jenkins, which is a continuous integration and delivery tool. The experiment was then set up with one container based cluster and one single node machine. Two kinds of experiments were run on them, one big job and one small job. The system scalability is assessed, and with smaller clusters the memory overhead could be an issue. Performance wise, the container cluster is performing better than a single node machine, as long as it is utilizing all its nodes. Security with containers is still an issue and it could be fatal for a cluster if it is compromised.
3

Design requirements to improve adoption of continuous development services

Rae, Trevor 21 May 2020 (has links)
The adoption of Continuous Development presents many challenges to users and organizations. The complexity of Continuous Development adoption is partially attributable to the diversity of the challenges faced, including technical challenges, cultural challenges, compliance regulations, and lack of understanding. In this thesis, I worked with industry partner IBM to improve their Continuous Delivery Pipeline offering to overcome adoption challenges faced by their users. Following Hevner’s Three Cycle Design Science Methodology, my research had two distinct stages: Characterizing Continuous Development Adoption Challenges and Creating Design Requirements to Aid Organizations Offering Continuous Development Services. Both stages necessitated involvement from both academic literature and industry collaboration with IBM. Industry collaboration included interviews, surveys, developer forum analysis, and collaboration with IBM’s “Continuous Delivery” teams. The design requirements I developed in this thesis addressed cultural, technical, compliance, and knowledge gap adoption challenges that were identified during the problem characterization stage. When tested within the Continuous Development community, feedback indicated that my design requirements would add value to users’ development process, enabling their Continuous Development adoption. This thesis provides a foundation of empirical research for future study and a set of guidelines for industry practitioners. / Graduate
4

Cost-saving in Continuous Integration: Development, Improvement, and Evaluation of Build Selection Approaches

Jin, Xianhao 24 May 2022 (has links)
Continuous integration (CI) is a widely used practice in modern software engineering. Unfortunately, it is also an expensive practice — Google and Mozilla estimate their CI systems in millions of dollars. In this dissertation, I propose a collection of novel build selection approaches that are able to save the cost of CI. I also propose the first exhaustive comparison of techniques to improve CI including build and test granularity approaches. I firstly design a build selection approach (SMARTBUILDSKIP) for CI cost reduction in a balanceable way. The evaluation of SMARTBUILDSKIP shows that it can save a median of 30% of builds by only incurring a median delay of 1 build in a median of 15% of failing builds under its most conservative configuration. To minimize the delayed failure observation, I then propose the second build selection approach (PRECISEBUILDSKIP) that can save cost without delaying failure observation. We find that PRECISEBUILDSKIP can save a median of 5.5% of builds while capturing the majority of failing builds (100% in median) from the evaluation. After that, I evaluate the strengths and weaknesses of 10 techniques that can improve CI including SMARTBUILDSKIP. The findings of the comparison motivate my next work to design a hybrid technique (HYBRIDBUILDSKIP) that combines these techniques to produce more cost-saving while keeping a low proportion of failing builds that are delayed in observation. Finally, I design an experiment to understand how different weights of test duration among the whole build duration can influence the cost-saving of build and test selection techniques. / Doctor of Philosophy / Modern software developing teams commonly use the continuous integration as the practice of automating and testing the integration of code changes from multiple contributors into a single software project. The best practice of continuous integration requires this process happens as frequently as possible because the bugs can be found earlier and easier before the change sets grow too large. However, continuous integration process can be time-consuming and in most cases the code change is bug-free. This means that developers may have to wait for a long time only to get a result with no actionable feedback. Thus, in this dissertation, I present multiple selection approaches to selectively execute the continuous integration process based on the prediction of the outcome - if the outcome is predicted to be passing with no actionable feedback, the approach will decide to skip the current execution. The evaluation result shows that my approaches can save the cost of continuous integration while keeping the value of it (finding bugs earlier).
5

The Effects of Parallelizing Builds in Continuous Integration Software

Lindblom, William, Johnsson, Jesper January 2018 (has links)
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.
6

Impact of Continuous Integration on Software Quality and Productivity

Bhattacharya, Arka January 2014 (has links)
No description available.
7

Automatiserad testning av användargränssnitt i SharePoint : Automated UI Testing in SharePoint

Borg, Daniel, Elfström, Anders January 2014 (has links)
Företag arbetar ofta efter hårda krav från kunder där lösningar måste levereras på ett tidseffektivt sätt och samtidigt hålla en hög kvalitet. Detta i form av felfria och robusta system vilket delvis kan åstadkommas med hjälp av testning. Kraven på snabb leverans och hög kvalitet är däremot motpoler till varandra; snabb leverans genomförs ofta på bekostnad av kvalitet och tvärtom. Agila arbetsmetoder med tidiga och frekventa leveranser har ändrat på detta, men kräver samtidigt en ständig kvalitetsförsäkring under arbetets löptid. Under utveckling av mjukvara enligt dessa metoder förekommer därför en kontinuerlig kvalitetssäkringsprocess för att säkerställa att produkten dels uppfyller vad kravspecifikationen avser samt att levererad produkt håller en hög tekniskt kvalitet i form av buggfri och robust kod som innehar stor pålitlighet för framtiden. Då manuell testning är en kostnad- och resurskrävande metod har automatiserad testning blivit ett aktuellt alternativ för ökad effektivitet och hållbar utveckling. Målet med det här arbetet har varit att för Precio Systemutveckling AB utreda möjligheterna för en implementation av automatiserad testning av användargränssnitt, i en hos företaget redan existerande och etablerad utvecklingsprocess. Arbetet har genomförts med en inledande förstudie om testning med fokus på varför det är en extra viktig faktor i dagsläget. Detta följs av ett avsnitt där existerande teori och teknik för testning i generell mening avhandlats, följt av en närmare studie på hur automatiserad testning är rekommenderad att utföras ur ett perspektiv från utveckling av produkter inom Microsoft-teknologi. / Software companies work under a strict pressure from customers where solutions must be delivered in a timely manner as well as providing high quality and value. The products should be robust and without errors, which partially can be accomplished by testing during the development process. The requirement for an early delivery and a high quality does not always come hand in hand, but with the increased use of agile software development methods, this can be achieved. During agile development of software, there is a continuous process to ensure the quality of what is being developed, both to make sure that all the functional requirements are fulfilled, but also that the code behind is robust and dependable for the future. Since manual testing can be both time and resource consuming, automated testing has become a modern alternative to increase productivity and to maintain a sustainable development process. The goal of this thesis work has been to investigate the possibilities of implementing a solution for automated UI testing in an already existing development process at the company Precio Systemutveckling AB. The work has been conducted in three steps, starting with a literature study about testing in general, followed by an extensive research into suitable tools and technology for testing that exists today. After this, a deeper look was made at what the recommended solutions for implementing automated testing in a Microsoft-oriented enviroment were. The work was concluded with an actual implementation of automated testing on premise at Precio.
8

The Challenges of adopting DevOps / Utmaningar när man tar sig an DevOps

Lindström, Gustav January 2019 (has links)
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.
9

Microservice Migration Patterns and how Continuous Integration and Continuous Delivery are affected : A Case study of Indicio’s journey towards microservice

Liu, Kasper January 2021 (has links)
Microservice is an architectural design that promises a more elastic system where a microservice can be allocated compute power according to demand. Through the separation of components, each microservice can have its own hardware or cloud setup. As a result, the code becomes more maintainable through smaller repositories. Development and Operations (DevOps) is a set of best practices to improve software development and operations. Two important components of DevOps are Continuous Integration (CI) and Continuous Delivery (CD). CI is a set of practices that aims to automate testing and increase development velocity through continuously integrate code changes. While CD aims to streamline the deployment process of the code, enabling a shorter time to market. When migrating a monolithic codebase towards a microservice architecture, one faces a lot of decisions that can have a deep impact on the whole organization. From a CI/CD perspective, some decisions can impact the efficiency of the CI/CD pipeline. This thesis investigated how Indicio’s CI/CD pipeline changed when going from a monolith towards a microservice architecture. It documents the decisions Indicio made along the way and investigates how the CI buildtime and CD deploy time were affected. The result showed that Indicio’s decision to keep the new microservice in the same repository added 44% to the median buildtime. The time increase was acceptable since it only resulted in an average of 20 seconds increase in median buildtime. Although, the decision to separate the CD into two independent CD pipelines, one for the old monolith and one for the new microservice didn’t affect the deploy time by any considerate margin. The new microservice was deployed to Microsoft Azure to be able to take advantage of the elastic compute power. The big advantage from a CD perspective by utilizing Azure was the blue-green deployment method resulting in zero downtime. / Mikrotjänster är en arkitektdesign som lovar ett mer flexibelt system där en mikrotjänst kan tilldelas den nödvändiga datakraften. Genom att dela upp komponenter kan varje mikrotjänst ha sin egen hårdvara eller molninställning. Det resulterar i mindre stycken kod som är lättare att underhålla. Development and Operations (DevOps) är en samling av bästa praxis för att förbättra mjukvaruutveckling och operationer. Två viktiga komponenter av DevOps är Continuous Integration (CI) och Continuous Delivery (CD). CI är en samling av verktyg som försöker automatisera tester och öka utvecklingshastigheten genom att kontinuerligt integrera kodändringar. Medan syftet med CD är att effektivisera distribution av kod, vilket möjliggör en kortare tid till marknaden. När man migrerar en monolitiskt kodbas mot en mikrotjänst arkitektur står man inför flera val som kan påverka hela organisationen. Utifrån ett CI/CD perspektiv så kan dessa val påverka effektiviteten av CI/CD processen. Denna uppsats undersöker hur Indicios CI/CD process förändras när dem går mot en mikrotjänstarkitektur från en monolit. Uppsatsen dokumenterar de val Indicio har gjort under migrationen och hur det påverkar CI byggnadstid och CD distribution tid. Resultaten visar att Indicios beslut att behålla den nya mikrotjänsten i samma förvar resulterade i 44% ökad medianbyggtid. Tidsökningen var acceptabel då det endast innebar en snittökning på 20 sekunder. Fastän Indicio beslutade att separera på CD processen till två nya, en för den nya mikrotjänsten och en för den nya monoliten så påverkades inte distribueringstiden särskilt mycket. Den nya mikrotjänsten distribuerades på Microsoft Azure för att kunna utnyttja den elastiska datakraften. Den stora fördelen från ett CD perspektiv med Azure var att man kunde utnyttja blågrön distributionsmetod, vilket gjorde att driftstopp tiden försvann.
10

CI/CD Pipeline from Android to Embedded Devices with end-to-end testing based on Containers

Bernhardt, Arne Jasper January 2021 (has links)
Embedded devices in the Internet of Things world mostly only have one connection channel, and smaller consumer devices usually communicate with other devices only over a wireless connection. Developers constantly upgrade the Internet of Things devices with Android phones connecting to the devices. If developers break the only possible connection, the devices become unusable, because the devices do not have a wired port. This study explores the options to test the wireless upgrade channel during the development workflow and implements a continuous integration pipeline for the devices. Literature in the field of continuous integration focuses primarily on Cloud and Web-related workloads. The few papers targeting embedded devices with continuous integration are primarily theoretical and discuss the possible advantages of utilizing continuous integration but do not implement a prototype. Our contribution creates a continuous integration pipeline for embedded devices, which automatically tests the update channel between Android phones and embedded devices over Bluetooth on every commit. To verify the correct functionality, we use previously faulty commits from the git history and run the pipeline with the buggy commit to check the pipeline’s functionality. The pipeline evaluation shows that the time improvements for our update validation process with continuous integration is insignificantly faster for the upgrade procedure. However, developers are required to test a combination of versions and here, the automated testing setup excels over the human testing method by being scalable. Furthermore, automated testing enables easier identification of the root cause for an issue and a faster delivery time of fixes. While the pipeline works reliably, we identify issues in adopting the continuous integration process by the developers. Additionally, the analysis summarizes essential tools and features to run the pipeline with an overview of required elements for similar projects. The work was created in cooperation with Wrlds Creations AB and we used the devices actively developed by the company. / Inbäddade enheter i Internet of Things världen har oftast bara en kommunikationskanal, och mindre konsumentenheter kommunicerar vanligtvis via en trådlös Bluetooth-anslutning. Utvecklarna uppgraderar ständigt enheterna med Android-telefoner som ansluts till enheterna. Om utvecklarna bryter den enda möjliga kommunikationskanalen blir enheterna obrukbara. Denna studien undersöks alternativen för att testa den trådlösa uppgraderingskanalen under utvecklingsarbetsflödet och implementeras en continuous integration pipeline för enheterna. Litteraturen inom området continuous integration fokuserar primärt på Cloud och webbrelaterade arbetsbelastningar. De få artiklar som är inriktade på inbäddade enheter med continuous integration är främst teoretiska och diskuterar de möjliga fördelarna med att använda continuous integration, men implementerar inte någon prototyp. Vårt bidrag skapar en continuous integration pipeline för inbäddade enheter, som automatiskt testar uppdateringskanalen mellan Android-telefoner och inbäddade enheter via Bluetooth vid varje commit. För att verifiera den korrekta funktionaliteten använder vi tidigare felaktiga commits från git-historiken och körde pipelinen med den felaktiga commit för att kontrollera funktionaliteten av pipelinen. Utvärderingen av pipelinen visar att tidsförbättringarna för valideringskanalen är obetydligt snabbare för hela uppgraderingsproceduren. Utvecklarna krävs dock testa en kombination av versioner och här är den automatiska testuppställningen bättre än den mänskliga testmetoden eftersom den är skalbar. Automatiserad testning gör det dessutom lättare att identifiera grundorsaken till ett problem och att leverera korrigeringar snabbare. Även om pipelinen fungerar på ett tillförlitligt sätt identifierar vi problem när det gäller utvecklarnas antagande av continuous integration-processen. Dessutom sammanfattas i analysen de viktigaste verktygen och funktionerna för att driva pipelinen med en översikt över vad som krävs för liknande projekt. Arbetet skapades i samarbete med Wrlds Creations AB och använde de enheter som företaget aktivt utvecklat.

Page generated in 0.5096 seconds