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.

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.

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.

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.

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.

In modern software development, continuous integration has become a integral part of agile development methods, advocating that developers should integrate their code frequently. Configura currently has one dedicated machine, performing tasks such as building the software and running system tests each time a developer submits new code to the main repository. One of the main practices of continuous integration advocates for having a fast build in order to keep the feedback loop short for developers, leading to increased productivity. Configura’s build system, named Build Central, currently uses a sequential build procedure to execute said tasks and was becoming too slow to keep up with the number of requested builds. The primary method for speeding up this procedure was to utilize the multi-core architecture of the build machine. In order to accomplish this, the system would need to deploy a scheduling algorithm to distribute and order tasks correctly. In this thesis, six scheduling algorithms are implemented and compared. Four of these algorithms are based on the classic list scheduling approach, and two additional algorithms are proposed which are based on dynamic scheduling principles. In this particular system, the dynamic algorithms proved to have better performance compared to the static scheduling algorithms. Performance on Build Central, using four processing cores, was improved with approximately 3.4 times faster execution time on an average daily build, resulting in a large increase of the number of builds that can be performed each day.

Many organizations have difficulty adopting advanced software development practices. Some software development project managers in large organizations are not aligned with the relationship between performance expectancy, effort expectancy, social influence, and facilitating conditions, as moderated by experience, with intent to adopt the DevOps practice of continuous delivery. The purpose of this study was to examine the statistical relationships between the independent variables—performance expectancy, effort expectancy, social influence, and facilitating conditions, as moderated by experience—and the dependent variable of behavioral intent to adopt a continuous delivery system. Venkatesh, Morris, Davis, and Davis's unified theory of acceptance and use of technology provided the theoretical framework. A stepwise multiple linear regression analysis was performed on survey data from 85 technical project managers affiliated with LinkedIn project management groups. The analysis reflected that only performance expectancy was significant in predicting intent to adopt continuous delivery. The findings may contribute to social change by providing project managers with the information they need to support organizational change, collaboration, and facilitation. The knowledge gained may additionally help organizations develop operational efficiency, competitive advantage, and generate higher value to their clients and society.

Manual deploys and testing of code can be both time-consuming and error-prone. Many repetitive manual steps can lead to critical tests or necessary configuration being forgotten or being skipped due time-constraints resulting in software that doesn’t work as intended when deployed to production. The purpose of this report is to examine whether continuous delivery(CD) could lead to any positive effects and if there are any obstacles for CD in an Episerver project at Sigma ITC. The study was done by implementing a CD pipeline for a project similar to a real project at Sigma then letting the developers work with it and interviewing them about their current workflow, their attitude towards the different steps involved and if they saw any problems with CD for their project. Even if the developers, in general, where positive to CD they had some reservations about it in their current projects. The main obstacle the developers saw where the time/cost which would affect the customer and also some uncertainty around the complexity in testing Episerver. The results show that there could be positive effects of CD even if the project type is not optimal for reaping all the CD benefits, it all depends on people involved seeing a value in testing and the questions around testing in Episerver are straightened out.

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.

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.