Software Development Environment - the Devops Perspective

Software Development Environment - the Devops Perspective

Bachelor Degree Project Software Development Environment - the DevOps perspective Author: Olga Christensen ​ Supervisor: Daniel Toll ​ Semester. VT 2020 ​ Subject: Computer Science ​ Abstract DevOps is a collaborative effort based on a set of practices and cultural values developed in order to improve software quality and release cycle while operating at the lowest cost possible. To enable DevOps principles such as automation, collaboration, and knowledge sharing, Continuous Delivery and Deployment, as well as Infrastructure as Code are heavily employed throughout the whole process of software development. One of the main building blocks of this process is a development environment where the application code is being developed and tested before it is released into production. This research investigates with the help of a systematic literature review the DevOps perspective regarding provisioning and deployment of a development environment in a controlled, automated way, specifically the benefits and challenges of this process. Keywords: development environment automation, DevOps, Infrastructure as ​ Code, Configuration management Contents 1 Introduction 4 1.1 Background 5 1.2 Related work 6 1.3 Problem formulation 7 1.4 Motivation 7 1.5 Objectives 8 1.6 Scope/Limitation 8 1.7 Target group 8 1.8 Outline 8 2 Method 10 2.1 Search strategy 10 2.2 Study selection 11 2.3 Data extraction and synthesis 12 2.4 Reliability and Validity 12 2.5 Ethical considerations 13 3 Results 14 4 Analysis 17 4.1 Benefits of provisioning a development environment automatically (RQ1) 17 4.1.1 Consistent environments entail speed, quality, collaboration 17 4.1.2 Low maintenance environments 18 4.1.3 Traceability 19 4.1.4 Reusability 19 4.1.5 Distributed development 19 4.1.6 Cost management 20 4.1.7 Virtualisation 20 4.1.8 Other applications 20 4.2 Challenges of the automatic provisioning of a development environment (RQ2) 20 4.2.1 Learning curve 21 4.2.2 Tools 21 4.2.3 Security 22 4.3 Tools for development environment automation (RQ3) 22 4.3.1 Version Control 23 4.3.2 Build and packaging tools 23 4.3.3 Configuration management tools 23 4.3.4 Virtualisation 23 4.3.5 Web-based IDE 24 4.3.6 Cloud computing 24 4.3.7 Prototypes 24 4.4 Summary 25 5 Discussion 26 6 Conclusion 28 6.1 Future work 28 References 29 Appendix 1 34 1 Introduction At the core of any software development project, you will find a developer and his workstation, where the code is being written, tested and compiled before it is eventually released through a number of stages to the end-user. This workstation has to be set up before the development process can begin, which takes time and effort - numerous tools and applications need to be installed and configured. Additionally, this process has to be repeated for each new member of a software development project, or whenever a developer has to move to a different workstation, or reinstall the setup for some other reasons. This project looks into how DevOps practices, specifically automation, collaboration, and knowledge sharing, can be applied to the configuration of development environments in order to increase the productivity of software developers and consequently improve the quality of produced software. 1.1 Background Today the process of software engineering is quite dynamic and complex: projects are driven by agile principles, development teams are often distributed geographically, source code is updated on a daily basis and involves different programming languages, tools, external libraries, databases, mail servers, etc. [1], [2]. In the days of high demands and constant change, there is one major problem when it comes to software development: how to cut the time from the creation of an idea to the delivery of the end product to the customer without the loss of its quality [3]. As a solution to this problem, a DevOps movement was coined which produced a ​ set of principles and practices that would enforce collaboration between software development, operations and quality assurance teams [3], [4]. DevOps incorporates agile principles by means of continuous feedback and quick response to changes, with the main focus on communication, collaboration and automation [4]. To enable DevOps and to make the process of software development as effective as possible, the principles and practices of continuous delivery ​ should be adopted, which focus on making the process of building, deploying, testing and releasing the software rapid and fully automated [3]. From a technical point of view, this is implemented through an automated continuous delivery pipeline which helps to significantly shorten release cycles without quality degradation. Diverse application environments (development, test, production, etc.) form the key building blocks of a continuous delivery pipeline [3]. Continuous delivery heavily depends on configuration management, ​ ​ which concentrates on the ability to repeatedly recreate any fragment of application infrastructure [3]. The other practices that build the foundation of continuous delivery are continuous integration, continuous testing and ​ ​ continuous deployment, often gathered together under the term continuous ​ ​ practices [3], [5]. To derive maximum benefit of continuous practices the IT ​ infrastructure has to be fully automated and treated as it was software and data, i.e. with Infrastructure as Code approach [6]. ​ ​ As a part of continuous practices, according to J. Humble [3] "It is important for developers’ productivity and sanity that their development environment is carefully managed", and that the company saves "lots of work of individual developers" by sharing deployment scripts among team members. However, often development teams are distributed geographically and starting on a new project, or simply moving your local development environment to a new machine can be time-consuming and frustrating [7]. The results produced with a manual development setup can be unpredictable, working exclusively within that particular environment [6], [8]. Moreover, in some scenarios the application runtime environment is OS-specific making the development setup even more tedious, as with the development of applications built in ASP.NET Framework, which can be run and compiled only on Windows OS [9]. The above-mentioned statements are supported by the vast amount of web search results on the topic of automation of a local development environment setup, which include questions, ideas and expertise, as well as white papers and how-tos. Additionally, according to the ActiveState's Developer Survey from 2019, over 50% of respondents ranked the importance of "ease of sharing an environment configuration" as "important" or "very important". And over 40% of respondents saw the task of "dev environment deployment/isolation" as a challenging one [10]. While performing preliminary research on the principles and patterns of continuous delivery and the practices of configuration management, one thing became apparent - within the academic literature, the focus lies on provisioning different deployment environments and the actual deployment process, which always starts with a developer committing new changes to a Version Control system (VCS) [3]. But there seems to be a lack of academic literature that focuses on the automation of software developer's daily tasks before "pushing" updates to VCS. In particular, how does one set up and run a local development environment and what part its manual vs. automated deployment plays in DevOps and continuous practices? 1.2 Related work The main work found in the field of this thesis is a book Continuous Delivery ​ by Jez Humble and David Farley [3]. There the authors address the issues connected to rapid releases of the software and how continuous practices are meant to solve them. The main focus of this book lies in the configuration of the deployment pipeline and addresses the developer's own workstation only marginally. The authors recommend using configuration management in order to be "able to repeatably re-create every piece of infrastructure used by your application", but focus on automation of production and test environments, mentioning only once that "It is even helpful to keep the configuration files for the development team’s development environments in version control since it makes it easy for everyone on the team to use the same settings". There is no discussion regarding which issues would be addressed and solved with this approach. An article Improving the delivery cycle: A multiple-case study of the ​ toolchains in Finnish software intensive enterprises by Mäkinen et al. [11] is dedicated to examining different tools that are used for rapid software delivery. This multiple case study to some extent addresses the role of local development setup in a bigger picture of continuous delivery, the developers' attitude to the issue, and some tools that could be used for automating the development environment. The main idea behind the automation of a development environment is to make development and production environments compatible and to a large extent identical by using Vagrant virtualisation tools in combination with configuration management tools, such as Chef, Puppet, and Ansible. No other reasons or tools for automation are mentioned, neither the topic of why it is important to have environments compatible is discussed. Information about the tools that are suitable for local environment automation is available in multiple blog posts and guides, such as an online blog Repeatable

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    36 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