Táto práca je prípadovou štúdiou postupného vývoja a nasadzovania lokačného softwaru v reálnom čase. Cieľom tejto práce je zrýchliť tento proces. Zvolený problém bol vyriešený s konvenčnými testovacími nastrojmi, vlastným nástrojom pre generovanie sieťovej prevádzky lokalizačnej platformy a nástrojmi CI/CD Gitlab. Prínosom tejto práce je zrýchlenie vývoja, zaručenie kvality vyvijaného softwaru a predstavenie spôsobu ako platformu pre lokalizáciu v reálnom čase testovať.

DevOps and continuous practices are increasingly popular development practices aiming at bridging the gap between software development and IT operations with the indented outcome of shorter development life cycles while maintaining a high software quality. A fundamental part of many DevOps systems is a CI/CD (continuous integration/deployment) pipeline allowing for automatic building, testing and deployment of software. The use of continuous practices have been shown to achieve the desired outcomes, whereas the adopting of such practices has been attributed with the challenges of lacking expertise and skill as well as lacking available tools and technology. Execution of commands in a CI/CD pipeline are handled by a runner application, which can be configured in different ways allowing for different levels of the quality attributes performance, response time, throughput, robustness, stability, resource constraints, cost and maintainability. Five different types of runner infrastructure were implemented and evaluated on the quality attributes. These were: one single-machine implementation, one serverless implementation and three autoscaling implementations. For robustness and stability autoscaling implementations achieved the best results. Performance and throughput were affected by resource constraints which in turn affected the cost. Similar results were found for response time for all but one of the three autoscaling implementations, and for the serverless implementation. Finally, all implementations had similar results for reliability.

The focus of this study is on examining when employees in the IT industry experience that it is more favorable to use automated tests and manual tests, respectively. The purpose of this study is to investigate how different companies in practice, use, work with and think about the two different test methods. Four factors that influence the choice of test method have been developed as a workframe based on five articles, all of which discuss the requirements and criteria for the two different test methods. By conducting an interview study with semi-structured interviews, data has been retrieved from two different companies. The data has in turn been analyzed based on the four factors that have been developed, namely: the number of test cases/test runs, technical aspects, what functions that are to be tested and resources. Based on the analyzes, it has been clear that the opinions from the different respondents and from previous research often remain on the same track. Thus, the various criteria could be discussed and the motivation for when the respondents use each method could be outlined. However, it also becomes clear that in the end it is mainly resources, often the number of working hours and the monetary cost, that determines what practice of testing is to be used. / Denna studie riktar in sig på att undersöka när anställda inom IT-branschen upplever att det är mer gynnsamt att använda sig av automatiserade tester respektive manuella tester. Syftet med studien är att undersöka hur olika företag använder sig, arbetar med och ser på de två olika testmetoderna i praktiken. Fyra stycken faktorer som påverkar valet av testmetod har tagits fram som ramverk som är baserad på fem artiklar där samtliga diskuterar krav och kriterier för de två olika testmetoderna. Genom att utföra en intervjustudie med semi-strukturerade intervjuer har data samlats in från två olika företag. Den insamlade datan har i sin tur analyserats utifrån de olika faktorerna som tagits fram nämligen: Antalet testfall/testkörningar, tekniska aspekter, funktioner som ska testas samt resurser. Utifrån analysen har det varit tydligt att åsikterna från de olika respondenterna samt från tidigare forskning ofta är på samma spår. Därmed har de olika kriterierna kunnat diskuterats och motiveringarna till när respondenterna använder sig av respektive metod kunnat benas ut. Dock blir det också tydligt att i slutändan är det resurser, oftast antalet arbetstimmar och den monetära kostnaden, som styr vad som borde väljas.

The goal of this thesis is to explore the possibility on if it is possible to automate regression testing for a SaaS application with a serverless approach. The thesis covers the fundamentals of the software development lifecycle, cloud concepts, different types of testing frameworks, and SaaS applications. The report researches various testing tools that can be used in accordance with Polestar’s needs. The testing framework must run the existing tests and deliver the results of the tests. The system must be able to coexist with the testing strategy that is in place today. The result is a testing framework that can run a number of selected tests on the SaaS application Salesforce. The system was deployed with serverless docker containers through Amazon Web Services. The report also covers what a future implementation can look like and potential improvements. / Målet med denna avhandling är att undersöka om det går att automatisera regression testning för en SaaS-applikation med hjälp av ett serverlöst tillvägagångsätt. Avhandlingen täcker grunderna inom molnkoncept, mjukvaruutveckling, olika typer av testramverk och SaaS-applikationer. Avhandlingen går även igenom gamla arbeten som har gjorts inom området. Rapporten behandlar val av verktyg med åtanke på vad företaget Polestar har för    behov. Testramverket ska kunna utföra automatiska regressionstester på SaaS-applikationen Salesforce. Resultatet är ett testramverk som kan köra ett antal utvalda tester på Salesforce. Systemet driftsattes med hjälp av serverlösa Docker containrar på Amazon Web Services. Avhandlingen täcker även alternativa verktyg som kan användas för testautomation och även potentiella förbättringsmöjligheter.

