Cloud computing enables on-demand access to a shared pool of computing resources, that can beeasily provisioned, configured and released with minimal management cost and effort. OpenStack isan open source cloud management platform aimed at providing private or public IaaS cloud onstandard hardware. Since, deploying OpenStack manually is tedious and time-consuming, there are several tools that automate the deployment of OpenStack. Usually, cloud admins choose a tool basedon its level of automation, ease of use or interoperability with existing tools used by them. However,another desired factor while choosing a deployment tool is its deployment speed. Cloud admins cannot select based on this factor since, there is no previous work on the comparison of deploymenttools based on deployment time. This thesis aims to address this issue. The main aim of the thesis is to evaluate the performance of OpenStack deployment tools with respectto operating system provisioning and OpenStack deployment time, on physical servers. Furthermore,the effect of varying number of nodes, OpenStack architecture deployed and resources (cores andRAM) provided to deployment node on provisioning and deployment times, is also analyzed. Also,the tools classified based on stages of deployment and method of deploying OpenStack services. In this thesis we evaluate the performance of MAAS, Foreman, Mirantis Fuel and Canonical Autopilot. The performance of the tools is measured via experimental research method. Operating system provisioning time and OpenStack deployment times are measured while varying the number of nodes/OpenStack architecture and resources provided to deployment node i.e. cores and RAM. Results show that provisioning time of MAAS is less than Mirantis Fuel, which is less than Foreman.Furthermore, for all 3 tools as number of nodes increases provisioning time increases. However, the amount of increase is lowest for MAAS than Mirantis Fuel and Foreman. Similarly, results for baremetal OpenStack deployment time show that, Canonical Autopilot outperforms Mirantis Fuel by asignificant difference for all OpenStack scenarios considered. Furthermore, as number of nodes in an OpenStack scenario increases, the deployment time for both the tools increases. From the research, it is concluded that MAAS and Canonical Autopilot perform better as provisioningand bare metal OpenStack deployment tool respectively, than other tools that have been analyzed.Furthermore, from the analysis it can be concluded that increase in number of nodes/ OpenStackarchitecture, leads to an increase in both provisioning time and OpenStack deployment time for all the tools.

DevOps es un enfoque cada vez más común para la entrega de software. En este webinar se explicará cuáles son los beneficios de aplicar DevOps para que los equipos de desarrollo y operaciones puedan para crear, probar, implementar y monitorear aplicaciones con velocidad, calidad y control.

Inom projektledning har olika metoder och agila arbetssätt utvecklas. Det har dock funnits frustration över separerande silostrukturer inom mjukvaruutveckling. DevOps har utvecklats som ett sätt att bemöta detta och istället sammankoppla olika funktioner som utveckling och operations. DevOps har effekter på ett team men det finns inget standardiserat tillvägagångssätt för dess implementering. Det behövs därför mer forskning kring implementeringsprocessen av DevOps. Det kan även vara av intresse att undersöka vilka de medföljande effekterna kan vara. Syftet med detta arbete är studera genomförandet av DevOps implementering inom IT-konsultbranschen och på vilket sätt det påverkar ett team. Det här arbetet har bedrivits som en abduktiv studie där en fallstudie genomförts. För att uppfylla arbetets syfte och besvara forskningsfrågorna har litteraturstudier och intervjuer genomförts. Insamlad teori och empiri har diskuterats och analyserats för att formulera slutsatser och rekommendationer.  En formulerad slutsats är att varje enskild implementering av DevOps behöver följa ett eget anpassat genomförande där syfte och innebörd tydliggörs. Faktorer inom kommunikation, automation, ansvar, förändringsvillighet och samarbete har också inverkan på implementeringen och de effekter teamet kan uppleva. Det kan även konkluderas att både fördelar och nackdelar kan påverka teamet men nackdelarna framstår ofta vara begränsade till implementeringens uppstart. Det praktiska bidraget utgörs av rekommendationer för implementeringen såsom att till exempel ha en dedikerad person och utbildning inom DevOps. / Within the field of project management different methods and agile approaches have emerged. However, dividing silo-structures have created frustration within software development. DevOps has surfaced as a way to address this and instead connect different functions such as development and operations. DevOps affects teams but there is no standardized approach for its implementation. Therefore, more research around the implementation process of DevOps is needed. Also, investigating what the accompanying effects could be, is of interest. The purpose of this thesis is to study the implementation of DevOps within the IT consultant industry and what impact it has on a team. This thesis was executed with abductive reasoning where a case study was carried out. To fulfill the purpose and answer the research questions literature review and interviews have been performed. Collected theory and empirical material have been discussed and analyzed in order to formulate conclusions and recommendations.  One formulated conclusion is that each implementation of DevOps needs to follow its own adapted execution where the aim and essence are clarified. Factors regarding communication, automation, responsibility, willingness to change and collaboration also impact the implementation and the effects experienced by the team. It can also be concluded that both benefits and limitations can affect the team yet, the disadvantages often appear to be contained within the start of the implementation. A practical contribution comes from recommendations for the implementation, such as having a dedicated person and education within DevOps among others.

