Software Development Environment: the DevOps perspective

(1)

Bachelor Degree Project

Software Development Environment

- the DevOps perspective

Author: Olga Christensen Supervisor: Daniel Toll

(2)

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

(3)

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

(6)

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

(7)

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 & Maintainable Development Environments by Andy Macdonald [7], where the author focuses on the practical side of the topic in a form of a tutorial. Vagrant and Ansible are used for automated deployment of development environments, but there is no explanation behind the choice of the tools or what other methods could be used.

All above-mentioned sources address a local development environment without depth and put the main focus on either the process of software deployment to production while utilising a deployment pipeline, or a rather small set of automation tools. However, it remains unclear why the automation of a development environment provisioning and deployment is not studied more extensively. Perhaps it is simply not feasible, and the challenges of automation outweigh its benefits, or the tools available for automation are not efficient or lacking in some other aspect.

1.3 Problem formulation

The objective of this project is to investigate and summarise available approaches for managing developers' local development environment efficiently from a DevOps perspective:

RQ1: What are the benefits regarding provisioning a development environment automatically compared to manually?

RQ2: What are the potential challenges associated with automatic provisioning of a development environment?

RQ3: Which tools are available for development environment automation?

1.4 Motivation

The DevOps approach to the software development process focuses on a high degree of automation in order to be able to produce results faster while

(8)

minimising errors. The concepts of test automation and application deployment as part of DevOps culture have been studied extensively. At the same time the subject of automating the development environment, the cornerstone of the development process, seems to be neglected and underresearched. The research carried out in this thesis would allow us to fill that gap and possibly identify topics for future research that could potentially improve the software development process even further.

1.5 Objectives

The objectives of this thesis are listed in Table 1.1.

O1 Gather available information regarding development environment configuration from a DevOps perspective.

O2 Establish which benefits and challenges are associated with automated development environment configuration.

O3 Analyse results in regard to defined research questions.

O4 Identify topics for future research.

Table 1.1: List of thesis objectives.

1.6 Scope/Limitation

The literature review is limited by a set of search words, information sources, publication date range, language and the sample size to find the most relevant publications on this topic. Additionally, the selection of the articles that are included in the research is carried out by a single person, which increases the chances of bias. It is plausible that some important publications would be omitted due to these limitations, but the time frame of the project and resource limitations would not allow the research to go any deeper.

Moreover, the lack of previous research might decrease the quality of the results presented in this report, but on the other hand, this would allow us to identify the gaps within existing literature and propose topics for future studies.

1.7 Target group

The findings of this project will be interesting to most actors/stakeholders within the software development process who follow DevOps principles, such as project managers, team leaders, quality assurance, testers, and developers since the results of this thesis would be able to aid in increasing developers' productivity, as well as the quality of the end product.

The results might also provide value to researchers of DevOps software development methodology by identifying trends and gaps in existing research.

1.8 Outline

The following chapter 2 addresses the method of this thesis, its strategy and execution. Reliability and validity of the method are discussed there as well.

(9)

Chapter 3 presents the results of the systematic literature review performed as a part of this research. In chapter 4 analysis of the results from the literature review are presented in the form of answers to research questions. Chapter 5 addresses the relevance of the research and how well were the research questions answered. The final chapter 6 reflects the conducted research and proposes the direction for future research.

(10)

2 Method

To establish current trends and gaps within the existing research regarding development environment from the DevOps perspective and to find the answers to questions defined in chapter 1.3, a systematic literature review (SLR) was selected as an appropriate method since it allowed to evaluate and interpret data from published research according to defined questions in an unbiased manner. The SLR was carried out according to the guidelines defined by Kitchenham [12] and executed in three phases: planning, conducting and reporting. The stages of each phase are denoted in Figure 2.1.

The stages of the Planning phase were addressed in the Introduction chapter of this report. The rest of the current chapter focuses on the second phase of the research - conducting the review. The reporting phase is documented in the next chapter - Results.

Figure 2.1: Phases of systematic literature review

2.1 Search strategy