This thesis applies energy measurements to the domain of continuous integration (CI) and continuous delivery (CD) pipelines. The goal is to conduct transparent and fine-granular energy measurements of these pipelines, increasing awareness and allowing optimizations regarding their energy efficiency. CI and CD automate processes like compilation, running tests, and code analysis tools and can improve the software quality and developer experience and enable more frequent releases. Initially, the applicability of existing energy measurement approaches for these tasks is analyzed. Afterward, a generic framework consisting of a pipeline run analyzer, a resource consumption collector, and an energy calculator is proposed. A representative implementation for a state-of-the-art infrastructure is devised to demonstrate its functionality, enabling the collection, analysis, and interpretation of data from real-world examples. Finally, it is examined whether this data aligns with the theoretical considerations and can be used to optimize the pipelines. The overall goal is to contribute to the sustainability of DevOps processes and therefore counteract the disastrous consequences of unrestrained climate change. / Denna avhandling tillämpar energimätningar på området kontinuerlig integration (CI) och kontinuerlig leverans (CD). Målet är att genomföra transparenta och finkorniga energimätningar av dessa pipelines, vilket ökar medvetenheten och möjliggör optimeringar av deras energieffektivitet. CI och CD automatiserar processer som kompilering, testkörning och kodanalysverktyg och kan förbättra programvarukvaliteten och utvecklarens upplevelse samt möjliggöra tätare lanseringar. Inledningsvis analyseras tillämpligheten av befintliga metoder för energimätning för dessa uppgifter. Därefter föreslås ett generiskt ramverk som består av en analysator för pipelinekörning, en insamlare av resursförbrukning och en energikalkylator. För att demonstrera dess funktionalitet utarbetas en representativ implementering för en modern infrastruktur som möjliggör insamling, analys och tolkning av data från verkliga exempel. Slutligen undersöks om dessa uppgifter stämmer överens med de teoretiska övervägandena och kan användas för att optimera rörledningarna. Det övergripande målet är att bidra till hållbarheten i DevOpsprocesser och därmed motverka de katastrofala konsekvenserna av ohämmade klimatförändringar.

DevOps is a cultural idea rather than a firm way to do software development, with the aim of reducing software lead times by bringing operations and development closer via principles that mainly deal with automation. This paper provides a potential DevOps solution for Wexnet, an internet service provider company. A requirements list is created by interviewing which is then used to evaluate existing web-based git solutions. Two viable candidates were selected, GitHub and GitLab which were compared against each other. GitLab was chosen because of its comparably low resource usage and lower overall setup complexity.

This paper examines how adding security tools to a software pipeline affect the build time. Software development is an ever-changing field in a world where computers are trusted with almost everything society does. Meanwhile keeping build time low is crucial, and some aspects of quality assurance have therefore been left on the cutting room floor, security being one of the most vital and time-consuming. The time taken to scan for vulnerabilities has been suggested as a reason for the absence of security tests. By implementing nine different security tools into a generic DevOps pipeline, this paper aimed to examine the build times quantitatively.              The tools were selected using the OWASP Top Ten, coupled with an ISO standard, as a guideline. OWASP Juice Shop was used as the testing environment, and the scans managed to find most of the vulnerabilities in the Vulnerable Web Application. The pipeline was set up in Microsoft Azure and was configured in .yaml files. The resulting scan durations show that adding security measures to a build pipeline can add as little as 1/3 of the original build time.

Both distributed work and DevOps are on an upward trend. There is a slight resemblance between the problems that DevOps is trying to find answers to, the solutions, and the common problems that geographically distributed work faces. Mainly, they are related to isolated environments that have difficulties in mutual understanding and communication, collaboration. All this leads to inefficiencies and costs that affect the overall efficiency of companies. This report identifies how DevOps engineering principles and implementations provide solutions to common problems in globally distributed work environments. It uses a literature systematic literature search and review to extract the recent and relevant academic data in the scope of the two research questions. Then, a proof-of-concept is implemented for DevOps, which confirms the literature. In parallel, a survey addressed to Swedish companies provides subject-related data from the professional environment, which largely supports the literature and brings extra knowledge. All of this is considered in data analysis and formulation of conclusions, showing DevOps features that can improve and support work in globally distributed environments and outlining the importance of the tailored organizational culture for the modern need of large-scale distributed work.

Continuous integration and delivery (CI/CD) frameworks are a core element of DevOps-based software development. A PHP-based case study assessed the suitability of five such frameworks - -JFrog Arti-factory, Bitbucket Pipelines, Jenkins, Azure DevOps, and TeamCity - -for instructional use. The five were found to be roughly equivalent in terms of their usability for simple configurations. The effort needed to implement CI/CD substantially increased for more realistic production scenarios, like deployments to cloud and load-balanced platforms. These results suggest a need to limit CI/CD-based academic projects to simple infrastructure and technology stacks: e.g., a web application on a single instance web server.

Background : Embedded system consists of both hardware and software. Boththese hardware and software development teams must be worked together to complete the project successfully, which requires a lot of communication among theteams. DevOps is an evolution of agile development that bridges communicationgap between teams. Since Embedded systems are not service-based, it isn’t easy toimplement DevOps. So there is a need to study what challenges are currently facedin implementing embedded application development. Objectives: The focus of this thesis was to gather the challenges and mitigationstrategies to overcome these challenges faced during the implementation of DevOpsin Embedded application development, along with mitigation strategies followed toovercome these challenges. Methods: In this thesis, surveys, and interviews were selected as research methods to identify challenges faced while implementing DevOps in embedded systemapplication development and mitigation strategies, and the survey was considered tocollect demographic questions. Results: A survey was conducted to identify embedded developers with experienceimplementing DevOps for Embedded Application Development. Out of 19 surveyresponses, 12 respondents were further interviewed for detailed information. Datacollected from the interviews are analyzed using thematic analysis and narrativeanalysis. Conclusions: From the analysis, the research concludes that continuous testingis the most challenging phase to implement. Continuous testing and continuous integration are the phases that need to be focused on more for the future implementationof DevOps