Att använda sig utav automatiserade processer blir allt viktigare då företag alltid strävar efter att vara så effektiva som möjligt och för att kunna mäta sig med varandra. I den här rapporten har Microsoft verktyg Azure DevOps studerats och hur ett konsultföretag i Linköping kan dra nytta av automatiserade processer på bästa möjliga sätt. Målet var att ge företaget en bredare synvinkel på hur verktyget kan användas i framtida projekt för att maximera chanserna till en mer lönsam utvecklingsprocess än de har i dagsläget. För att mäta resultatet och framgångsfaktorn har olika kriterier kopplat till mjukvaruutveckling analyserats och jämförts med utvecklingsmetoder som kräver mer manuella handlingar. Resultatet visar på hur företaget praktiskt bör använda Azure DevOps och dess pipeline för att underlätta utvecklingen och lanseringen till olika miljöer.

Information system development projecs are often considered a costly and uncertain process were projects often exceed the scheduled time and budget. By continuously integrating source code and do regular builds problems can be discovered almost directly and thus minimizing the cost to fix them. In this qualitative study we have focused on which challenges a large public organization who cooperate with an external provider can face when adopting continuous integration and continuous delivery. We have interviewed six employees within the organisation and two employees from the external provider, who are all in some way connected to the software development process. The results showed that our interviewees are interested in agile software development and to be able to deliver high quality software continuously. We also found that the software development process is complex and has a lot of barriers and handovers that slows the process down. Our conclusion is that the organization needs to change their approach to software development. To achieve this the organisation needs to adopt Devops, which means erasing the barriers between development and operations.

Det ställs högra krav på små till medelstora IT-företag vad gäller arbetsprocesser och tillämpning av agil arbetsmetod. Syftet med denna studie är att undersöka användningen av DevOps-tjänsterna Jira och Azure DevOps vid tillämpning av agila arbetsmetoder i små till medelstora IT-företag enligt företagens egna erfarenheter och upplevelser. Intervjuer har gjorts med två IT-företag som tillämpar en agil arbetsprocess tillsammans med DevOps-tjänsterna Jira respektive Azure DevOps. Slutsatserna är att DevOps-tjänsterna bidrar med struktur, översikt, diagnostik och är bidragande vid kommunikation. Båda IT-företagen själva säger att de rekommenderar sin respektive DevOps-tjänst och det finns många sätt som tjänsterna kan bidra till den agila processen på.

Cloud computing allows access to a collection of computing resources that can be easily provisioned, configured as well as released on-demand with minimum cost and effort. OpenStack is an open source cloud management platform aimed at providing public or private IaaS cloud on standard hardware. Since, deploying OpenStack manually is tedious and time-consuming, several tools that automate the deployment of OpenStack are available. Usually, cloud administrators choose a tool based on its level of automation, ease of use or interoperability with existing tools used by them. However, another desired factor while choosing a deployment tool is its deployment speed. Cloud admins cannot select based on this factor since, there is no previous work done on the comparison of deployment tools based on deployment time. This thesis aims to address this issue. The main aim of the thesis is to evaluate the performance of OpenStack deployment tools with respect to operating system provisioning and OpenStack deployment time, on physical servers. Furthermore, the effect of varying number of nodes, OpenStack architecture deployed and resources (cores and RAM) provided to deployment node on provisioning and deployment times, is also analyzed. Also, the tools are classified based on stages of deployment and method of deploying OpenStack services. In this thesis we evaluate the performance of MAAS, Foreman, Mirantis Fuel and Canonical Autopilot. The performance of the tools is measured via experimental research method. Operating system provisioning time and OpenStack deployment times are measured while varying the number of nodes/ OpenStack architecture and resources provided to deployment node i.e. cores and RAM. Results show that provisioning time of MAAS is less than Mirantis Fuel which is less than Foreman for all node scenarios and resources cases considered. Furthermore, for all 3 tools as number of nodes increases provisioning time increases. However, the amount of increase is lowest for MAAS than Mirantis Fuel and Foreman. Similarly, results for bare metal OpenStack deployment time show that, Canonical Autopilot outperforms Mirantis Fuel by a significant difference for all OpenStack scenarios and resources cases considered. Furthermore, as number of nodes in an OpenStack scenario as well as its complexity increases, the deployment time for both the tools increases. From the research, it is concluded that MAAS and Canonical Autopilot perform better as provisioning and bare metal OpenStack deployment tool respectively, than other tools that have been analyzed. Furthermore, from the analysis it can be concluded that increase in number of nodes/ OpenStack architecture, leads to an increase in both provisioning time and OpenStack deployment time for all the tools. Finally, after analyzing the results the tools are classified based on the method of deploying OpenStack services i.e. parallel or role-wise parallel.

