With the advent of DevOps and its success stories, many large firms in the regulatory sector have begun to study more streamlined software deployment strategies. Traceability and change management is vital in these regulated organizations to keep track of when, why, and what was supplied to the production environment at what time. This thesis intends to provide a technique for one of the major banks in Sweden to deploy software using Azure DevOps pipelines while employing tracing and approving a deployment in an on-premises change management system. Since direct communication between the change management system and Azure DevOps is not possible, the decision was made to create an on-premises RFC handler and use Azure storage account queues to facilitate communication between pipelines searching for deployment grants and the on-premises change management system. To determine what value the RFC handler could provide the organization, interviews were conducted with several change management experts at the bank. One of the most notable conclusions from the interviews was that the RFC handler would likely reduce deployment time relative the old workflow. / Med tillkomsten av DevOps och dess framgångshistorier har många stora företag inom regleringssektorn börjat studera mer strömlinjeformade programvarudistributionsstrategier. Spårbarhet och förändringshantering är avgörande i dessa reglerade organisationer för att förklara när, varför och vad som levererades till produktionsmiljön vid vilken tidpunkt. Detta examensarbete avser att tillhandahålla en teknik för en av de stora bankerna i Sverige att distribuera programvara med hjälp av Azure DevOps-pipelines samtidigt som man använder spårning och godkännande av en driftsättning i ett lokalt förändringshanteringssystem. Eftersom direkt kommunikation mellan ändringshanteringssystemet och Azure DevOps inte är möjlig, togs beslutet att skapa RFC handler och använda Azure Storage-kontoköer för att underlätta kommunikationen mellan pipelines som söker efter driftsättningsgodkännande och den lokala förändringshanteringen. För att avgöra vilket värde RFC handler skulle ge organisationen, genomfördes intervjuer med flera experter på förändringshantering inom banken. En av de viktigaste slutsatserna från intervjuerna var att RFC handler kommer att minska driftsättningstiden jämfört med tidigare arbetsflöde.

Software-Defined Networking (SDN) is a new evolving approach within the networking domain. The concept is based on decoupling and abstracting the control and data plane of the traditional network devices. This separation facilitates the network operations with many benefits such as faster delivery, better segmentation, scalability, programmability, enhancing the quality of service and the quality of experience. Despite all the benefits, SDN has its own set of challenges.  The purpose of this study is to explore the main challenges in adopting SDN architecture in Swedish organizations. The focus is on the skills gap as one of the main challenges and how Swedish organizations were able to manage it. A qualitative approach has been chosen to conduct this research using semi-structured interviews to collect the data from seven different organizations, using a mixture of a purposive and snowball sampling selection. A thematic approach was then used to generate categories and themes from the collected data. The results are consistent with previous studies when it comes to technical, financial and security challenges. The technical challenges, however, were fewer in comparison with previous studies. A new way of working was presented as a new challenge when implementing SDN solutions. Furthermore, the knowledge gap was mentioned as a key challenge within Swedish organizations when implementing/operating SDN.  Finally, clear recommendations were made to overcome the knowledge gap challenge, from consulting a third-party expert, having a detailed plan, employing a multiphase process for SDN implementation, to having an online learning platform available to the IT team. / Software-Defined Networking (SDN) är en framväxande teknik inom nätverksdomänen. Konceptet är baserat på att frikoppla och abstrahera kontrollplan och dataplan för de traditionella nätverksenheterna. Separationen underlättar nätverksdrift och ger många fördelar såsom, snabbare leverans, bättre segmentering, skalbarhet, förbättrade kvalitet på tjänsten och kvalitet på upplevelsen. Trots många fördelar har SDN också utmaningar. Syftet med denna studie är att utforska de största utmaningarna med att implementera SDN-arkitektur i svenska organisationer. Fokus ligger på kunskapsklyftan som är en av de tidigare identifierade huvudutmaningarna, och hur svenska organisationer har hanterat dessa. En kvalitativ metod har valts för att genomföra denna studie med hjälp av semistrukturerade intervjuer för att samla in data från sju olika organisationer, med hjälp av en blandning av målinriktat och snöbollsurval. En tematisk metod användes sedan för att generera kategorier och teman från den insamlade datan. Resultaten överensstämmer med tidigare studier när det gäller tekniska, ekonomiska och säkerhetsmässiga utmaningar. De tekniska utmaningarna var dock färre jämfört med tidigare studier. Ett nytt arbetssätt presenterades som en ny utmaning vid implementering av en SDN-lösning. Dessutom, nämndes kunskapsklyftan som en central utmaning inom svenska organisationer vid implementering och drift av SDN. Slutligen presenterades tydliga rekommendationer för att övervinna utmaningen med kunskapsgapet, från att konsultera en tredje part, att ha en tydlig plan, använda en flerfasprocess för SDN-implementering samt att ha en digital utbildningsplattform tillgänglig för IT-teamet.

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.

