Webbapplikationer bygger på många olika webbramar och utvecklare har en mängd olika webbramverk att välja mellan när de utvecklar en webbapplikation. Två populära webbramverk som finns på marknaden är NextJS och Create React App (CRA). Varje ramverk har sina egna för- och nackdelar i olika perspektiv. Syftet med denna studie är att granska om det finns några skillnader i dessa två populära webbramverk ur ett kontinuerligt integrations och kontinuerligt leverans-perspektiv med ett fokus på att kolla närmare på skillnaderna inom utvecklingsprocessen vid utökningar av applikationer och den tid det tar att bygga och driftsätta applikationer i de olika ramverken. För att få kunskap om ämnet så har en teoretisk studie av webbaserade källor gjorts och en applikation har skapats i de båda ramarverken för att sedan utvidgas med ytterligare verktyg för att kunna utföra en jämförelse. Studien visar att ramverken resulterar i liknande byggoch driftsättningstider men skiljer sig dock åt gällande konfigurationer när applikationerna utökades och att NextJS gav en enklare åtkomst åt konfigurering. / Web applications are built on numerous of different web frameworks and developers have a plethora of different web frameworks to choose from when developing a web application. Two popular web frameworks on the market are NextJS and Create React App (CRA). Each framework has its own advantages and disadvantages in different perspectives. The objective of this study is to review if there are any differences in these two popular web frameworks in a continuous integration and continuous delivery perspective looking closer at the differences in the development process when extending applications and the time it takes to build and deploy applications in the different frameworks. To gain knowledge about the subject, a theoretical study on web based sources has been made and an application has been created in both framework to then be extended with further tools to be able to perform the comparison. The study shows that the frameworks results in similar build and deployment times but does however differ in the configurations when extending applications and that NextJS did provide a more straightforward configuration.

AbstractThe increasing amount of data available from software systems has given a unique opportunity for software development organizations to make use of it in decision-making. There are several types of data such as bug reports, website interaction information, product usage extent or test results coming into software-intensive companies and there is a perceived lack of structure associated with the data. The data is mostly scattered and not in an organized form to be utilized further. The data, if analyzed in an effective way, can be useful for many purposes, especially in decision-making. The decisions can be on the level of business or on the level of product execution. In this paper, through a literature review, an interview study and a qualitative analysis we categorize different types data that organizations nowadays collect. Based on the categorization we order the different types of decisions that are generally taken in a software development process cycle. Combining the two we create a model to explain a recommended process of handling the surge of data and making effective use of it. The model is a tool to help both practitioners and academicians who want to have a clearer understanding of which type of data can best be used for which type of decisions. An outline of how further research can be conducted in the area is also highlighted.

The current migration of companies towards continuous integration and delivery as well all service-oriented business models brings great benefits but also challenges. One challenge that a company striving to establish continuous practices is the need for pipeline traceability, which can bring great enhancements to continuous integration and delivery pipelines as well as offer a competitive edge. This exploratory case study looks at the current and desired states at Axis Communications, a global leader in network video solutions based in Lund, Sweden. It further evaluates the practical and organizational aspects of the adoption of the Eiffel protocol in the company’s pipeline tools through developing a proof-of-concept Eiffel plugin for Artifactory. Based on the discovered technical and organizational needs and obstacles, it draws conclusions and makes recommendations on a possible strategy when introducing Eiffel in a company.

The thesis deals with the reengineering of the Umbrela questionnaire system. The text describes the reasons for reengineering, technology selection, application design, description of basic application blocks and implementation. The work also mentions proposals for improvement of the overall project and its further development.

Continuous Integration (CI) has become an essential practice in software development, allowing teams to integrate code changes frequently and detect issues early. However, the selection of proper test cases for CI remains a challenge, as it requires balancing the need for thorough testing with the minimization of execution time and resources. This study proposes a practical and lightweight approach that leverages Reinforcement Learning with a linear function approximator for test case selection in CI. Several models are created where each one focuses on a different feature set. The proposed method aims to optimize the selection of test cases by learning from past CI outcomes, both the historical data of the test cases and the coverage data of the source code, and dynamically adapting the models for encountering new test cases and modified source code. Through experimentation and comparison between the models, the study demonstrates which feature set is optimal and efficient. The result indicates that Reinforcement Learning with a linear function approximator using coverage information can effectively assist in selecting test cases in CI, leading to enhanced software quality and development efficiency.

The goals with continuous delivery are to reduce the risk, cost, and time of releasing software to the stakeholders and the users. It is a process which can result in reliable releases and reducing errors in the software. Furthermore, there are some best practices to follow when conducting the continuous delivery process, involving version control, and build tools. There are however some obstacles and challenges for organizations when moving to continuous delivery. For example, complex environments, organizational problems, and lack of automated test cases. This master thesis investigates continuous delivery through a literature review, a multiple-case study, and fieldwork. The result can either be used by software engineers and organizations who are new to the continuous delivery concept. Or the result can be used by more experienced software engineers to gain more knowledge about existing obstacles and for further research.

