Det finns idag ett stort behov för IT-verksamheter att arbeta med ständiga förbättringar för att hålla sig konkurrenskraftiga på marknaden. En viktig del i arbetet med ständiga förbättringar är att bedöma och utvärdera den befintliga situationen i syfte att skapa bra åtgärder. För att möjliggöra denna bedömning kan verksamheter använda sig av standarder och modeller för processbedömning. I IT-sektorn anstränger sig många företag med att förbättra arbetsprocesserna och brygga samman sina utvecklings- (eng. Development) och driftsavdelningar (eng. Operations). Arbetet med denna sammanlänkning benämns ofta som DevOps. Problemet som vi adresserar är att det saknas enkla digitala verktyg som är kontextualiserade för verksamheter som vill förbättra sitt samarbete mellan dessa avdelningar. Den befintliga klassen av system för DevOps-bedömning innehåller modeller som är otillräckliga och stödjer därmed inte utvecklings- och driftsaktörer i deras arbete att bedöma sin verksamhet för att ge beslutsunderlag för förbättring. I syfte att förbättra möjligheterna för DevOps-verksamheter och samtidigt skapa ny kunskap har vi designat och utvärderat en digital bedömningsmodell som kan användas i praktiken. För att uppfylla syftet har vi använt oss av forskningsmetoden Action Design Research som är särskilt lämplig metod vid skapande av IT-relaterade modeller i en verklig kontext. Resultatet bekräftar att befintliga bedömningsmodeller inte är tillräckliga och att problemet är generaliserbart som en klass av problem. En operativ digital modell kommer även presenteras med syfte att bedöma verksamheter ur ett DevOps-kontext. Vid utveckling av artefakten har även tre generella designprinciper identifierats vilka utvecklare och praktiker bör följa vid design av framtida bedömningsmodeller för DevOps. Principerna innebär att vid skapandet av en bedömningsmodell för DevOps i en IT-kontext bör det (i) användas en betygsskala uppdelad på fyra kapacitetsnivåer, (ii) påståenden som används i modellen bör vara förändrings- och anpassningsbara då verksamheter är unika, samt att (iii) modellen bör utvecklas så att development och operations kan utföra utvärderingen tillsammans. / Today, there is a great need for IT businesses to work with continuous improvement to keep competitive on the market. An important part of the work of continuous improvement is to assess and evaluate the existing situation with a view for creating profitable actions. To enable this assessment, businesses can use standards and models for process assessment. In the IT sector, many companies try to improve their work processes and combine development and operations. The work of this interconnection is often referred to as DevOps. The problem we address is that there are no simple digital tools that are contextualized for activities that want to improve collaboration between these departments. The existing class of DevOps assessment systems contains inadequate models, thus not support development and operational players in their work to assess their business to provide a basis for improvements. In order to improve the opportunities for DevOps operations while creating new knowledge, we have designed and evaluated a digital assessment model that can be used in practice. To fulfill the purpose, we have used the research method Action Design Research, which is a particularly suitable method of creating IT-related models in a real context. The result confirms that existing assessment models are not sufficient and that the problem is generalizable as a class of problems. An operating digital model will also be presented with the purpose of assessing activities from a DevOps context. In developing the artifact, three general design principles have also been identified which developers and practitioners should follow for design of future assessment models for DevOps. The principles imply that, in the creation of a DevOps assessment model in an IT context, (i) a grading scale should be divided into four capacity levels, (ii) statements used in the model should be changeable and adaptable as organizations are unique and (iii) should be developed so that development and operation can perform the evaluation together.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-03-16T12:48:08Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) / Made available in DSpace on 2016-03-16T12:48:08Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) Previous issue date: 2015-08-21 / Hoje as organizações de T.I. estão enfrentando um sério desafio, por um lado temos mercados cada vez mais competitivos, com mudanças quase que rotineiras nos softwares e uma variedade imensa de dispositivos e sistemas operacionais; por outro, os sistemas ficam cada vez mais complexos, integrados a outros serviços e exigindo um alto grau de confiabilidade e disponibilidade dos mesmos, exigindo assim um processo de implantação cada vez mais eficiente e robusto. Nos últimos anos o termo DevOps – colaboração entre desenvolvimento e operação - e suas práticas foram amplamente usados e discutidos sob diferentes aspectos. Assim como no movimento ágil, DevOps também nasceu na indústria e a partir da necessidade da mesma. Por mais que várias organizações já adotem práticas que ficaram conhecidas como DevOps, seu uso ainda não é prescritivo, existindo assim uma variedade de diferentes manifestações de uso em termos de definição e padrão dentre as organizações. Diante disso, esta dissertação teve por objetivo realizar um mapeamento sistemático da literatura e um survey em busca do movimento DevOps, áreas de concentração dos estudos, os principais autores da área e as principais práticas e formas de uso de DevOps nas organizações. Como contribuição, esta pesquisa identificou que dentre as principais áreas de DevOps podem-se destacar (i) entrega, (ii) integração, (iii) e testes contínuos, além da (vi) automação da infraestrutura. Como principais práticas foram possíveis destacar: (a) implantações através de máquinas virtuais, (b) visibilidade do pipeline de implantação, (c) processos robustos de roolbacks, além de técnicas como (d) canary release, (e) toogled features e (f) blue-green deployments. / Today's IT organizations are facing a serious challenge, on the one hand we increasingly competitive markets with routine software’s changes and a wide variety of devices and operating systems; on the other hand, the systems are increasingly complex, integrated with other services and requiring a high degree of reliability and availability requiring a deploy process increasingly efficient and robust. In recent years the DevOps term - a clipped compound of development and operations - and DevOps’s practices were widely used and discussed under different aspects. As agile movement, the DevOps term was also born in the industry’s need. Today many organizations already adopt practices that became known as DevOps its use is not prescriptive, so there is a variety of different manifestations of use in terms of definition and standard among organizations. Therefore, this work aimed to carry out a mapping study and a survey in search of the state of the art DevOps movement, concentration areas of study, the main authors of the area and the main practices and the use of DevOps in organizations. As a contribution, this research found that among the main DevOps area can highlight: (i) continuous delivery; (ii) continuous integration; (iii) continuous testing; and (vi) infrastructure’s automation. Additionally, we can emphasize the main practices in the DevOps adoption: (a) deploys through virtual machines; (b) visibility’s deployment pipeline; (c) robust processes roolbacks, and techniques such as (d) canary release, (e) toogled features and (f) blue-green deployments.

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-03-16T14:48:51Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) / Made available in DSpace on 2016-03-16T14:48:52Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Filipe_Versao_Final_Pos_Defesa_Deposito.pdf: 1855793 bytes, checksum: 366a64a51c618d78933bc62349a182cc (MD5) Previous issue date: 2015-08-21 / Hoje as organizações de T.I. estão enfrentando um sério desafio, por um lado temos mercados cada vez mais competitivos, com mudanças quase que rotineiras nos softwares e uma variedade imensa de dispositivos e sistemas operacionais; por outro, os sistemas ficam cada vez mais complexos, integrados a outros serviços e exigindo um alto grau de confiabilidade e disponibilidade dos mesmos, exigindo assim um processo de implantação cada vez mais eficiente e robusto. Nos últimos anos o termo DevOps – colaboração entre desenvolvimento e operação - e suas práticas foram amplamente usados e discutidos sob diferentes aspectos. Assim como no movimento ágil, DevOps também nasceu na indústria e a partir da necessidade da mesma. Por mais que várias organizações já adotem práticas que ficaram conhecidas como DevOps, seu uso ainda não é prescritivo, existindo assim uma variedade de diferentes manifestações de uso em termos de definição e padrão dentre as organizações. Diante disso, esta dissertação teve por objetivo realizar um mapeamento sistemático da literatura e um survey em busca do movimento DevOps, áreas de concentração dos estudos, os principais autores da área e as principais práticas e formas de uso de DevOps nas organizações. Como contribuição, esta pesquisa identificou que dentre as principais áreas de DevOps podem-se destacar (i) entrega, (ii) integração, (iii) e testes contínuos, além da (vi) automação da infraestrutura. Como principais práticas foram possíveis destacar: (a) implantações através de máquinas virtuais, (b) visibilidade do pipeline de implantação, (c) processos robustos de roolbacks, além de técnicas como (d) canary release, (e) toogled features e (f) blue-green deployments. / Today's IT organizations are facing a serious challenge, on the one hand we increasingly competitive markets with routine software’s changes and a wide variety of devices and operating systems; on the other hand, the systems are increasingly complex, integrated with other services and requiring a high degree of reliability and availability requiring a deploy process increasingly efficient and robust. In recent years the DevOps term - a clipped compound of development and operations - and DevOps’s practices were widely used and discussed under different aspects. As agile movement, the DevOps term was also born in the industry’s need. Today many organizations already adopt practices that became known as DevOps its use is not prescriptive, so there is a variety of different manifestations of use in terms of definition and standard among organizations. Therefore, this work aimed to carry out a mapping study and a survey in search of the state of the art DevOps movement, concentration areas of study, the main authors of the area and the main practices and the use of DevOps in organizations. As a contribution, this research found that among the main DevOps area can highlight: (i) continuous delivery; (ii) continuous integration; (iii) continuous testing; and (vi) infrastructure’s automation. Additionally, we can emphasize the main practices in the DevOps adoption: (a) deploys through virtual machines; (b) visibility’s deployment pipeline; (c) robust processes roolbacks, and techniques such as (d) canary release, (e) toogled features and (f) blue-green deployments.

