Implementing Continuous Integration in a Small Company: a Case Study

Implementing Continuous Integration in a Small Company: a Case Study

Aalto University School of Science Degree Programme in Computer Science and Engineering Kim Rejstr¨om Implementing Continuous Integration in a Small Company: A Case Study Master's Thesis Espoo, October 27, 2016 Supervisor: Professor Casper Lassenius Advisors: Maria Paasivaara Juuso Pesola Aalto University School of Science ABSTRACT OF Degree Programme in Computer Science and Engineering MASTER'S THESIS Author: Kim Rejstr¨om Title: Implementing Continuous Integration in a Small Company: A Case Study Date: October 27, 2016 Pages: vii + 100 Major: Software Engineering and Business Code: T-110 Supervisor: Professor Casper Lassenius Advisors: Maria Paasivaara Juuso Pesola Release engineering is the process responsible for taking individual code contribu- tions of developers and bringing those to the end user in the form of high quality software releases. This process encompasses code change integration, build sys- tem specifications, infrastructure-as-code, deployment and release. Organizations have started automating various parts of their release pipelines resulting in the practices of continuous integration (CI), continuous delivery (CD), continuous deployment, DevOps and continuous value delivery. The goal of this thesis is to produce an updated release pipeline for the case company and evaluate the proposed solution from a CI/CD perspective. This is done through design science research, where an artifact (the new release pipeline) is constructed based on a series of feasibility studies aimed at finding an optimal solution to the elicited needs of the company. The study implemented a modern, automated release pipeline that solved the problems targeted. The solution includes many of the typical methods and tools documented in existing research: automated builds, test automation, configu- ration management and automated deployments. The CI/CD adoption was not without problems, as challenges related to resource allocation, security and QA ef- forts emerged. The transition was however successful and as a result of the imple- mentation, perceived benefits included improved release planning, infrastructure- as-code and close tie-ins with the DevOps culture. Keywords: Continuous Integration, Continuous Delivery, Single Case Study, Release Pipeline, DevOps, Design Science Research, CI assimilation Language: English ii Aalto-universitetet H¨ogskolan f¨or teknikvetenskaper SAMMANDRAG AV Examensprogram f¨or datateknik DIPLOMARBETET Utf¨ort av: Kim Rejstr¨om Arbetets namn: Implementering av Kontinuerlig Integration i ett litet f¨oretag: En fallstudie Datum: Den 27 Oktober 2016 Sidantal: vii + 100 Huvud¨amne: Programvaruutveckling och Kod: T-110 aff¨arsverksamhet Overvakare:¨ Professor Casper Lassenius Handledare: Maria Paasivaara Juuso Pesola Publiceringsutveckling ¨ar processen ansvaring f¨or att individuella kod bidrag fr˚an programvaruutvecklarna levereras till slutanv¨andarna i form av h¨ogkvalitatets- programvara. Denna process omfattar integration av kod, specifikationer f¨or build-system, infrastruktur-som-kod samt distribution och publicering av pro- gramvara. Organisationer har b¨orjat automatisera olika delar av sina publice- ringslinjer, n˚agotsom resulterat i inf¨orandet av kontinuerlig integration (CI), kontinuerlig leverans (CD), kontinuerlig publicering, DevOps och kontinuerlig v¨arde leverans. M˚aletmed denna avhandling ¨ar att producera en uppdaterad publiceringsline f¨or fallstudie f¨oretaget och utv¨ardera den f¨oreslagna l¨osningen fr˚anett CI / CD perspektiv. Studien g¨ors som design science forskning, dvs. en artefakt (den nya publiceringlinjen) konstrueras p˚abasen av ett antal f¨orstudier ¨amnade f¨or att finna en optimal l¨osning p˚af¨oretagets problem. I studien implementerades en modern, automatiserad publiceringslinje som l¨oste problemen den addresserade. L¨osningen inneh˚allerm˚angaav de typiska metoder och verktyg dokumenterade i befintlig forskning: automatiserade build-system, testautomatisering, konfigurationshantering samt automatiserade installationer. CI/CD ¨overg˚angenvar dock inte problemfri { utmaningar relaterade till resursal- lokering, s¨akerhet och QA insatser uppstod p˚av¨agen. Overg˚angenvar¨ trots detta lyckad och som f¨oljder av ett framg˚angsriktgenomf¨orande uppstod f¨orb¨attrad publiceringsplanering, infrastruktur-som-kod samt n¨ara band till DevOps kultu- ren. Nyckelord: Kontinuerlig Integration, Kontinuerlig Leverans, Fallstudie, Publiceringslinje, DevOps, Design Science Forskning, CI assi- milation Spr˚ak: Engelska iii Acknowledgements I want to express the deepest of gratitude to my fellow colleagues at The Button Corporation for supporting this endeavor from day one. I also want to thank my professor Casper Lassenius together with Maria Paasivaara for guiding me throughout the process. A big thank you goes to Juuso Pesola for all the time he devoted to this project as well. Espoo, October 27, 2016 Kim Rejstr¨om iv Abbreviations and Acronyms CI Continuous Integration CD Continuous Delivery CSA Current State Analysis CN Company Needs VCS Version Control System DSR Design Science Research v Contents Abbreviations and Acronyms v 1 Introduction 1 1.1 Problem statement . .2 1.2 Structure of the Thesis . .2 2 Background 4 2.1 Characteristics of Continuous Integration and Delivery . .5 2.2 Practices of successful CI/CD . 10 2.3 Challenges in adopting CI/CD . 13 2.4 Proposed benefits in adopting CI/CD . 15 2.5 Organizational implications of CI assimilation . 16 2.6 SMB experience reports . 18 2.7 Integration flow model . 20 3 Research Method 22 3.1 Research Motivation . 22 3.2 Design science research . 23 3.3 Data Collection . 24 3.4 Research Phases . 26 3.5 Environment . 26 4 Current State Analysis 30 4.1 Requirements . 31 4.2 Development . 33 4.3 Operations . 35 4.4 Testing . 36 4.5 Quality . 37 4.6 Original Release pipeline . 38 4.7 Company Needs . 41 vi 5 Solution Proposals 47 5.1 Feasibility study: Core tool-chain . 47 5.2 Solution: Tool-chain 3 { The Gitlab Suite . 50 5.3 Feasibility study: Code quality . 55 5.4 Solution: Full-stack code health checker for bt.tn application suite . 57 5.5 Threats to successful implementation . 58 6 Implementation 62 6.1 Architecture . 62 6.2 Integration Flow Model . 65 6.3 Implementation problems . 67 7 Evaluation 70 7.1 Removing the bottlenecks . 70 7.2 Automating the pipeline . 74 7.3 Evaluating the pipeline . 77 8 Discussion 82 8.1 The ideal solution . 82 8.2 Answers to the research questions . 86 8.3 Threats to validity . 90 8.4 Future research . 93 9 Conclusions 95 vii Chapter 1 Introduction Software engineering is about the creation and delivery of value to its in- tended customers and users. During the past two decades the software de- velopment practices have transitioned from document-driven, rigid waterfall models to lean and agile development practices. These development practices have introduced a new way of looking at value delivery. Value is defined by the users, which means getting useful feedback on whether or not the soft- ware under development satisfies the actual requirements of a the users is the only way to know if the right thing is being developed. Reducing the time it takes to develop new features, thus shortening the feedback loop between developers and users, decreases the risk of developing the wrong product. Release engineering is the process responsible for taking the individual code contributions of developers and bringing those to the end user in the form of a high quality software release [Adams and McIntosh, 2016]. This process encompasses code change integration, continuous integration, build system specifications, infrastructure-as-code, deployment and release. Or- ganizations have started automating various parts of their release pipelines [St˚ahland Bosch, 2014b] resulting in the practices of continuous integration (CI), continuous delivery (CD), continuous deployment and continuous value delivery [Dingsøyr and Lassenius, 2016]. CI is a software development practice where software is integrated contin- uously during development. All the code that is produced must be checked in to a version control system, integrated and built into executables which are then automatically tested [Fowler and Foemmel, 2006]. CD is an extension of CI in the sense that all CI practices are fully included in the CD process as shown in Figure 2.1. CD is defined as a software development practice in which software can be released to production at any time [Fowler, 2013]. This means the CD pipeline not only integrates and tests the code, but moves the executables to production-like environments for acceptance and release 1 CHAPTER 1. INTRODUCTION 2 testing. Continuous deployment further automates CD as no manual action is needed to deploy the product increment.[Fowler, 2013] 1.1 Problem statement Prior to this study, the company has identified and need to improve its de- velopment process. They have decided to adopt agile software development methods within the company. Implementing a CI system was seen as the fundamental first step needed to start a transition towards more agile prac- tices overall within the company. Thus, the problem this thesis aims to solve is how to improve the release pipeline of The Button Corporation. This is performed as design science research, where in addition to evaluating the current state of the company's release pipeline a CI/CD tool-chain will be implemented and introduced into their release pipeline. The thesis intends to address this problem by answering the following research questions: RQ1 What are the motivation

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    107 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us