The main objective of the SLR was to find as many relevant studies as possible about practices and approaches regarding management and automation of a development environment. For this purpose, a search strategy was defined.

Due to strict time and resource constraints the research was limited to resources available online and free of charge, specifically Google Scholar [13] was used for search execution and Linnaeus University OneSearch library [14] was used for proxy access to resources that otherwise required subscription. Only publications written in English with available full-text were included in the search.

Since the rise of the DevOps movement is dated to 2008 [15], the publication date of articles was set to minimum 2005, to make sure that research that could have potentially influenced the emergence of DevOps was also included in this study.

A narrow search for keywords "DevOps" and "development environment" in either title, keywords or abstract gave a single relevant result. Therefore the search strategy was expanded. Based on the findings in

(11)

chapters 1.1 and 1.2, the search terms used for the extraction of the articles were defined as follows:

- "configuration management" OR - "continuous delivery" OR

- "DevOps" OR - "automation"

Additionally, it was decided to include the following terms to exclude any publications that were not connected to computer science:

- "software" OR

- "software development"

Furthermore, since the research main focus was the development environment specifically, a final query term was added:

- "development environment"

The final search string: '("configuration management" OR

"continuous delivery" OR "DevOps" OR "automation") AND ("software" OR

"software development") AND "development environment"'.

The Google Scholar search with the final search string was performed on the 4th of April 2020 and gave over 17.000 results. To extend the term-based search, a forward snowballing technique [16] was used on the retrieved secondary studies. Moreover, the publications that were already mentioned in chapter 1.2 were also included in the research.

2.2 Study selection

The study selection was divided into several stages, during each one of them irrelevant search results were excluded, based on the publication's relevance to the research questions. The stages of study selection were the following:

1. The sorting of results was done by relevance and the number of publications for further review was set to 200.

2. Each article was examined by its title and keywords, and all publications that clearly didn't match the research subject were excluded.

3. The abstract, introduction and conclusion of the remaining publications were evaluated and irrelevant publications were removed from the set.

4. If the publication was still deemed relevant, a quick search was performed for the term "development environment", to see in which context it was used.

5. The whole publication was examined and evaluated.

The inclusion criteria were the following:

- Benefits of development environment automation are addressed;

- Issues with manual provisioning of development environments are addressed;

- Challenges of automatic provisioning are addressed;

- Tools for the automatic provisioning of development environments are addressed.

The exclusion criteria for study selection:

- The publication is not a primary study;

- Full text of the publication is not available free of charge;

- The publication is not written in English.

(12)

2.3 Data extraction and synthesis

A form for data extraction was designed according to [12] in order to gather the information needed to answer the research questions. The form for data extraction is presented in Table 2.1.

Field Value

Title Title of publication

Year Publication year

Publication type Article / Conference paper / Thesis Peer reviewed true/false

Keywords Defined by the author(s)

Type of research E.g. Case study, Survey, Experiment Benefits Benefits of automatic dev env provisioning Challenges Challenges of automatic dev env provisioning Tools Available tools for automatic provisioning

Authors Author(s)

Table 2.1: Data extraction form.

2.4 Reliability and Validity

Given the earlier outlined strategy for the literature review, it should be possible to produce the same results as described in this report. However, the study selection steps have less strict rules and are used more like guidelines, thus when repeated the results might differ.

Since the study selection was performed by a single researcher, it is possible that some bias was introduced. In an attempt to mitigate it, five publications from the final selection set were chosen randomly and re-evaluated by the researcher, following the same study selection procedure as described in chapter 2.2. All five publications were deemed relevant for the research, thus the consistency with the initial selection results was confirmed [12].

Moreover, due to the project limitations regarding available time and resources, it is likely that some important search terms were not identified during the strategy definition, or that some publications did not get into the final selection, due to generalised inclusion and exclusion criteria.

(13)

2.5 Ethical considerations

The materials selected for the SLR were all collected from the databases open for public use, where the authors of the primary studies gave their explicit consent for their publications to be cited. Several of the primary studies include surveys and interviews and during study selection they were examined for potential ethical violations. This report does not focus on any specific individual opinions presented in those publications, instead interpreting the findings of all primary studies holistically for the purpose of creating a general overview of the subject.

(14)

3 Results

The literature search was carried out according to the search strategy described in chapter 2.1 and gave over 17.000 results. After applying the study selection procedure described in chapter 2.2, a total of 26 publications were selected for the SLR. The steps performed during study selection, as well as the number of publications that satisfied the selection criteria at each step, are illustrated in Figure 3.1.

Figure 3.1: Study selection process

There were 26 primary studies selected for the literature review that had to some extent addressed the problems defined in section 1.3 regarding the benefits and challenges associated with automation of development environment provisioning and tools available for such implementation. After the snowballing procedure on several secondary studies, five relevant primary studies were identified and included in the SLR. Moreover, two studies that were already mentioned in chapter 1.2 were also included in the research. The full list of studies selected for the SLR can be found in Appendix 1.

The studies were published between 2009 and 2019, with the most relevant studies published during the past five years. The distribution of studies along the timeline is presented in Figure 3.2. Most studies were published in 2012 and 2015, thereafter the trend seemed to be more or less stable. However, with the consideration that the study selection had been done on a relatively small batch of search results, the results were not necessarily representative and were not deemed sufficient to determine trends within the topic of current research.

The final set of publications selected for the SLR consisted of one book, one dissertation, one bachelor and two master thesis reports, one working paper, 15 articles, and 12 conference papers. The most common research methods employed in the selected studies were surveys, case studies, and prototypes. Some publications had multiple research methods applied in one study. The distribution of types of publications are presented in Figure

(15)

3.3, and Figure 3.4 shows the distribution of research types used.

There were a total of 25 publications that were peer-reviewed.

Figure 3.2: Publish years of reviewed studies.

Figure 3.3: Distribution of publication types.

(16)

Figure 3.4: Distribution of research methods.

The following concepts were identified to have a direct impact on the transition from manually to automatically provisioned development environments. DevOps and the associated continuous practices suggest that any repetitive manual task promotes human error and thus should be automated.Cloud Computing provides application infrastructure on demand, where a basic server or a complex environment can be provisioned within minutes, given that it is modelled with the help of machine-readable definition code. Microservices architecture takes advantage of virtualisation for developing, testing and deploying complex software solutions.

Distributed software development requires extra effort in synchronisation of the software development process and tools between teams and developers that are dispersed throughout the world while working in collaboration on the same project. This issue is resolved by means of automation and virtualisation. The number of studies that address these concepts is presented in Table 3.1.

Concept Number of studies

DevOps 21

Continuous practices 25

Cloud computing 22

Microservices 9

Distributed software development 11

Table 3.1: Concepts that impact automation of development environment Based on the keywords in the articles and papers assigned by the authors, a word cloud was generated that presented the main concepts discussed in those studies. The word cloud is presented in Figure 3.5.

Figure 3.5: Keywords cloud

(17)

4 Analysis

This chapter presents an analysis of the SLR findings in the form of an answer to each research question defined in chapter 1.

4.1 Benefits of provisioning a development environment automatically (RQ1)

There were seven main benefits identified during the research associated with the automatic provisioning and deployment of a development environment (DE). The distribution of the benefits presented in the primary studies is depicted in Figure 4.1.

Figure 4.1: Distribution of primary studies with regard to RQ1

4.1.1 Consistent environments entail speed, quality, collaboration

Commonly, the code created and committed on a DE would go through a variety of tests and integration procedures before it is built in a dedicated environment, then deployed to a staging environment, where it goes through rigorous testing once again, after which it is finally deployed to production.

Each environment that the code passes needs to be configured and provisioned [S3], [S7], [S17], [S19], [S20], [S23], [S25], [S28], [S29].

Differences in development, test, staging and production environments create problems [S17], [S20], [S23]. The diversity between DEs of different developers within a project would most likely negatively impact the development process, its efficiency, traceability, and consistency since the code or application errors would be hard to reproduce between

(18)

different DEs or development sites [S8], or the code might work and pass tests on a local DE, but would fail during production [S1], [S31]. This could happen due to mismatch of the DE configuration or its scale [S31], operating system (OS) incompatibility, differences in server configuration, network setup or the security rules applied to it [S19]. Therefore it is paramount that all environments should be the same as much as possible, specifically like the production environment [S20], [S21], [S23], [S25], [S28], [S29], [S33], so it would be possible to test and deploy software without any need to modify any of the environments, i.e. without time waste [S19], [S23]. Since the end-users might have some constraints within their infrastructure regarding OS or hardware they use, it is important to replicate their infrastructure for development and tests [S18]. Moreover, all developers should work on the same OS, same versions of supporting libraries, and the same Integrated Development Environment (IDE) [S29].

If some (or all) environments are provisioned manually, it is most likely that at some point a diversity would be introduced, specifically when one of the environments is updated, but the changes are not properly documented, or a human error occurred while propagating these updates to other environments [S3], [S17], [S25]. With all that in mind, and due to the complexity of modern software solutions it is mandatory to avoid any manual configuration of infrastructure and treat it as code with a help of configuration management (CM) [S11], [S18], [S25].

CM offers automatic configuration and control over all infrastructure elements: hosts and their OS, software, users, services, networking, storage [S11], while Infrastructure as code (IaC) allows efficient coordination and integration of software development, IT operations and quality assurance (QA), as well as knowledge sharing and better collaboration between them [S20].

Harmonised environments, that are described in form of configuration code, are self-documented, allow to effortlessly start, destroy or recreate any necessary environment, therefore resulting in shorter lead time, faster delivery to production, faster feedback, reduced development costs, and an efficient DevOps culture [S10], [S11], [S17], [S21], [S23], [S24], [S25], [S28], [S32] [S33]. For example, it is documented that with IaC it is possible to decrease the time needed to provision a DE from two days down to 21 minutes with a single command run from the developer's own terminal [S26], [S32]. This means dramatically decreased wasted time for developers and other stakeholders, where instead of waiting for operations to provision necessary environments the work can start almost immediately [S3], [S15], [S21], [S25], [S28].

4.1.2 Low maintenance environments

Most developers would like to minimise tasks related to system administration in the form of software installation and configuration [S10], [S12]. With a DE as code, a developer can start a standardised DE from his workstation using a single command, without any need for extra configuration [S26], [S32].

In case there was a need to apply changes to the environment (e.g.

install additional library), or the production environment was updated (e.g.

(19)

security updates or patches [S10], [S26]), all such manipulations should be done via a script rather than to the environment directly [S3], this way the environment is always repeatable, reproducible and harmonised, which means minimal developer's involvement [S10], [S12], no need for operations to manually push the changes to already provisioned environments, and all stakeholders work with the same latest version of a stable and tested environment [S5], [S26], [S31].

By provisioning environments with custom build scripts that are independent of IDE's built-in functionality, would allow all stakeholders to produce consistent builds in all environments [S7] since custom manual builds are error-prone and can produce inconsistency between environments [S1], [S31].

Moreover, incorporating package management into the configuration of the DE would allow performing controlled updates of libraries and modules [S9], [S18], enable collaboration and knowledge sharing between developers, as well as establish best practices within the project or organisation, facilitate built-in security, and help to avoid package incompatibilities [S9].

4.1.3 Traceability

CM supplies tracing information for the artefacts of the software itself and its infrastructure, becoming a type of documentation that allows any stakeholder to get a quick understanding of added changes and trace the evolution of environments and their tools [S2], [S3], [S11], [S15], [S25].

Together with version control (VC), CM enables collaboration between multiple developers and records changes made to infrastructure's configuration files, as well as tracks when those changes were applied and by whom. Additionally, it enforces continuous improvement of configuration, allows to incorporate and merge configuration of new services and features, as well as to quickly roll back and recover from failure [S11], [S25].

4.1.4 Reusability

When configuration scripting is approached like any other code by employing modularisation, separation into classes, and general simplicity, this allows creating flexible and reusable blocks of code that describe the configuration of different services and software items, which in turn enables code reuse between projects or services [S11].

4.1.5 Distributed development

The threats to software quality and timely delivery are higher within a distributed development environment where team members are spread around different sites, countries, and time zones. Communication and collaboration are handicapped due to physical distance, language barriers, and different working hours [S8]. Automated, well-defined configuration of a DE that is under VC mitigates the above-mentioned issues. Developers on all sites are using the same tools and software during development, follow the same workflow, any changes added to infrastructure are immediately validated and made available on all sites via VC [S5], [S8].

(20)

Additionally, moving the development of software into the cloud facilitates collaboration and distributed development even further.

Cloud-based DEs do not require additional configuration and work out-of-the-box, they are easy to set up or tear down, easy to share between developers and escalate collaboration by means of live sharing and group coding in the cloud-based IDE, offer real-time conflict tracking, automatic change integration, and unobtrusive configuration management, as well as utmost monitoring and logging capabilities [S5], [S6], [S10], [S12], [S14], [S21], [S22].

4.1.6 Cost management

Cloud-based DEs do not require extensive computing power locally since everything happens in the cloud. The solutions are provided and scaled on-demand and charged on pay-as-you-go bases, which means minimal investments for startups and flexible cost management [S10], [S21], [S22].

4.1.7 Virtualisation

Automated provisioning of a DE is improved even further with the incorporation of virtualisation techniques, such as virtual machines (VM) and containers, which isolate the DE with all required tools, software, and settings [S7], [S15], [S16]. Virtualisation allows the software produced within an automated DE to be fully independent of the configuration of a local machine, which means no dependency conflicts with local configuration [S7], [S15]. This helps to keep diverse environments consistent and in sync and allows to develop, test, and deploy software using the same configuration, thus increasing quality and speed of development [S15], [S16].

moreover, it becomes possible to have several DEs running simultaneously on the same machine that otherwise would be incompatible [S16], [S33], or to recreate the complete production environment on a single host for the improved testing procedure [S15], [S16], [S27].

The above-mentioned benefits of the DE automation, when combined with virtualisation, have another positive effect on software development - they provide support for the development and deployment of applications with microservices architecture [S15], [S16], [S27].

4.1.8 Other applications

Self-contained, deployed with a single command DEs have become a valuable tool not only within software development but also as a part of scientific research [S18] and educational process [S4], [S6]. This approach allows for users with minimal development and operational knowledge to reap the full benefit of fully configured DE, that is easy to experiment with without polluting the local workstation, and which allows to shift focus from the process of provisioning the DE towards the computational functions the DE provides [S4], [S6], [S18].

4.2 Challenges of the automatic provisioning of a development environment (RQ2)

There were three main challenges identified during the SLR associated with the automatic provisioning and deployment of DE. The distribution of the

(21)

challenges identified in the primary studies is depicted in Figure 4.2.

Figure 4.2: Distribution of primary studies with regard to RQ2 4.2.1 Learning curve

Most of the studies have shown that the learning curve and general reluctance to change are the biggest challenges when adopting the new development workflow since there are a lot of new tools and techniques that need to be understood and learned to work with [S9], [S10], [S22], [S23], [S26], [S28].

The usual workflow is disrupted and familiar processes, such as testing and debugging, become complex, which might mean a longer time to market [S22], [S26]. Additionally, the IT operations perceive that their workload has increased, and developers feel that they got more responsibilities [S26], [S28]. Moreover, the cultural aspect of the new workflow that requires closer communication and collaboration between developers and operations is perceived as very challenging [S23], [S28].

Since the automated approach towards software development requires a broad set of expertise that is still relatively new, it is challenging to find skilled employees for the development and maintenance of scripted infrastructure [S28].

Despite the above-mentioned aspects, the quantitative data shows that with experience and deeper understanding of new tools and workflows, most stakeholders conclude that the benefits of infrastructure automation outweigh the challenges, and they are willing to continue working with new methodology [S21], [S26].

4.2.2 Tools

When it comes to using cloud-based services and tools, it is mentioned that the process is not without fault, and even though the service providers are responsible for environment provisioning and deployment, some steps are still required to build and start the DE locally [S12], [S22]. Moreover, some development, legacy, and project management tools that are normally used with a local setup of the DE are still not available as cloud-based [S10], [S22], [S23]. With cloud-based infrastructure developers and operations have access to additional data, in the form of logs, statistics, and monitoring data, which is abundant and confusing, thus might become redundant [S14], [S22].

Cloud providers often focus on open-source tools, which in turn require additional configuration and customisation, this means longer lead time due to knowledge acquisition [S12], [S23]. Moreover, cloud solutions

(22)

are very closely coupled with their provider, which makes it very hard to change vendor or port together applications and services that developed on different platforms [S12], [S13], [S21], [S22].

The number of available providers and the multitude of services they each offer, complicates the issue even further since now there is a need for a broker that would help with making the decision regarding which provider and service to use, estimating the budget, and outlining the infrastructure [S21].

4.2.3 Security

The issues related to the application and network security become paramount when moving to the cloud, since now application's sensitive data, as well its source code, are available on the web [S21], [S22]. IaC scripts have to be checked for common security vulnerabilities, such as giving the scripts unnecessary administrative privileges, including secrets directly in configuration scripts, leaving passwords empty or hard-coded, using HTTP without TLS, and using weak cryptographic algorithms [S32].

4.3 Tools for development environment automation (RQ3)

There was a multitude of different tools used for the DE automation that were named in the primary studies. Most of them were just briefly mentioned, while cloud solutions appeared to attract the most interest. Following are the tools that could be used to automate a DE provisioning, some of them can be used in solitude, while it is also possible to create complex solutions for provisioning and deployment of a complete application infrastructure by employing all of these tools together.

The distribution of the tools for the DE automation found in the primary studies is depicted in Figure 4.3.

Figure 4.3: Distribution of primary studies with regard to RQ3

(23)

4.3.1 Version Control

VC is basically a database system that keeps track of all configuration files and scripts, when they were updated and by whom [S3]. It is a tool that enables sharing and collaboration between project members. By creating a chronological tracking of infrastructure components, it becomes possible to document their development, as well as revert to the latest known stable version in case of erroneous infrastructure deployment [S3], [S5], [S6], [S14], [S22], [S28], [S29], [S31].

VC cannot be used by itself to automatically deploy DE, but it is an important tool to empower collaboration and knowledge sharing as a part of DevOps principles [S3], [S15], [S19], [S20], [S28], [S29], [S31]. The research mentions four VC software providers Git, SVN, CVS, and Azure DevOps. There is no discussion as to which tool should be used under which circumstances.

4.3.2 Build and packaging tools

Build tools were identified to be important for maintaining consistency between diverse environments. Automated and scripted builds were used to compile and package the software in order to detect integration errors as early as possible. [S2], [S7], [S9], [S20], [S29], [S31]

Depending on the application stack, tools like Maven, Ant, Ivy, Gradle, Rake, or their equivalent could make it easy to package and deliver the application.

4.3.3 Configuration management tools

CM tools were identified to provide automated, fast, repeatable and predictable deployment of a DE [S2], [S3], [S11], [S15], [S19], [S20], [S31].

There were two main models of CM tools described in the research regarding the delivery of updates to deployed environments: push and pull delivery.

Within the push model the central CM server, once a configuration update was committed, pushes the changes to all servers/environments that it supervises. In the pull model, the servers under CM have dedicated demons constantly running and pulling updates from the CM repository. It is also possible to have a standalone installation of a CM tool that on command would create or destroy a DE on the machine it is running on. [S3], [S31]

There were four CM tools named in the studies: Salt, Ansible, Puppet, Chef.

4.3.4 Virtualisation

There were two solutions for environment virtualisation mentioned in the studies - virtual machines (VM) and containers [S14], [S15], [S16], [S18], [S22], [S27], [S29], [S31]. Most popular VM implementation is Vagrant, and Docker is leading technology within containers.