Software projects can nowadays have complex infrastructures behind them, in the form of libraries and various other dependencies which need to be installed on the machines they are being developed on. Setting up this infrastructure on a new machine manually can be a tedious process prone to errors. This can be avoided by automating the process using a software provisioning tool, which can automatically transfer infrastructure between machines based on instructions which can be version controlled in similar ways as the source code. Docker and Vagrant are two tools which can achieve this. Docker encapsulates projects into containers, while Vagrant handles automatic setup of virtual machines. This study compares Docker and Vagrant regarding their performance for machine level provisioning, both when setting up an infrastructure for the first time on a new machine, as well as when implementing a change in the infrastructure configuration. This was done by provisioning a project using both tools, and performing experiments measuring the time taken for each tool to perform the tasks. The results of the experiments were analyzed, and showed that Docker performed significantly better than Vagrant in both tests. However, due to limitations of the study, this cannot be assumed to be true for all use cases and scenarios, and performance is not the only factor to consider when choosing a provisioning tool. According to the data collected in this study, Docker is thereby the recommended tool to choose, but more research is needed to determine whether other test cases yield different results. / Moderna mjukvaruprojekt kan ha en komplex infrastruktur bakom sig, i form av bibliotek och andra beroenden som måste installeras på utvecklarmaskiner. Att konfigurera denna infrastruktur på en ny maskin manuellt kan vara en tidskrävande process, som även kan leda till en ofullständigt eller felaktigt konfigurerad lösning. Detta kan undvikas genom att automatisera processen med hjälp av provisioneringsverktyg, som automatiskt kan överföra infrastrukturer mellan maskiner baserat på instruktioner som kan versionshanteras på liknande sätt som källkoden. Docker och Vagrant är två verktyg som kan användas till detta ändamål. Docker kapslar in projektet i containers, medan Vagrant hanterar automatisk konfiguration av virtuella maskiner. Denna studie jämför Docker och Vagrant avseende deras prestanda för mjukvaruprovisionering på maskinnivå, både när det kommer till en förstagångsinstallation av infrastrukturen på en ny maskin, och även implementering av en ändring i konfigurationen av infrastrukturen. Denna jämförelse gjordes genom att implementera båda lösningarna, och sedan utföra experiment för att mäta tidsåtgången för båda verktygen att lösa de två uppgifterna. Resultaten av experimenten analyserades, och visade att Docker presterade bättre än Vagrant i båda tester. På grund av begränsningar i studien kan detta inte antas vara sant för alla användningsområden och scenarier, och prestanda är inte den enda faktorn att ha i åtanke när ett provisioneringsverktyg ska väljas. Baserat på datan insamlad i denna studie är Docker därmed verktyget som rekommenderas, men mer forskning krävs för att avgöra om andra testområden ger andra resultat.