Kubernetes is a fast emerging technological platform for developing and operating modern IT applications. The capacity to deploy new apps and change old ones at a faster rate with less chance of error is one of the key value proposition of the Kubernetes platform. A continuous integration and continuous deployment (CI/CD) pipeline is a crucial component of the technology. Such pipelines compile all updated code and do specific tests and may then automatically deploy the produced code artifacts to a running system. There is a thriving ecosystem of CI/CD tools. Tools can also be divided into two types: integrated and standalone. Integrated tools will be utilized for both pipeline phases, CI and CD. The standalone tools will be used just for one of the processes, which needs the usage of two independent programs to build up the pipeline. Some tools predate Kubernetes and may be converted to operate on Kubernetes, while others are new and designed specifically for usage with Kubernetes clusters. CD systems are classified as push-style (artifacts from outside the cluster are pushed into the cluster) or pull-style (CD tool running inside the cluster pulling built artifacts into the cluster). Pull- and push-style pipelines will have an impact on how cluster credentials are managed and if they ever need to leave the cluster. This thesis investigates the deployment time, fault tolerance, and access security of pipelines. Using a simple microservices application, a testing setup is created to measure the metrics of the pipelines. Drone, Argo Workflows, ArgoCD, and GoCD are the tools compared in this study. These tools are coupled to form various pipelines. The pipeline using Kubernetes-specific tools, Argo Workflows and ArgoCD, is the fastest, the pipeline with GoCD is somewhat slower, and the Drone pipeline is the slowest. The pipeline that used Argo Workflows and ArgoCD could also withstand failures. Theother pipelines that used Drone and GoCD were unable to recover and timed out. Pull pipelines handles the Kubernetes access differently to push pipelines as the Kubernetes cluster credentials does not have to leave the cluster, whereas push pipelines needs the cluster credentials in the external environment where the CD tool is running.

In this thesis the application of software defect prediction to predict unit test failure is investigated. Data for this purpose was collected from a Continuous Integration development environment. Experiments were performed using semantic features from the source code. As the data was imbalanced with defective samples being in minority different degrees of oversampling were also evaluated. The data collection process revealed that even though several different code commits were available few ever failed a unit test. Difficulties with linking a failure to a specific file were also encountered. The machine learning model used in the project produced poor results when compared against related work, from which it was based on. In F-measure, it on average achieve 53% of the mean performance of state-of-the-art for software defect prediction on bugs in Java source files. Specifically, it would appear that very little information was available for the model to learn defects in files not present in training data. / I denna avhandling undersöks applikationen av prognos för mjukvarudefekter för att förutse enhetstestfel. Data för detta syfte samlades in från en utvecklingsmiljö med kontinuerlig integration. Experimenten utfördes med användning av semantiska särdrag samlade från källkod. Då data var obalanserat med defekta exempel i minoritet evaluerades olika grader av översampling. Datainsamlingsprocessen visade att även om det fanns många kodinlämningar så misslyckades få någonsin ett enhetstest. Svårigheter med att länka testmisslyckanden till en specifik fil påträffades också. Den använda maskininlärningsmodellen uppvisade också dåliga resultat i jämförelse med relaterade värk. Mätt i F-measure uppnåddes i genomsnitt 53% av genomsnittlig prestandan av bästa möjliga prognos av mjukvarudefekter av buggar i Java källkod. Specifikt så framträdde det att väldigt lite information verkar finnas för modellen att lära sig defekter i filer som ej fanns med i träningsdata.

When designing a software, it was commonplace to use specialised techniques to ensure quality of the final product. Continuous Integration (CI) provides developers a strategy by allowing for teams to continuously add to their project daily without conflicting with prior work. An automated process would check that these new integration additions are functional so that any faults were quickly identified for correction. Continuous Integration played a pivotal role in organisations that developed software solutions for their own or their customers’ processes. It comes as no shock that an abundance of research illustrates its importance and success in software development. Automated testing was praised so much so that there was a distinct lack of negatives particularly in the professional industry. The goal of this study was to gather knowledge about automated testing in a work environment so that principles for implementing automated testing. This was conducted by a qualitative case study while looking at the developer/user perspective. This was done by conducting semi-structured interviews with employees working with automated testing in a telecommunication organisation. The study’s results presented eight themes that the informants and prior literature studies observed as issues of importance. These themes showed that the automated testing had experienced problems in practice that were not noticed in academical papers and for that, seven recommendations were presented for other organisations to be observant of.

Static Application Security Testing Tools (SAST) is a security tool that claims to help with security in an IT system. Static Application Security Testing tools are technical solutions that operate within the continuous integration of the system. The tool uses frameworks such as OWASP and CWE to detect common vulnerabilities in the codebase by analysing code in the building and testing phase of continuous integration. The problem with SAST tools is that there are many different beliefs surrounding them. Some say they are crucial for security, while some believe they are less helpful and can even inhibit projects by introducing false positives. This thesis determines if SAST tools are an effective solution to security problems within in an IT system. The focus was on logistics- and infrastructure-oriented operations, which the partner company Triona operates within. We use literature review to look at previously similarly conducted research combined with interviews with experienced people within the fields. This gives qualitative results that coupled with previous research can be generalized. The results show that SAST tools are effective tools if used responsibly. Both the literature and interviews conclude that SAST tools are not enough on their own to satisfy the security requirements but must be combined with responsible use of the tools as well as code reviews and other types of testing. SAST tools are also shown to have some problems, mainly false positives, and false negatives. There are also problems related to the implementation of the tools. These problems are costs that comes with implementation, as well as the time spent on it. Other problems are bad communication with developer teams that led to developers not knowing what to do in case of errors shown by the tool. Interviews conducted provides information that SAST tools are not only tools for security but also helps with manageability of code bases.