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.

The amount of data being collected is increasing astronomically. Hence questions about privacy and data security are becoming more important than ever. A fast-changing culture is also reflected in the demands and requirements placed on software systems. Products and services need to evolve with the demands and feedback from customers to stay relevant on the market. Working methods and technologies have been refined to afford updating software continuously. However, rapidly changing software cause concern for the quality and level of security in the release. This thesis is a comprehensive literature study, reviewing the challenges of ensuring secure practises for continuously evolving software. The problem solved by the thesis is lack of an overall picture of the security concerns during continuous evolution. The findings are summarised in a checklist of areas of concern for security when maintaining and updating systems with continuous practises in cloud environments. This study shows that ensuring security, while delivering continuous releases, is a daunting task. It requires close collaboration between teams handling different aspects of software. This, in turn, entails a widening of competences to include knowledge about the work of other departments. It is concluded that personnel with this wide range of skill will be hard to acquire. / I en tid då mängden data som samlas in om individer ökar i ohindrad takt, blir frågor om integritet och informationssäkerhet viktigare än någonsin. Kraven på snabb utveckling och förändring präglar även metoderna för mjukvaruutveckling. Produkter och tjänster måste konstant anpassas efter kundernas önskemål för att förbli relevant på marknaden. Arbetssätt och teknologier har utvecklats över tid för att möjliggöra mjukvara som uppdateras kontinuerligt. Konstant föränderlig mjukvara leder dock till oro för kvalitén och säkerheten av uppdateringarna. Den här uppsatsen är en litteraturstudie som undersöker utmaningarna att säkerställa säkerhet för mjukvara som uppdateras kontinuerligt. Problemet som löses genom studien är den saknade helhetsbilden av säkerhetsproblem vid kontinuerligt föränderlig mjukvara. Resultatet sammanfattas i en checklista för områden som väcker oro för säkerheten vid arbetssätt som tillåter kontinuerliga uppdateringar i moln-miljöer. Studien visar att leverera säkra lösningar kontinuerligt är en svår uppgift. Det kräver nära samarbete mellan team som sköter olika delar av mjukvaruutveckling. Detta fordrar vida kompetenser som inkluderar förståelse av varandras arbete. Att finna personal med tillräckligt vida kompetenser uppskattas vara problematiskt.

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.