The choice of development environment can be crucial when it comes to developing a software. Few researches exist on comparing development environments. Docker is a relatively new software for handling and setting up container-environments. In this research, the possibility of using Docker as a software development environment is being investigated and compared against virtual machines as a development environment. The purpose of this research is to examine how the choice of development environment affect the development process. The work was qualitative, with an inductive and a deductive approach. It included a case study with two phases. One in which virtual machines and one in which Docker were used to implement a development environment. Observations were made after each implementation. The data from each implementation were then compared and evaluated against each other. The results from the comparisons and the evaluation clearly shows that the choice of development environment can influence the process of developing software. Different development environments affect the development process differently, both good and bad. With Docker, it’s possible to run more environments at once than when using virtual machines. Also, Docker stores the environments in a clever way that results in the environments taking up less space on the secondary storage compared to virtual machine environments. This is due to that Docker uses a layer system when it comes to containers and their components. When using Docker, no Graphical User Interface (GUI) to install and manage applications inside a container is provided, this can be a drawback since some developers may need a GUI to work. The lack of a GUI makes it harder to get an Integrated Development Environment (IDE) to work properly with a container to for example debug code. / Valet av utvecklingsmiljö kan vara avgörande vid utveckling av mjukvara. Få undersökningar finns idag angående jämförelser mellan utvecklingsmiljöer. Docker är en relativt ny mjukvara för att sätta upp samt hantera container- miljöer. I denna undersökning, kommer möjligheten att använda Docker som utvecklingsmiljö att undersökas och jämföras mot virtuella maskiner som utvecklingsmiljö. Syftet med undersökningen är att se hur valet av utvecklingsmiljö påverkar utvecklingsprocessen av en mjukvara. Arbetet bedrevs på ett kvalitativt sätt, med både ett induktivt samt ett deduktivt tillvägagångssätt. Det inkluderade även en fältstudie med två faser. En där virtuella maskiner och en där Docker användes till att implementera en utvecklingsmiljö. Observationer utfördes efter varje implementation. Data från varje implementation jämfördes och evaluerades mot varandra. Resultaten från jämförelserna och evalueringen visar att valet av utvecklingsmiljö har inflytande på processen av utveckling av mjukvara. Olika utvecklingsmiljöer påverkar utvecklingsprocessen olika, både på bra och dåliga sätt. Med Docker är det möjligt att köra fler miljöer samtidigt än vad som är möjligt vid användande av virtuella maskiner. Docker lagrar även miljöerna på ett smart sätt, som gör att de tar upp mindre plats på den sekundära lagringen jämfört med virtuella maskiner. Detta är på grund av att Docker använder sig av ett lager-system när det gäller containrar och deras komponenter. När Docker används, tillhandhålls inget Graphical User Interface (GUI) för att installera eller hanterar applikationer inuti en container, detta kan vara en nackdel då vissa utvecklare kan behöva ett GUI för att arbeta. Avsaknaden av ett GUI gör det svårare att få en Integrated Development Environment (IDE) att fungera ordentligt med en container för att till exempel avlusa kod.

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.

This thesis explores applying DevOps practices to mitigate knowledge loss in project-based environments. In the context of high developer turnover, the study aims to implement a standardised DevOps workflow using automation and knowledge management. The research questions of the thesis are answered by following a method consisting of interviews, requirements gathering, implementation of a DevOps workflow focusing on knowledge management practices and evaluation using a DevOps maturity model. The study finds that explicit knowledge practices, including issue tracking, code reviews, and knowledge repositories, are complemented by developers’ tacit knowledge. Additional practices including testing standards, coding standards, and containerisation also contribute to knowledge retention. Integrating these practices into a DevOps workflow involves automation, tool integration, and continuous workflow through a CI/CD pipeline. The research evaluates the organisation’s initial maturity level at level 1 ("Initial") in technology and process areas. However, implementing the proposed DevOps workflow increases the maturity level to level 3 ("Defined"). This, in turn, indicates that knowledge management practices can be integrated into a DevOps workflow to mitigate knowledge loss further.

Цель работы – внедрение необходимых практик DevOps в компании «Технопарк-Автоматизация» и снижение затрат на используемое программное обеспечение. Объектом исследования является управление жизненным циклом создаваемого программного обеспечения. Методы исследования: анализ существующих DevOps-практик, анализ и сравнение различных DevOps-инструментов, операционных систем и web-серверов. Результат работы: разработана DevOps-инфраструктура проектов компании, проведена оценка экономической выгоды от реализации данной работы. Магистерская диссертация состоит из введения, 4 глав и заключения, изложенных на 70 страницах, а также библиографического списка. / The goal of the work is to implement the necessary DevOps practices in the Technopark-Automation company and reduce the costs of the software used. The object of the study is the life cycle management of created software. Research methods: analysis of existing DevOps practices, analysis and comparison of various DevOps tools, operating systems and web servers. Result of the work: a DevOps infrastructure for the company’s projects was developed, and the economic benefits from the implementation of this work were assessed. The master's thesis consists of an introduction, 4 chapters and a conclusion, presented on 70 pages, as well as a bibliography.

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.

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.