Introduction : DevOps bridges the gap between the development and operations by improving the collaboration while automating the as many as steps from developing the software to releasing the product to the customers. To automate the software development activities, DevOps relies on the tools. There are many challenges associated with the tool implementation such as choosing the suitable tools and integrating tools with existed tools and practices. There must be a clear understanding on what kind of tools are used by the DevOps practitioners and what challenges does each tool create for them. Objectives: The main aim of our study is to investigate the challenges faced by the DevOps practitioners related to the tools and compare the findings with the related literature. Our contributions are (i) a comprehensive set of tools used by Developers and Operators in the software industries; (ii) challenges related to tools faced by the practitioners; and (iii) suggested recommendations and its effectiveness to mitigate the above challenges. Methods: we adopted case study for our study to achieve our research objectives. We have chosen literature review and semi-structured interviews as our data collection methods. Results: In our study we identified seven tools used by developers and operators which were not reported in the literature such as Intellij, Neo4j, and Postman. We identified tool related challenges from the practitioners such as difficulty in choosing the suitable tools, lack of maturity in tools such as Git, and learning new tools. We also identified recommendations for addressing tool related challenges such as Tech-Talks and seminars using complementary tools to overcome the limitations of other tools. We also identified benefits related to the adoption of such recommendations. Conclusion: We expect the DevOps tool landscape to change as old tools either become more sophisticated or outdated and new tools are being developed to better support DevOps and more easily integrate with deployment pipeline. With regard to tool related challenges literature review as well as interviews show that there is a lack of knowledge on how to select appropriate tools and the time it takes to learn the DevOps practices are common challenges. Regarding suggested recommendations, the most feasible one appears to be seminars and knowledge sharing events which educate practitioners how to use better tools and how to possible identify suitable tools.

Background: Due to the complexity involved in robotic software development, the progress in the field has been slow. Component-based software engineering was observed to have a strong influence on the improvement of the robotic software development process and its adoption achieved good results. DevOps was seen to be compatible and produced efficient results in software engineering. Objectives: The aim of this thesis work is to present the potential usage of DevOps practices in robotic software development. 15 DevOps practices were selected from prior research from software engineering and mapped to the robotic software development process and checked for success in terms of applicability and effectiveness. Methods: By performing a research synthesis of the literature, the usage of DevOps practices in robotic software development is proposed and presented. Interview based survey was performed by approaching industry experts on robotic software development to get their response on the results of the research synthesis. Results: The applicability of the DevOps practices in robotic software development is presented and the implications of the potential usage of the practices in the proposed manner are discussed. The potential advantages and limitations of the proposed mapping are discussed and presented. Conclusions: DevOps, like other software development frameworks, has various observable advantages when applied in robotic software development. The interviews confirmed the need for DevOps to be adapted into robotic software development and the benefits it has.

Tesis para optar al grado de Magíster en Tecnologías de la Información / Previred S.A, empresa de servicios de información, cuenta con una división de negocios denominada Apoyo al Giro que presta servicios para la industria previsional y de seguridad social nacional. Esta división cuenta con un equipo de desarrollo de software dedicado que construye la mayor parte de los sistemas de información que apoyan las labores de apoyo al giro. El nivel de demanda y exigencia por estos servicios ha aumentado, al punto que gran parte de ellos son considerados críticos por los clientes de Previred. Esto compromete a la organización a cumplir altos niveles de servicios y a garantizar la continuidad operativa de los mismos. Actualmente el proceso de implantación de nuevas versiones de los sistemas se realiza mediante procesos manuales, con una tasa de fallos considerada insatisfactoria por los clientes internos y externos. Por otro lado, se ha establecido una métrica sobre la tasa de fallos críticos, cuyo valor se espera disminuir. Un fallo crítico corresponde a una indisponibilidad del servicio productivo por varias horas o incluso días. Una parte de estos fallos se debe a errores en el proceso de implantación en producción, por mala ejecución de las instrucciones, falta de prolijidad en la instalación, o en la elaboración de los documentos que describen los pasos a producción. El objetivo general de este trabajo de tesis es ajustar el proceso de desarrollo mediante la implantación de los procesos automatizados de integración y entrega continua, incorporando procesos y herramientas de DevOps dentro de la organización, con el fin de reducir la tasa de fallos críticos debidos al proceso actual. Esto es aplicado en un piloto de un nuevo servicio productivo de Previred. Para alcanzar el objetivo planteado primero se revisa el actual proceso de desarrollo de Previred, y luego se determinan los principales problemas y dolores que experimenta la organización con este proceso, mediante entrevistas a personas claves de la organización. En base a los antecedentes recogidos se proponen modificaciones al proceso de desarrollo, junto con una plataforma tecnológica que apoya estos cambios. Para plasmar esta plataforma, se propone una arquitectura de referencia y para construirla se analizan las herramientas disponibles y se seleccionan las adecuadas para la cultura y realidad de Previred. Para verificar la factibilidad de la arquitectura se realizó primero una prueba de concepto, y luego se validó la plataforma mediante un piloto aplicado a un proyecto de desarrollo de un nuevo servicio. Además, se realizó una evaluación cualitativa de la solución a través de una encuesta a un grupo de personas clave en la organización y a los participantes en el piloto. Por último, se relevaron las mejoras obtenidas en el proceso mediante la obtención de algunas métricas del proceso.