In recent years, companies and organizations have increasingly integrated software security testing into the software development life cycle using DevOps practices. The current integration approach introduces multiple challenges in an information technology environment that consists of a large number of software development projects and multiple software security testing tools. This thesis aims to address these challenges by proposing a microservice-based framework to unify application security testing. The thesis first identifies the challenges, then proposes a design for a framework based on relevant literature and common characteristics of application security testing tools. The main components of the proposed framework are implemented and evaluated. The evaluation result shows that the framework offers many benefits: more secure credential management process, reduced execution time for Continuous Integration (CI) pipelines, and more efficient project onboarding and management. Furthermore, the integration of the proposed framework does not introduce major security threats to the current environment. / Under de senaste åren har företag och organisationer i allt högre grad integrerat testning av programvarusäkerhet i livscykeln för programvaruutveckling med hjälp av DevOps-metoder. Den nuvarande integrationsmetoden medför flera utmaningar i en informationsteknisk miljö som består av ett stort antal programvaruutvecklingsprojekt och flera verktyg för testning av programvarusäkerhet. Detta examensarbete syftar till att ta itu med dessa utmaningar genom att föreslå en mikrotjänstbaserat ramverk för enhetlig testning av programsäkerhet. I arbetet identifieras först utmaningarna och därefter föreslås en konstruktion baserad på relevant litteratur och gemensamma egenskaper hos verktyg för testning av applikationssäkerhet. De viktigaste komponenterna i det föreslagna ramverket implementeras och utvärderas. Utvärderingsresultatet visar att ramverket erbjuder många fördelar: säkrare process för hantering av autentiseringsuppgifter, kortare genomförandetid för Continuous Integration (CI)-pipelines och effektivare projektstart och -hantering. Dessutom medför integrationen av det föreslagna ramverket inga större säkerhetshot i den nuvarande miljön.

