<p>Utveckling av olika typer av påbyggnadskod till programvaror blir allt vanligare. Dessa som går under samlingsnamnet plugins skiljer sig från vanliga applikationer då de har en annan struktur samt speciella beroenden till applikationsspecifika moduler. Problem uppstår när denna typ av utveckling inte stöds av de vanliga utvecklingsmiljöer som finns ute på företagen och delar som borde vara automatiserade måste utföras manuellt. Syftet med studien är att undersöka hur utvecklingsmiljön för Java på Sandvik IT Services kan anpassas för att stödja plugin-utveckling för IBM Lotus Notes. I denna studie undersöks skillnaden mellan plugin-utveckling och den vanliga Java-utvecklingen på företaget samt hur detta påverkar verktygen i utvecklingsmiljön. Resultatet beskriver hur utvecklingsmiljön kan anpassas för att stödja plugin-utveckling och en lösning för detta föreslås. Slutligen visas en implementation av lösningen i form av en prototyp där utvecklingsmiljön anpassas för plugins med Maven pluginet Tycho.</p>

Utveckling av olika typer av påbyggnadskod till programvaror blir allt vanligare. Dessa som går under samlingsnamnet plugins skiljer sig från vanliga applikationer då de har en annan struktur samt speciella beroenden till applikationsspecifika moduler. Problem uppstår när denna typ av utveckling inte stöds av de vanliga utvecklingsmiljöer som finns ute på företagen och delar som borde vara automatiserade måste utföras manuellt. Syftet med studien är att undersöka hur utvecklingsmiljön för Java på Sandvik IT Services kan anpassas för att stödja plugin-utveckling för IBM Lotus Notes. I denna studie undersöks skillnaden mellan plugin-utveckling och den vanliga Java-utvecklingen på företaget samt hur detta påverkar verktygen i utvecklingsmiljön. Resultatet beskriver hur utvecklingsmiljön kan anpassas för att stödja plugin-utveckling och en lösning för detta föreslås. Slutligen visas en implementation av lösningen i form av en prototyp där utvecklingsmiljön anpassas för plugins med Maven pluginet Tycho.

Regression testing is the process of testing software to make sure changes to the software will not change the functionality. With growing test suites theneed to prioritize arises. This thesis explores how to weigh factors such as the number of fails detected, days since latest test case execution, and coverage. The prioritization is done over multiple test systems, software branches, and over many test sessions where the software can change in-between. With data provided by an industrial partner, we evaluate different ways to prioritize. The developed mathematical model could not cope with the size of the problem, whereas a simulated annealing approach based on said model proved highly successful. We also found that prioritizing test cases related to recent codechanges was effective. / Regressionstestning är processen att testa mjukvara för att säkerställa att ändringar av mjukvaran inte kommer att ändra funktionaliteten. Med växande testsviter uppstår behovet av att prioritera. Det här examensarbetet undersöker hur man väger faktorer som antalet upptäckta underkända testfall, dagar sedan testfallen senast kördes och täckning. Prioriteringen görs över flera testsystem, mjukvarugrenar och över många testsessioner där mjukvaran kan ändras däremellan. Med data från en industriell partner utvärderar vi olika sätt att prioritera. Den utvecklade matematiska modellen kunde inte hantera problemets storlek, medan en simulerad kylningsmetod baserad på denna modell visade sig vara mycket framgångsrik. Vi fann också att prioritering enligt ändringar som gjorts i mjukvaran var effetivt

