Syncing with overleaf - english review.

parent b1ea4a11
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -3,7 +3,7 @@
% based on the paper "A systematic literature review of service
% choreography adaptation" we have published on SOCA
Given the vast amount of work on \devops, we could not conduct an exhaustive search in every source. We have not considered academic workshops, and we only mentioned a few books in the field. It would not be practical to try to cover every existing work on \devops and to condense it all in this single survey. However, by focusing on journal and conference papers, and by applying the snowballing process, we hope to have covered the primary literature on the field. We decided not to expand the query string to not artificially favor some of the category concepts over others. However, the appearance of the keyword ``\devops'' was not mandatory in the snowballing process so that we could select vital work tackling highly related subjects as, for example, continuous delivery.
Given the vast amount of work on \devops, we could not conduct an exhaustive search in every source. We have not considered academic workshops, and we mentioned only a few books in the field. It would not be practical to try to cover every existing work on \devops and to condense it all in this single survey. However, by focusing on journal and conference papers, and by applying the snowballing process, we aimed to cover the primary literature on the field. We decided not to expand the query string to avoid artificially favoring some of the category concepts over others. However, the appearance of the keyword ``\devops'' was not mandatory in the snowballing process so that we could select vital work tackling highly related subjects such as continuous delivery.
The choice of the primary selected studies, as well paper classification, may suffer from subjective bias. To reduce this bias, at least two authors participated in the selection process and the papers classification. More experienced researchers also supervised the whole process.
There is also the publication bias since positive results are more likely to be published than negative results. We did not find, for example, a paper reporting a case of failed \devops adoption. We did not address this issue in this study.
The choice of the primary selected studies, as well paper classification, may suffer from subjective bias. To reduce this bias, at least two authors participated in the selection process and the classification of papers. More experienced researchers also supervised the whole process.
Our study also suffers the publication bias, since positive results are more likely to be published than negative results. We did not find, for example, a paper reporting a case of failed \devops adoption. We did not address this issue in this study.
\section{Conclusions}
\label{sec:conclusions}
In this survey, we have discussed \devops concepts and challenges presented by the literature. We associated these concepts to tools, contributing to support practitioners in properly choosing a toolset. Both concepts, tools, and implications were also associated with the professional perspectives of researchers, managers, and engineers, the last ones including developers and operators. In this way, our reader can better understand the impact of \devops on her activities based on her profile.
In this survey, we have discussed \devops concepts and challenges presented by the literature. By associating these concepts with tools, we contributed to supporting practitioners in choosing a proper toolset. Concepts, tools, and implications were also associated with the professional perspectives of researchers, managers, and engineers -- including developers and operators. We hope our reader can now better understand the impact of \devops on her activities based on her profile.
Two pillars of \devops are 1) human collaboration across departments and 2) automation. We found that technical issues regarding delivery automation are more consolidated, having only a few minor controversies in literature. On the other hand, there is no consensus on how to effectively empower collaboration among departments, as well there are only a few tools for tackling this issue.
Two pillars of \devops are 1) human collaboration across departments and 2) automation. We found that technical issues regarding delivery automation are more consolidated, with only a few minor controversies in the literature. On the other hand, there is no consensus on how to effectively empower collaboration among departments, and there are only a few tools for tackling this issue.
A technical topic highly related to \devops revealed by our sources was microservice architecture. Some technical conflicting points are: there is no consensus if microservices should be versioned; some practitioners see configuration management tools and containerization as complementary approaches, but others understand them as competitors; maximizing reusability of software components and services is possibly not the better strategy; rolling back is usually seen as a \devops practice, but some practitioners tend to favor feature toggles as a way to avoid rolling back.
A technical topic highly related to \devops revealed by our sources was microservice architecture. Some technical conflicting points are: there is no consensus on whether microservices should be versioned; some practitioners see configuration management tools and containerization as complementary approaches, but others understand them as competitors; maximizing reusability of software components and services may not be the better strategy; rolling back is usually seen as a \devops practice, but some practitioners tend to favor feature toggles as a way to avoid rolling back.
Structuring an organization to introduce \devops is a major concern in both academics and organizations. There are three possible structures: 1) keeping collaborating departments, 2) building cross-functional teams, and 3) having \devops teams. Each one of these strategies has its challenges, and, by following the current literature, it is not possible to define the best strategy for a given scenario. But whatever the structure adopted, it is clear that the \devops movement has blurred the frontier between developers and operators in an irreversible way, even for organizations that have not yet fully embraced \devops.
Structuring an organization to introduce \devops is a major concern in both academics and organizations. There are three possible structures: 1) preserving collaborating departments, 2) building cross-functional teams, and 3) having \devops teams. Each one of these strategies has its challenges, and, by following the current literature, it is not possible to define the best strategy for a given scenario. However, whatever the structure adopted, it is clear that the \devops movement has irreversibly blurred the frontier between developers and operators, even for organizations that have not yet fully embraced \devops.
%Finally, we found not sufficient works on the experience of more than a single organization. Similarly, quantitative metrics for assessing \devops adoption. We did not find any articles reporting negative results. These are some aspects to be improved in future research on \devops.
......
......@@ -172,8 +172,8 @@
\begin{abstract}
\devops is a collaborative and multidisciplinary effort within an organization, aiming at automating continuous delivery of new software updates while guaranteeing their correctness and reliability.
In this context, the present survey investigates and discusses \devops challenges from the multiple perspectives of engineers, managers, and researchers. We review the literature and develop a \devops conceptual map. We correlate the \devops automation tools with these concepts and discuss their practical implications for engineers, managers, and researchers. Finally, we discuss critically some of the most relevant \devops challenges reported by the literature on the topic.
\devops is a collaborative and multidisciplinary organizational effort to automate continuous delivery of new software updates while guaranteeing their correctness and reliability.
The present survey investigates and discusses DevOps challenges from the perspective of engineers, managers, and researchers. We review the literature and develop a DevOps conceptual map, correlating the DevOps automation tools with these concepts. We then discuss their practical implications for engineers, managers, and researchers. Finally, we critically explore some of the most relevant DevOps challenges reported by the literature.
\end{abstract}
......
......@@ -3,7 +3,7 @@
\begin{table}[ht]
\centering
\caption{Major research questions from previous \devops SLR works}
\caption{Primary research questions from previous \devops SLR works}
\label{tab:research-questions}
\begin{adjustbox}{max width=\textwidth}
\begin{tabular}{l r }
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment