Sincronizando com o Overleaf.

parent 6d38c06f
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
\section{Fundamental \devops Concepts}
\section{Fundamental concepts}
\label{sec:concepts}
In this section, we present the \emph{fundamental concepts on \devops} emerged from our literature review.
The \emph{objective} of our conceptual maps is \emph{to provide a relevant and structured set of concepts on \devops, grounded in the literature, to support the analysis of \devops challenges}.
Our contribution is \emph{to provide a relevant and structured set of concepts on \devops, grounded in the literature, to support the analysis and understanding of \devops challenges}.
The concepts were separated into four major categories: Process, People, Delivery, and Runtime. These categories are depicted on Figure~\ref{fig:concepts-families} and the following subsections present one conceptual map for each of the listed categories.
The concepts emerged from the protocol presented in Section \ref{sec:methodology}. They are distributed into four major categories: Process, People, Delivery, and Runtime. \emph{Process} category encompasses business-related concepts. \emph{People} category covers skills and concepts regarding the culture of collaboration. \emph{Delivery} category provides the concepts necessary for continuous delivery. Finally, \emph{runtime} category synthesizes concepts necessary to guarantee stability and reliability of services in a continuous delivery environment.
While Process and People categories are more related to the manager perspective, Runtime and Delivery are more related to engineers. Moreover, while \emph{Delivery} concepts are more related to developers, \emph{Runtime} concepts are more related to the traditional operator role. The categories are depicted in Figure~\ref{fig:concepts-families} and described in the sequence.
\begin{figure}[ht]
\includegraphics[scale=0.4]{figs/concepts-categories}
......@@ -14,7 +16,7 @@ The concepts were separated into four major categories: Process, People, Deliver
\subsection{Process}
\devops deploys a continuous delivery \emph{process} to achieve business benefits. Reducing risk and cost, complying with regulations, improving product quality and customer satisfaction are samples of these benefits. We grouped those concepts into the \emph{process} category of concepts, and they are all related to the business outcome from \devops. Some concepts are not exclusively achieved by \devops approach. One could argue that rigorous human and hierarchical approval process is an option to reduce risk, comply with regulations, and provide product quality. The difference here is that the \devops approach is based on the agile mindset, which advocates the shortening of feedback cycle through frequent releases. The \emph{Process} category of concepts is presented in Figure \ref{fig:concepts-process}.
\devops enables and motivates a continuous delivery \emph{process} to achieve business benefits. Reducing risk and cost, complying with regulations, improving product quality and customer satisfaction are examples of these benefits. We grouped these concepts into the \emph{process} category of concepts and they are all associated with the business outcome from \devops. One could argue that rigorous human and hierarchical approval process is an option to reduce risk, comply with regulations, and provide product quality. The difference here is that the \devops practices are aligned with the agile mindset, which promotes the shortening of the feedback cycle through frequent releases. The \emph{Process} category of concepts is presented in Figure \ref{fig:concepts-process}.
\begin{figure}[ht]
\includegraphics[scale=0.25]{figs/concepts-process}
......@@ -24,7 +26,7 @@ The concepts were separated into four major categories: Process, People, Deliver
\subsection{People}
The term ``\devops'' itself centers around the idea of bringing together \emph{people} from development and operations through a culture of collaboration. The intention is avoiding distinct areas of the organization to have different and conflicting goals, which could reduce efficiency and time-to-market. However, breaking down the silos raises a lot of questions, such as: how to perform a cultural shift in the organization that implies more responsibilities for developers? How do developers acquire operations skills? Can developers and operators work in the same team and still keep different job titles? Should ``\devops'' be a role? Should teams be cross-functional and include operators? Should an operator be exclusive to one single team? What actually means being an operator in the \devops context? Although the concepts implied in such questions are frequent in the literature, the answers are not clear yet. We grouped these concepts in the \emph{people} category and we debate such questions in Section~\ref{sec:devosp-adoption-approaches}. The \emph{People} category of concepts is presented in Figure~\ref{fig:concepts-people}.
The term ``\devops'' itself centers around the idea of bringing together \emph{people} from development and operations through a culture of collaboration. The intention is avoiding distinct areas of the organization to have different and conflicting goals, which could reduce efficiency and time-to-market. However, breaking down the silos raises a lot of questions: how to perform a cultural shift in the organization that implies more responsibilities for developers? How do developers acquire operations skills? Can developers and operators work in the same team and still keep different job titles? Should ``\devops'' be a role? Should teams be cross-functional and include operators? Should an operator be exclusive to one single team? What does it mean being an operator in the \devops context? Although the concepts of this category are frequent in the literature, the answers for the previous questions are not clear yet, so we debate them in Section~\ref{sec:devosp-adoption-approaches}. We grouped these concepts in the \emph{People} category of concepts, which is presented in Figure~\ref{fig:concepts-people}.
\begin{figure}[ht]
\includegraphics[scale=0.25]{figs/concepts-people}
......@@ -34,7 +36,7 @@ The term ``\devops'' itself centers around the idea of bringing together \emph{p
\subsection{Delivery}
The core strategy for achieving a frequent and reliable delivery process is based on the automation of the \emph{deployment pipeline}, from which \devops tools and techniques emerge. We grouped the concepts surrounding the deployment pipeline into the \emph{delivery} category, which is a much more technical category than the previous ones. There is still some debate on concrete approaches for tooling, such as the containerized approach leveraged by Docker from one side, and continuous configuration convergence, such as in Chef and Puppet, on the other side. We discuss such debate in Section~\ref{sec:tools}. However, we claim that the \emph{delivery} concepts are much more stable and accepted by the community than the \emph{people} concepts. The \emph{Delivery} category of concepts is presented in Figure~\ref{fig:concepts-delivery}.
The core strategy for achieving a frequent and reliable delivery process is the automation of the \emph{deployment pipeline}, from which \devops tools and techniques emerge. We grouped the concepts surrounding the deployment pipeline into the \emph{delivery} category, which is a much more technical category than the previous ones. There is still some debate on concrete strategies for tooling, such as the containerized approach leveraged by Docker from one side, and continuous configuration convergence, such as in Chef and Puppet, on the other side. We discuss such debate in Section~\ref{sec:tools}. However, we claim that the \emph{delivery} concepts are much more stable and accepted by the community than the \emph{people} concepts. The \emph{Delivery} category of concepts is presented in Figure~\ref{fig:concepts-delivery}.
\begin{figure}[ht]
\includegraphics[scale=0.25]{figs/concepts-delivery}
......@@ -44,7 +46,7 @@ The core strategy for achieving a frequent and reliable delivery process is base
\subsection{Runtime}
\emph{Runtime} concepts are a subsequent and necessary extension in the \devops approach since it is not enough to continuously deliver new versions, but it is also necessary for each new version to be stable and reliable. The need for such reliability is the main link between the \devops approach and cloud environments. It is also worthy to note that while \emph{delivery} concepts are more related to developers, \emph{runtime} concepts are more related to the traditional operator role. The \emph{Runtime} category of concepts is presented in Figure~\ref{fig:concepts-runtime}.
\emph{Runtime} concepts are a subsequent and necessary extension in the \devops since it is not enough to continuously deliver new versions, but it is also necessary for each new version to be stable and reliable. The need for such reliability is the main connection between \devops and cloud environments. The \emph{Runtime} category of concepts is presented in Figure~\ref{fig:concepts-runtime}.
\begin{figure}[ht]
\includegraphics[scale=0.25]{figs/concepts-runtime}
......@@ -52,3 +54,8 @@ The core strategy for achieving a frequent and reliable delivery process is base
\label{fig:concepts-runtime}
\end{figure}
\subsection*{}
We now complement our conceptual analysis taking a look on the practical side of \devops by investigating the \devops tools, their actors, and their relations to concepts. As the presentation of \devops concepts has already raised some concerns demanding more discussion, some issues will also emerge from the discussion on \devops tools.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
\section{Limitations}
\section{Limitations of this study}
\label{sec:limitations}
% 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. For example, we have not considered academic workshops and we have considered only a few books in the field. It would not be practical to try to cover every existing work on \devops and condensing it all in this single survey, which is also limited in length. However, by focusing on journal and conference papers, and by applying the snowballing process, we hope to have covered the main literature on the field.
The choice of the main selected studies, primarily in the snowballing process, as well paper classification, may suffer from subjective bias. One contributing factor is that \devops has not a single definition widely accepted by the community. To avoid favoring specific facets of \devops in our selection, we have used only the keyword ``\devops'' in our search query. However, the appearance of the keyword ``\devops'' was not mandatory in the snowballing process, so we could select some important work tackling highly related subjects as, for example, continuous delivery. To reduce the subjective bias, at least two authors participated in the selection process and in 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. Therefore, we did not address this issue in this survey.
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.
\section{Conclusions}
\label{sec:conclusions}
In this survey, we have discussed the most common \devops challenges presented by the literature. We based our approach on a conceptual analysis grounded in the academic literature and complemented by other sources.
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.
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.
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.
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.
%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.
The two fundamental pillars of \devops are 1) human collaboration across departments and 2) automation. In this survey we found that technical issues regarding delivery automation are more consolidated, having only a few minor controversies. On the other hand, how to effectively enable collaboration among departments is not well discussed, as 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 found in the literature or in the community 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; 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 fundamental topic that ran through all the sections of this survey is about structuring an organization in the \devops context. The options are 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.
Finally, we found few works focusing on the experience of more than a single organization. Similarly, we found very few works using 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.
No preview for this file type
......@@ -69,7 +69,7 @@
\newcommand\devops{DevOps\xspace}
\newcommand\numberofselectedpapers{167\xspace}
\newcommand\numberofmainselectedpapers{50\xspace}
\newcommand\pageofmainselecetdstudies{31\xspace}
\newcommand\pageofmainselecetdstudies{29\xspace}
\newcommand{\myparagraph}[1]{\vspace{.5em}\noindent\textit{\textbf{#1:}}\hspace{.3em}}
\newcommand{\swurl}[1]{\footnote{\url{#1}}}
......@@ -144,7 +144,7 @@
% \state{SP}
% \postcode{05508-090}
\country{Brazil}}
\email{paulo@unifesp}
\email{paulo.meirelles@unifesp.br}
\author{Fabio Kon}
%\orcid{1234-5678-9012-3456}
......@@ -172,8 +172,8 @@
\begin{abstract}
\devops refers to a collaborative and multidisciplinary effort within an organization, aiming at automating continuous delivery of new software versions, while guaranteeing their correctness and reliability.
In this context, this survey investigates and discusses \devops challenges from the multiple perspectives of engineers, managers, and researchers. Based on the reviewed literature, we develop a conceptual map from the \devops field. From this conceptual background, we analyze the \devops tools and discuss the implications of \devops concepts and practices for engineers, managers, and researchers. Finally, we discuss critically some of the most relevant \devops challenges revealed by the literature on the topic.
\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.
\end{abstract}
......@@ -227,7 +227,7 @@ In this context, this survey investigates and discusses \devops challenges from
% English help: https://corpus.byu.edu/coca/
\info{Paper length: should not exceed 35 pages}
%\info{Paper length: should not exceed 35 pages}
\input{1-introduction}
\input{2-methodology}
\input{3-sources-of-knowledge}
......
This diff is collapsed.
......@@ -548,4 +548,21 @@ isbn="978-3-319-13835-0"
publisher = {ACM}
}
@misc{roberts2018serverless,
author = {Mike Roberts},
title = {{Serverless Architectures}},
year = {2018},
note={\url{https://martinfowler.com/articles/serverless.html}, accessed on Oct 2018.}
}
@article{dejan2011autograding,
author={Dejan Milojicic},
title={Autograding in the Cloud: Interview with David O'Hallaron},
journal={IEEE Internet Computing},
volume={15},
number={1},
pages={9--12},
year={2011},
publisher = {IEEE}
}
\ No newline at end of file
......@@ -3,7 +3,7 @@
\begin{table}[ht]
\centering
\caption{Papers classification}
\caption{Classification of the main selected studies}
\label{tab:papers-classification}
\begin{tabular}{l r r} \hline
......@@ -11,25 +11,19 @@
\hline
% KEEP ORDERED
Support & 10 & \citesel{wettinger2015knowledge, wettinger2015environments, woods2016view, basiri2016chaos, magoutis2015social, pang2016maintenance, jaatun2018incident, rahman2018defective, li2018api, zhu2015frequency} \\
Practices & 15 & \citesel{wettinger2015knowledge, wettinger2015environments, woods2016view, basiri2016chaos, magoutis2015social, jaatun2018incident, rahman2018defective, li2018api, zhu2015frequency, brown2016microservices, cukier2013patterns, ebert2016devops, kang2016docker, kersten2018explosion, forsgren2018metrics} \\
Impact & 8 & \citesel{yasar2016security, shahin2016architecting, roche2013quality, jaatun2017security, cerqueira2015researchops, rajkumar2016culture, sill2014standards, rossem2018virtualized} \\
Experience report & 8 & \citesel{balalaie2016microservices, callanan2016right, chen2015huge, feitelson2013facebook, gray2006conversation, neely2013easy, siqueira2018gov, cerqueira2015researchops} \\
Experience report & 7 & \citesel{balalaie2016microservices, callanan2016right, chen2015huge, feitelson2013facebook, gray2006conversation, neely2013easy, siqueira2018gov} \\
Impact & 7 & \citesel{yasar2016security, shahin2016architecting, roche2013quality, jaatun2017security, rajkumar2016culture, sill2014standards, rossem2018virtualized} \\
Surveys & 6 & \cite{travassos2016SLR, Erich2017SLR, gill2017SLR, Jabbari2016SLR, Bosch2017SLR, Paasivaara2015LSR} \\
Concepts & 7 & \citesel{humble2011devops, humble2017willwork, punjabi2016stories, bass2018architect, dyck2015release, debois2011revolution, pang2016maintenance} \\
Introduction & 6 & \citesel{humble2011devops, humble2017willwork, punjabi2016stories, bass2018architect, dyck2015release, debois2011revolution} \\
Challenges & 6 & \citesel{laukkarinen2017medical, lwakatare2016towards, diel2016distributed, olsson2012stairway,leppanen2015highways, claps2015journey} \\
Challenges & 5 & \citesel{laukkarinen2017medical, lwakatare2016towards, diel2016distributed, olsson2012stairway,leppanen2015highways} \\
Education & 4 & \citesel{chung2016ksa, hussain2017zealand, bai2018feedback, christensen2016teaching} \\
Education & 3 & \citesel{chung2016ksa, hussain2017zealand, bai2018feedback} \\
Adoption patterns & 3 & \citesel{nybom2016mixing, snyder2018analytics, feijter2018maturity} \\
Tools & 3 & \citesel{ebert2016devops, kang2016docker, kersten2018explosion} \\
Practices and patterns & 2 & \citesel{brown2016microservices, cukier2013patterns} \\
Adoption & 3 & \citesel{nybom2016mixing, snyder2018analytics, feijter2018maturity} \\
\hline
......
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