An application build describes compiling and linking the source code of a developed application to libraries and executables. A Continuous Integration (CI) build executes such a build after the source code has been changed and tries to integrate the changes into the existing application. Such CI builds are executed automatically and include automated software tests, which give the developer the assurance that the changes are technically correct. When the time between the discovery of a test failure and the notification to the developer about it is too long, the development process will be impacted negatively and the beneficial effects of CI decrease. Even though several companies already have CI systems that display all events of a single CI build on a terminal during runtime, bigger applications often involve several CI builds in a single CI pipeline to integrate code changes. Observing the events of these CI builds during runtime might require concurrent monitoring of several different terminals. This thesis overcomes this issue by developing a Proof of Concept (PoC) which streams the test failures of a whole CI pipeline in real-time to the developer. To show the feasibility of real-time failure event streaming of CI builds, the PoC is implemented within Spotify’s CI for clientfacing applications. The issues highlighted by this initial PoC will help to refine the whole CI practice. Furthermore, the faster feedback cycles realised by this PoC will lead to a productivity, efficiency and happiness increase for the involved developers and, eventually, higher quality of the developed software. / Ett applikationsbygge beskriver kompilering och länkning av källkod för en utvecklad applikation till bibliotek och körbara filer. Ett Kontinuerlig Integrerings (CI)-bygge kör en sådan bygge efter att källkoden har ändrats och försöker integrera ändringarna i den befintliga applikationen. Sådana CIbyggen exekveras automatiskt och inkluderar automatiserade mjukvarutester, som ger utvecklaren en försäkran om att ändringarna är tekniskt korrekta. När tiden mellan upptäckten av ett testfel och meddelandet till utvecklaren om det är för lång kommer utvecklingsprocessen att påverkas negativt och de fördelaktiga effekterna av CI minskar. Även om flera företag redan har CIsystem som visar alla händelser av ett enskilt CI-bygge i en terminal under körning, involverar större applikationer ofta flera CI-byggen i en och samma CI-pipeline för att integrera kodändringar. Att observera händelserna i dessa CI-byggen under körning kan kräva jämlöpande övervakning av flera olika terminaler. Den här avhandlingen övervinner detta problem genom att utveckla en PoC som strömmar testfelen för en hel CI-pipeline i realtid till utvecklaren. För att visa genomförbarheten av strömning av felhändelser i realtid av CIbyggnader implementeras PoC i Spotifys CI för klientvända applikationer. De problem som lyfts fram av denna första PoC kommer att bidra till att förfina hela CI-praxisen. Dessutom kommer de snabbare återkopplingscyklerna som realiseras av denna PoCatt leda till ökad produktivitet, effektivitet och glädje för de inblandade utvecklarna och, så småningom, högre kvalitet på den utvecklade mjukvaran.

Continuous Integration (CI) techniques are widely adopted in web and application development but have received limited attention in the embedded software domain. This thesis investigates the application of CI techniques in embedded software development through a case study at Cobolt AB, a company specializing in optoelectronics. The study aims to identify suitable CI techniques, assess implementation efforts, and evaluate the impact of CI adoption in this domain. A CI service is implemented using Jenkins as the automation server, following an iterative development and deployment process. The service incorporates multi-target compilation, automated unit testing, test reporting, visual CI feedback, and trunk-based development. These techniques prove effective for embedded software with a modular firmware architecture. However, automated system testing encounters limitations due to the need for manual interaction with hardware targets. Challenges encountered during implementation, such as learning CI tools, managing build tool dependencies, and addressing manual input requirements for system testing, are overcome through iterative implementation, distributed build architecture, and selective test automation. Developers’ resistance to CI adoption diminishes as they experience the positive impact of the CI service. CI adoption in the embedded domain brings benefits such as fast bug detection, increased developer motivation, higher confidence in code quality, and encouragement for standardization n. No noticeable negative impacts are observed. Future research should focus on integrating hardware-in-the-loop simulation systems for comprehensive automated system testing, exploring validation on multiple hardware targets, and studying the vertical scaling capabilities of distributed build architectures with Jenkins. / Kontinuerlig integration (CI) tekniker används i stor utsträckning inom webboch applikationsutveckling, men har fått begränsad uppmärksamhet inom inbyggd programvarudomän. Denna avhandling undersöker tillämpningen av CI-tekniker inom inbyggd programvaruutveckling genom en fallstudie vid Cobolt AB, ett företag specialiserat på optoelektronik. Studien syftar till att identifiera lämpliga CI-tekniker, bedöma implementeringsinsatser och utvärdera effekten av CI-användning inom detta område. En CI-tjänst implementeras med Jenkins som automatiseringsserver, efter en iterativ utvecklings- och distribueringsprocess. Tjänsten inkluderar kompilering för flera målenheter, automatiserad enhetstestning, testrapportering, visuell CI-återkoppling och utveckling baserad på huvudgrenen. Dessa tekniker visar sig vara effektiva för inbyggd programvara med en modulär firmware-arkitektur. Dock begränsas automatiserad systemtestning av behovet av manuell interaktion med hårdvarumål. Utmaningar som uppstår under implementeringen, såsom att lära sig CIverktyg, hantera byggverktygsberoenden och hantera manuella indatakrav för systemtestning, övervinner genom iterativ implementering, distribuerade byggarkitekturer och selektiv testautomatisering. Utvecklarnas motstånd mot CI-användning minskar när de upplever de positiva effekterna av CI-tjänsten. CI-användning inom inbyggd programvaruutveckling medför fördelar som snabb upptäckt av fel, ökad utvecklar motivation, högre förtroende för kodkvalitet och främjande av standardisering. Inga märkbara negativa effekter observeras. Framtida forskning bör fokusera på att integrera hårdvaru-i-loop simulering för omfattande automatiserad systemtestning, utforska validering på flera hårdvarumål och studera de vertikala skalningsmöjligheterna hos distribuerade byggarkitekturer med Jenkins.

Time-consuming code builds within the Continuous Integration pipeline is a common problem in today’s software industry. With fast-evolving trends and technologies, Machine Learning has become a more popular approach to tackle and solve real problems within the software industry. It has been shown to be successful to train Machine Learning models that can classify whether a code change is likely to be successful or fail during a code build. Reducing the time it takes to run code builds within the Continuous Integration pipeline can lead to higher productivity in software development, faster feedback for developers, and lower the cost of hardware resources used to run the builds. To answer the research question: How accurate can success or failure in code build be predicted by using Machine Learning techniques on the historical data collection? The important factor is the historical data available and understanding the data. Thorough data analysis was conducted on the historical data and a data cleaning process to create a dataset suitable for feeding the Machine Learning models. The dataset was imbalanced, favouring the successful builds, and to balance the dataset the SMOTE method was used to create synthetic samples. Binary classification and supervised learning comparison of four Machine Learning models were performed; Random Forest, Logistic Regression, Support Vector Machine, and Neural Network. The performance metrics used to measure the performance of the models were recall, precision, specificity, f1-score, ROC curve, and AUC score. To reduce the dimensionality of the features the PCA method was used. The outcome of the Machine Learning models revealed that historical data can be used to accurately predict if a code change will result in a code build success or failure. / Den tidskrävande koden bygger inom pipeline för kontinuerlig integration är en vanlig faktor i dagens mjukvaruindustri. Med trender och teknologier som utvecklas snabbt har maskininlärning blivit ett mer populärt tillvägagångssätt för att ta itu med och lösa verkliga problem inom programvaruindustrin. Det har visat sig vara framgångsrikt att träna maskininlärningsmodeller som kan klassificeras om en kodändring sannolikt kommer att lyckas eller misslyckas under en kodbyggnad. Genom att förbättra och minska den tid det tar att köra kodbyggnader i den kontinuerliga integrationsrörledningen kan det leda till högre produktivitet inom mjukvaruutveckling och snabbare feedback för utvecklare. För att svara på forskningsfrågan: Hur korrekt kan förutsäga framgång eller misslyckande i kodbyggnad med hjälp av Machine Learning-tekniker för historisk datainsamling? Den viktiga faktorn är den tillgängliga historiska informationen och förståelsen för data. Noggrann dataanalys utfördes på historiska data och en datarengöringsprocess för att skapa en datamängd lämplig för matning av maskininlärningsmodellerna. Datauppsättningen var obalanserad och för att balansera användes uppsättningen SMOTE-metoden. Med binär klassificering och övervakad inlärningsjämförelse gjordes fyra maskininlärningsmodeller, Random Forest, Logistic Regression, Support Vector Machine och Neural Network. Prestandamätvärdena som används för att mäta prestandan hos modellerna är återkallelse, precision, f1-poäng och genomsnittlig ROCAUC-poäng. För att minska dimensionaliteten hos funktionerna användes PCA-metoden. Resultatet av modellerna avslöjar att de med god noggrannhet kan klassificeras om en kodändring misslyckas eller lyckas baserat på den datamängd som skapats från historiska data som används för att träna modellerna.