IT-projekt har misslyckats till hög grad under väldigt lång tid, studier visar på att uppemot 80% av alla IT-projekt anses vara misslyckade. Det har gjorts studier som visar på att agila metoder, såsom DevOps, kan vara lösningen till att fler IT-projekt ska lyckas. Syftet med denna studie är att bidra till förståelse för hur risker relaterade till IT-projekt har sett ut mellan 1990–2020, samt undersöka om metoder såsom DevOps är rätt väg att gå för att reducera misslyckade IT-projekt. I denna studie kartläggs de vanligaste orsakerna till misslyckade IT-projekt genom att kategorisera risker identifierade i forskning från 1990 till 2020. Detta görs och presenteras genom en litteraturstudie. Denna litteraturstudie resulterar i en överblick över hur litteraturen för de vanligaste riskerna sett ut över 30 år. Kartläggningen visar att tidigare studier mellan 1990 -2010 haft en bred spridning kring risker relaterade till IT-projekt bland samtliga kategorier. De senare åren, 2010–2020 har fokus i litteraturen legat mot lednings-, process samt personalrelaterade risker, något som även får stöd av respondenterna. Vi har även studerat DevOps och genomfört två semistrukturerade intervjuer med respondenter som har erfarenhet av DevOps, agila metoder och att driva IT-projekt. Resultatet av studien är tydligt, teori och empiri är väl överens om att agila metoder är rätt väg att gå. DevOps anses av respondenterna som en effektiv metod att använda för att nå fler lyckade IT-projekt. De två respondenterna verifierar även de riskkategorier som tagits fram i litteraturstudien och bekräftar att det är dessa som är aktuella i IT-projekt. / Literature shows that IT-projects have failed to a large extent for a long time, studies shows that up to 80 % of all IT-projects are considered as failed. There are studies that shows that agile methods, such as DevOps, can be the solution for more IT-project success. The purpose of this study is to contribute to an understanding of what risks related to IT projects that has been identified in literature between 1990-2020 and investigate if methods such as DevOps is the right way to reduce IT-project failure. This study maps all the most common causes to failed IT-projects by categorize the most frequent risks identified in research from 1990 to 2020 and is performed and presented by a literature study. This literature study results in an overview of the literature of the most frequent risks occurred in studies from the last 30 years. The overview identifies that studies between 1990 to 2020 has a range between risks related to IT-projects in all categories. In the most recent studies, from 2010- 2020, focus in research points to management-, process and personnel-related risks, which is also supported by the respondents. We have studied DevOps and completed two semi structured interviews with respondents that have experience of DevOps, agile methods and managing IT-projects. The result of this study is clear, the theory and empirics are aligned, agile methods are the right way to go. The respondents consider DevOps as an effective method to reach a higher success rate for IT-projects. The respondents verify the risk categories from the literature study and confirm these risks in their own IT-projects.