While a VM is a fully independent environment that simulates a computer system with its own OS and virtualized hardware, a container virtualises only the OS which makes it a more light-weight virtualisation option. The latter is faster to start up and requires fewer resources, which means that there can be several containers running in parallel on the same host without noticeable impact on the performance of host or guest systems.

(24)

Because of that containers are often used as the base for the Platform as a Service solutions [S14], [S18], [S29], [S31]

4.3.5 Web-based IDE

Web-based IDEs, such as Cloud9, CodeRun Studio, Codeanywhere, offer access to a large set of programming tools that are developed and maintained by the provider, as well as online collaborative DE. Stand-alone cloud-based development and collaboration environments. [S1], [S5], [S10], [S12], [S14], [S21], [S22]

4.3.6 Cloud computing

The most common models of cloud-provided services are Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

SaaS offers a complete application that is made available to developers and other end-users via online web access. This allows developers to get started on the development immediately given the online access, utilise generic modules and components that are available as utils, work with a codebase that is always synchronised. (Providers examples: Google Apps, Salesforce, Dropbox). [S1], [S10], [S13], [S14], [S22]

PaaS offers a computing development platform with tools that support design, implementation and deployment of web applications. With productivity in focus, different PaaS solutions offer various levels of control for the developer by allowing to select the needed set of development tools for increased collaboration and productivity, while removing the burden of operational needs. (Providers examples: Oracle, Azure, Google App Engine, Heroku, Cloud Foundry, AWS). [S1], [S10], [S12], [S13], [S22], [S26]

IaaS offers a complete infrastructure, often composed of multiple VMs. The user of IaaS gets the administrative access to the infrastructure and has to provision the VMs on their own. The development process can be carried out on a VM deployed on such infrastructure. (Providers examples:

AWS, OpenStack, Azure). [S12], [S13], [S22], [S26]

4.3.7 Prototypes

There were three prototypes of cloud-based DEs presented in the studies that address some of the research questions.

Collabode is Java-based web-based IDE that supports real-time code sharing among developers, intended for developers simultaneously working on the same piece of code with the same view. The main objective of this IDE is to support three types of collaboration: micro-outsourcing, test-driven pair programming and classroom programming [S4], [S6].

CloudStudio - brings focus to configuration management through a distributed collaborative IDE. The main functionalities of this tool are unobtrusive CM (automatically syncing and saving all changes) and an awareness system (it presents fresh changes to other collaborators) [S5].

ICDO - an Integrated Cloud-based Development Tool for DevOps that consists of a web-based IDE, a cloud broker API that dynamically selects the best cloud provider/solution according to the application under development [S21].

(25)

4.4 Summary

To recapitulate the findings of the SLR described in this chapter, the answers to the research questions are presented on the next page in Table 4.1.

RQ Findings Description

1 Consistency Identical software environments (e.g. development, test, staging, production) help to speed up the development process and increase the quality of software

Maintainability Scripted provisioning and deployment of an environment makes it repeatable, reproducible and harmonised Traceability Configuration scripts become a documentation of the

infrastructure and its development

Reusability Modular configuration scripts can be re-used between teams and projects

Distributed development

When team members are spread around different sites automated environments facilitate communication, collaboration, efficiency

Cost management Cloud-based DEs require minimal monetary investments Other Support for scientific research and education

2 Learning curve Both developers and operations need to learn new tools, workflows, communication approaches

Tools Cloud-based tools do not always match up to their local counterparts

Security Configuration scripts might introduce vulnerabilities, e.g.

secrets, default passwords, administrative access

3 Version control Records changes made to automation scripts Build tools Support automated builds and artefacts' creation Configuration

management

Creates repeatable, reproducible, homogeneous, self-documented environments via scripts

Virtualisation Encapsulates the environment with its software, tools, dependencies

Web-based IDE Provides access to a managed set of programming tools on-demand

Cloud computing Provides development software, platform or infrastructure as a service, on-demand

Prototypes Various cloud-based collaboration and development environments

Table 4.1: Research findings

Software Development Environment: the DevOps perspective

Bachelor Degree Project