Most of the medium and big size software companies around the world are now using some form of continuous automatic build systems, with smaller companies following through. This approach, towards a more continuous flow, has pushed for more innovation in the domain and the adoption of various orchestration tools for these builds. At the same time, most continuous integration build systems do not leverage the data for improving the total building time. This thesis intends to decrease the overall building time in a pull based build system, named Blazar. This is obtained by decreasing the average time a build waits before being allocated a resource by the orchestration tool, Kubernetes. The improvement of average queuing time is done by leveraging the past data regarding the queue load of the system with the scope of predicting the amount of resources and preemptively allocating them. In the thesis, various time series prediction models are explored in order to find the most relevant one with regards to the available data. The final choice of the model is Facebook’s Prophet due to its ability to leverage multiple seasonalities, handle outliers, accommodate holidays, and provide fast predictions. By tuning various model’s parameters, it was possible to achieve satisfactory results. Thus, for some of the tested periods, the average queuing time was decreased with up to 20%, while maintaining a reasonable resource usage, compared to the time without using any prediction models. Finally, this thesis represents a practical approach that can be applied to other applications and systems. This thesis also details its limitations while discussing other solutions and ideas to further improve the results. / De flesta medelstora och större mjukvaruföretag runt om i världen använder idag någon form av kontinuerliga automatiska byggsystem, något som mindre företag även har börjat efterfölja. Detta tillvägagångssätt mot ett mer kontinuerligt flöde har drivit för mer innovation inom domänen och adopteringen av olika orkestreringsverktyg för dessa byggda program. Samtidigt utnyttjar de flesta kontinuerliga integrationssystem inte den data de samlar in för att förbättra den totala byggtiden. Denna uppsats avser att minska den totala byggtiden i ett pull-baserat byggsystem som heter Blazar. Detta uppnås genom att minska den genomsnittliga tid som ett byggt program väntar innan den tilldelas en resurs av orkestreringsverktyget, Kubernetes. Förbättringen av den genomsnittliga kötiden fås genom att utnyttja tidigare data om systemets köbelastning med omfattningen att förutsäga mängden resurser och fördela dem förebyggande. I avhandlingen undersöks olika tidsserieprognosmodeller för att hitta den mest relevanta med avseende på tillgänglig data. Det slutliga valet av modellen är Facebooks Prophet på grund av dess förmåga att utnyttja flera säsongsbestämmelser, hantera avvikelser, helgdagar och ge snabba förutsägelser. Genom att ställa in olika modellparametrar var det möjligt att uppnå tillfredsställande resultat. Under några av de testade perioderna minskade således den genomsnittliga kötiden med upp till 20%, samtidigt som en rimlig resursanvändning bibehölls, jämfört med tiden som ficks utan att använda någon förutsägelsemodell. Slutligen avser denna avhandling inte att ge en toppmodern lösning. Således slutar det med att beskriva sina begränsningar samtidigt som de tillhandahåller andra lösningar och idéer som kan förbättra resultaten.

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&amp;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&amp;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.

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.

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.