In traditional Software Development Life Cycle, medium and large organizations tend to divide the activities of Operations and Development into separate departments. These groups often have a troublesome relationship because of different incentives during the software delivery process. As a result, conflicts occur between development and operations personnel as they blame each other to be the cause of long lead times and inefficient software delivery processes. The concept of DevOps emerged trying to resolve the problem that arises when separating the work of Development and Operations into organizational silos. The term DevOps is a combination of the abbreviations of Development (Dev) and Operations (Ops). DevOps aim to create a coalition that spans between Development (software developers and quality assurance) and Operation (experts responsible to roll out software to production and managing the infrastructure, e.g. system, network and database administrators and technicians). The idea is to increase the speed of the software delivery process and to quickly solve critical issues, enable organizations to better serve their customers. DevOps means that development teams who previously were solely responsible for the development of their applications now have to manage and govern both development and operational responsibilities. Thus, the adoption of DevOps might introduce new type of challenges and implications for the traditional development teams. Current literature and research about DevOps focus mainly on the challenges that DevOps attempts to overcome. There is a lack of literature on the challenges that practitioners encounter during the adoption of DevOps. As more organizations and companies tend to adopt the concept of DevOps, it increases the need to understand potential challenges and effects of adopting DevOps. Therefore, the aim of this study is to investigate the challenges that development teams encounter during the adoption of DevOps. This research was conducted by an inductive research approach through a single qualitative case study, with the use of semi-structured interviews. In total, four main challenges and fourteen sub-challenges were identified in this study. The four main challenges identified was, lack of awareness, lack of support for DevOps, implementing DevOps technology and adapting organizational processes to DevOps. This study concludes that the adoption of DevOps has a profound impact on the role of a software developer, and that the traditional role of a software developer needs to be evolved. The research provides four recommendations and means to overcome the challenges identified in this research, establishing common ways of working and spreading the knowledge, building commitment and trust by smarter seating, allocate time and resources to transition and trying out with one team and one application. / I traditionell livscykel för mjukvaruutveckling tenderar medelstora och stora organisationer att dela upp verksamheten i drift och utveckling i separata avdelningar. Dessa grupper har ofta en besvärlig relation på grund av olika incitament under mjukvaruleveransprocessen. Som ett resultat uppstår konflikter mellan utvecklings- och driftpersonal eftersom de beskyller varandra för att vara orsaken till långa ledtider och ineffektiva mjukvaruleveransprocesser. Konceptet DevOps uppstod för att försöka lösa det problem som uppstår när man separerar utveckling och drift i organisationella silosar. Termen DevOps är en kombination av förkortningarna för utveckling (Dev) och drift (Ops). DevOps syftar till att skapa en koalition som sträcker sig mellan utveckling (mjukvaruutvecklare och kvalitetssäkring) och drift (system-, nätverks- och databasadministratörer och tekniker). Idén är att öka hastigheten av mjukvaruleveranser och att snabbt lösa kritiska problem för att förbättra organisationens förmåga att betjäna sina kunder. DevOps innebär att utvecklingsgrupper som tidigare enbart ansvarade för utvecklingen av sina applikationer nu även har driftansvar. Således kan antagandet av DevOps introducera nya typer av utmaningar och konsekvenser för de traditionella utvecklingsgrupperna. Aktuell litteratur och forskning kring DevOps fokuserar främst på de utmaningar som DevOps försöker övervinna. Därav finns det brist på litteratur kring de utmaningar som utövare stöter på under antagandet av DevOps. Eftersom fler organisationer och företag tenderar att adoptera begreppet DevOps ökar behovet av att förstå potentiella utmaningar och effekter av att anta DevOps. Därav är syftet med denna studie att undersöka de utmaningar som utvecklingsgrupper bemöter under antagandet av DevOps. Denna forskning utfördes genom en induktiv forskningsinriktning, en kvalitativ fallstudie och datainsamling genom halvstrukturerade intervjuer. Totalt identifierades fyra huvudutmaningar och fjorton sub utmaningar i denna studie. De fyra huvudsakliga utmaningar som identifierades var, brist på medvetenhet, brist på stöd för DevOps, implementering av DevOps-teknik och anpassning av organisationsprocesser till DevOps. Den här studien drar slutsatsen att antagandet av DevOps har en djupgående inverkan på rollen som en mjukvaruutvecklare och att den traditionella rollen som en mjukvaruutvecklare behöver utvecklas. Studien ger fyra rekommendationer och medel för att övervinna de utmaningar som identifierats, etablering av gemensamma sätt att arbeta och sprida kunskapen, bygga upp engagemang och förtroende genom smartare sittplatser, fördela tid och resurser till övergången samt prova med ett lag och en applikation.

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.