syncing text

parent 815f2df6
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
\section{Discussion of challenges}
\section{Unresolved Challenges}
\label{sec:discussion}
Throughout this survey, we have shown that overviewing \devops concepts and tools raises some issues to debate. The previous section also listed some not-so-straightforward implications for practitioners and researchers. Therefore, based on the surveyed literature and additional sources of knowledge, we further discuss in this section some of the \devops challenges faced by managers, engineers, and researchers that are not thoroughly handled by the current state-of-the-art.
\subsection{How to re-design systems toward continuous delivery}
\label{sec:redesign}
Highly coupled monolithic architecture are obstacles to effective continuous delivery. Complex dependency management of software components and teams is imposed to the deployment pipeline~\citesel{shahin2016architecting}.
An essential principle for successfully adopting and implementing continuous delivery is an architecture composed of small and independently deployable units~\citesel{shahin2016architecting}. Lewis and Fowler call this architectural style ``microservices,'' a single application developed as a suite of small distributed services that communicate through the network, are built around business capabilities, and are independently deployable~\cite{fowler2014microservices}.
Highly coupled monolithic architectures are obstacles to effective continuous delivery. Complex dependency management of software components and teams is imposed to the deployment pipeline~\citesel{shahin2016architecting}.
An essential principle for successfully adopting and implementing continuous delivery is an architecture composed of small and independently deployable units~\citesel{shahin2016architecting}. Lewis and Fowler call this architectural style ``microservices,'' a single application developed as a suite of small distributed services that communicate through the network, built around business capabilities, and independently deployable~\cite{fowler2014microservices}.
Conceiving of an application architecture with loosely coupled and well-encapsulated microservices guarantees two architectural attributes required by continuous delivery: \emph{testability} and \emph{deployability}~\citesel{humble2017willwork}. If each microservice has its test suit, this reduces the blocking of deployment due to long-running tests~\citesel{leppanen2015highways}.
Conceiving of an application architecture with loosely coupled and well-encapsulated microservices guarantees two architectural attributes required by continuous delivery: \emph{testability} and \emph{deployability}~\citesel{humble2017willwork}. If each microservice has its test suite, this reduces the blocking of deployment due to long-running tests~\citesel{leppanen2015highways}.
Whereas some authors say microservices facilitate effective implementation of \devops~\citesel{balalaie2016microservices}, others say microservices require \devops~\citesel{ebert2016devops}, since deployment automation minimizes the overhead to manage a significant number of microservices.
However, adopting microservices comes with several challenges. First, there is heterogeneity in non-functional patterns such as startup scripts, configuration files, administration endpoints, and logging locations~\citesel{callanan2016right}. Technological heterogeneity can be a productivity barrier for newcomers in the team. Second, microservices must be deployed to production with the same set of versions used for integration tests~\citesel{brown2016microservices}. These challenges can be overcome by adopting a minimum set of microservices standards across the organization~\citesel{callanan2016right}.
......@@ -20,7 +21,7 @@ In highly regulated environments, the proper use of microservices can constrain
%In the case of testability for firmware development, Humble reported a case in which success was achieved when the architecture changed to let tests execution on a hardware simulator and reproduction of test failures on developer workstations~\citesel{humble2017willwork}.
PaaS is also recommended for its operational simplicity, like other cloud services, such as storage services, asynchronous processing with queues, email delivery, and real-time user monitoring~\citesel{cukier2013patterns}.
Finally, although reusability is a historical goal of software engineering~\cite{mcilroy1968massproduced}, Shahin \emph{et al.} recommend engineers not focus too much on it~\citesel{shahin2016architecting}. It brings coupling, which is a huge bottleneck to continuously delivery~\citesel{shahin2016architecting}. Therefore, each team should discuss the trade-off between reusability and independence from other components, services, and teams.
Finally, although reusability is a historical goal of software engineering~\cite{mcilroy1968massproduced}, Shahin \emph{et al.} recommend engineers not to focus too much on it~\citesel{shahin2016architecting}. It brings coupling, which is a huge bottleneck to continuous delivery~\citesel{shahin2016architecting}. Therefore, each team should discuss the trade-off between reusability and independence from other components, services, and teams.
\subsection{How to deploy \devops in an organization}
\label{sec:devosp-adoption-approaches}
......
......@@ -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 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.
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 in the field. We decided not to expand the query string to avoid artificially favoring some of the \devops 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 classification of papers. More experienced researchers also supervised the whole process.
The choice of core and relevant papers 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. 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.
In this survey, we have discussed \devops concepts and challenges presented in the literature. By associating these concepts with tools, we contributed to supporting practitioners in choosing a proper toolset. This paper also aides IT professionals by presenting in a systematic way the most relevant concepts, tools, and implications, 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 daily activities based on each 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, 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 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.
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) 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.
Structuring an organization to introduce \devops is now a major concern. There are three alternative 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.
......
No preview for this file type
......@@ -14,7 +14,7 @@
% Pacotes que nós adicionamos:
\usepackage{xspace}
\usepackage{multibib}
\newcites{sel}{Main selected studies}
\newcites{sel}{List of Core Papers}
% ---------------------------------------------------------------------------- %
% Macros for proof-reading
......@@ -69,7 +69,7 @@
\newcommand\devops{DevOps\xspace}
\newcommand\numberofselectedpapers{167\xspace}
\newcommand\numberofmainselectedpapers{50\xspace}
\newcommand\pageofmainselecetdstudies{29\xspace}
\newcommand\pageofmainselecetdstudies{30\xspace}
\newcommand{\myparagraph}[1]{\vspace{.5em}\noindent\textit{\textbf{#1:}}\hspace{.3em}}
\newcommand{\swurl}[1]{\footnote{\url{#1}}}
......@@ -161,7 +161,7 @@
\author{Dejan Milojicic}
%\orcid{1234-5678-9012-3456}
\affiliation{%
\institution{Hewlett Packard Labs}
\institution{Hewlett Packard Labs, Palo Alto}
% \department{Department of Computer Science}
% \streetaddress{Rua do Matao 1010}
\city{Palo Alto}
......@@ -217,7 +217,7 @@ The present survey investigates and discusses DevOps challenges from the perspec
%
\keywords{DevOps, other keywords}
\keywords{DevOps, continuous (delivery, deployment, integration), release process, versioning, configuration management, and build process}
\maketitle
......
%!PS-Adobe-3.0 EPSF-3.0
%%Title: /home/leonardo/books-per-year.eps
%%Creator: matplotlib version 2.1.1, http://matplotlib.org/
%%CreationDate: Mon Apr 23 17:35:13 2018
%%Title: /home/leonardo/Figure_1.eps
%%Creator: matplotlib version 3.0.2, http://matplotlib.org/
%%CreationDate: Sun Dec 30 10:31:38 2018
%%Orientation: portrait
%%BoundingBox: 75 223 536 568
%%EndComments
......@@ -536,8 +536,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
73.832727 38.016 m
103.346777 38.016 l
103.346777 49.03513 l
73.832727 49.03513 l
103.346777 42.348308 l
73.832727 42.348308 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -546,8 +546,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
110.725289 38.016 m
140.239339 38.016 l
140.239339 71.073391 l
110.725289 71.073391 l
140.239339 51.012923 l
110.725289 51.012923 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -556,8 +556,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
147.617851 38.016 m
177.131901 38.016 l
177.131901 49.03513 l
147.617851 49.03513 l
177.131901 42.348308 l
147.617851 42.348308 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -566,8 +566,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
184.510413 38.016 m
214.024463 38.016 l
214.024463 82.092522 l
184.510413 82.092522 l
214.024463 53.179077 l
184.510413 53.179077 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -576,8 +576,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
221.402975 38.016 m
250.917025 38.016 l
250.917025 126.169043 l
221.402975 126.169043 l
250.917025 79.172923 l
221.402975 79.172923 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -586,8 +586,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
258.295537 38.016 m
287.809587 38.016 l
287.809587 219.831652 l
258.295537 219.831652 l
287.809587 107.332923 l
258.295537 107.332923 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -596,8 +596,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
295.188099 38.016 m
324.702149 38.016 l
324.702149 291.456 l
295.188099 291.456 l
324.702149 133.326769 l
295.188099 133.326769 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -606,8 +606,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
332.080661 38.016 m
361.594711 38.016 l
361.594711 159.226435 l
332.080661 159.226435 l
361.594711 291.456 l
332.080661 291.456 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -616,8 +616,8 @@ gsave
357.1 266.1 57.6 38.02 clipbox
368.973223 38.016 m
398.487273 38.016 l
398.487273 49.03513 l
368.973223 49.03513 l
398.487273 57.511385 l
368.973223 57.511385 l
cl
0.122 0.467 0.706 setrgbcolor
fill
......@@ -933,12 +933,12 @@ grestore
stroke
grestore
} bind def
57.6 93.1117 o
57.6 81.3391 o
grestore
gsave
37.881250 89.314777 translate
37.881250 77.542202 translate
0.000000 rotate
0.000000 0.000000 m /one glyphshow
0.000000 0.000000 m /two glyphshow
6.362305 0.000000 m /zero glyphshow
grestore
gsave
......@@ -959,12 +959,12 @@ grestore
stroke
grestore
} bind def
57.6 148.207 o
57.6 124.662 o
grestore
gsave
37.881250 144.410429 translate
37.881250 120.865279 translate
0.000000 rotate
0.000000 0.000000 m /two glyphshow
0.000000 0.000000 m /four glyphshow
6.362305 0.000000 m /zero glyphshow
grestore
gsave
......@@ -985,12 +985,12 @@ grestore
stroke
grestore
} bind def
57.6 203.303 o
57.6 167.985 o
grestore
gsave
37.881250 199.506082 translate
37.881250 164.188356 translate
0.000000 rotate
0.000000 0.000000 m /three glyphshow
0.000000 0.000000 m /six glyphshow
6.362305 0.000000 m /zero glyphshow
grestore
gsave
......@@ -1011,16 +1011,70 @@ grestore
stroke
grestore
} bind def
57.6 258.399 o
57.6 211.308 o
grestore
gsave
37.881250 254.601734 translate
37.881250 207.511433 translate
0.000000 rotate
0.000000 0.000000 m /four glyphshow
0.000000 0.000000 m /eight glyphshow
6.362305 0.000000 m /zero glyphshow
grestore
gsave
/o {
gsave
newpath
translate
0.8 setlinewidth
1 setlinejoin
0 setlinecap
0 0 m
-3.5 0 l
gsave
0.000 setgray
fill
grestore
stroke
grestore
} bind def
57.6 254.631 o
grestore
gsave
31.521875 250.834510 translate
0.000000 rotate
0.000000 0.000000 m /one glyphshow
6.362305 0.000000 m /zero glyphshow
12.724609 0.000000 m /zero glyphshow
grestore
gsave
/o {
gsave
newpath
translate
0.8 setlinewidth
1 setlinejoin
0 setlinecap
0 0 m
-3.5 0 l
gsave
0.000 setgray
fill
grestore
stroke
grestore
} bind def
57.6 297.954 o
grestore
gsave
31.521875 294.157587 translate
0.000000 rotate
0.000000 0.000000 m /one glyphshow
6.362305 0.000000 m /two glyphshow
12.724609 0.000000 m /zero glyphshow
grestore
gsave
31.803125 149.454812 translate
25.443750 149.454812 translate
90.000000 rotate
0.000000 0.000000 m /Q glyphshow
7.871094 0.000000 m /u glyphshow
......
......@@ -254,7 +254,7 @@ isbn="978-3-319-13835-0"
}
@INPROCEEDINGS{Bosch2017SLR,
author={D. Stahl and T. Martensson and J. Bosch},
author={Daniel Stahl and Torvald Martensson and Jan Bosch},
booktitle={43rd Euromicro Conference on Software Engineering and Advanced Applications},
series = {SEAA 2017},
title={Continuous practices and devops: beyond the buzz, what does it all mean?},
......@@ -565,4 +565,41 @@ isbn="978-3-319-13835-0"
pages={9--12},
year={2011},
publisher = {IEEE}
}
\ No newline at end of file
}
@inproceedings{stol2016grounded,
author={Klaas-Jan Stol and Paul Ralph and Brian Fitzgerald},
booktitle={2016 IEEE/ACM 38th International Conference on Software Engineering},
series = {ICSE '16},
title={Grounded Theory in Software Engineering Research: A Critical Review and Guidelines},
year={2016},
pages={120-131}
}
@book{corbin2014slr,
title={Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory},
author={Juliet Corbin and Anselm Strauss},
year={2014},
edition={4th},
publisher={SAGE Publications, Inc}
}
@inproceedings{terceiro2010analizo,
title={Analizo: an extensible multi-language source code analysis and visualization toolkit},
author={Terceiro, Antonio and Costa, Joenio and Miranda, Jo{\~a}o and Meirelles, Paulo and Rios, Luiz Rom{\'a}rio and Almeida, Lucianna and Chavez, Christina and Kon, Fabio},
booktitle={Brazilian Conference on Software: Theory and Practice (Tools Session)},
series={CBSoft},
volume={29},
year={2010}
}
@inproceedings{mulyana2018chatops,
author={Eueung Mulyana and Rifqy Hakimi and Hendrawan},
booktitle={2018 4th International Conference on Wireless and Telematics},
series = {ICWT},
title={Bringing Automation to the Classroom: A ChatOps-Based Approach},
year={2018},
pages={1--6}
}
......@@ -10,7 +10,7 @@
}
@article{balalaie2016microservices,
author={A. Balalaie and A. Heydarnoori and P. Jamshidi},
author={Armin Balalaie and Abbas Heydarnoori and Pooyan Jamshidi},
journal={IEEE Software},
title={Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture},
year={2016},
......@@ -56,7 +56,7 @@
}
@inproceedings{wettinger2015knowledge,
author={J. Wettinger and V. Andrikopoulos and F. Leymann},
author={Johannes Wettinger and Vasilios Andrikopoulos and Frank Leymann},
booktitle={2015 IEEE International Conference on Cloud Engineering},
title={Automated Capturing and Systematic Usage of DevOps Knowledge for Cloud Applications},
year={2015},
......@@ -77,7 +77,7 @@ publisher = {IEEE},
}
@article{callanan2016right,
author={M. Callanan and A. Spillane},
author={Matt Callanan and Alexandra Spillane},
journal={IEEE Software},
title={DevOps: Making It Easy to Do the Right Thing},
year={2016},
......@@ -113,7 +113,7 @@ publisher = {IEEE},
}
@article{woods2016view,
author={E. Woods},
author={Eoin Woods},
journal={IEEE Software},
title={Operational: The Forgotten Architectural View},
year={2016},
......@@ -230,7 +230,7 @@ publisher = {IEEE},
}
@inproceedings{kang2016docker,
author={H. Kang and M. Le and S. Tao},
author={Hui Kang and Michael Le and Shu Tao},
booktitle={2016 IEEE International Conference on Cloud Engineering (IC2E)},
title={Container and Microservice Driven Design for Cloud Infrastructure DevOps},
year={2016},
......@@ -250,7 +250,7 @@ publisher = {IEEE},
@INPROCEEDINGS{laukkarinen2017medical,
title={DevOps in Regulated Software Development: Case Medical Devices},
author={T. Laukkarinen and K. Kuusinen and T. Mikkonen},
author={Teemu Laukkarinen and Kati Kuusinen and Tommi Mikkonen},
booktitle = {Proceedings of the 39th International Conference on Software Engineering: New Ideas and Emerging Results Track},
series = {ICSE-NIER '17},
year={2017},
......@@ -283,7 +283,7 @@ publisher = {IEEE},
}
@inproceedings{cerqueira2015researchops,
author={M. de Bayser and L. G. Azevedo and R. Cerqueira},
author={Maximilien de Bayser and Leonardo G. Azevedo and Renato Cerqueira},
booktitle={2015 IFIP/IEEE International Symposium on Integrated Network Management (IM)},
title={ResearchOps: The case for DevOps in scientific applications},
year={2015},
......@@ -292,7 +292,7 @@ publisher = {IEEE},
}
@inproceedings{diel2016distributed,
author={E. Diel and S. Marczak and D. S. Cruzes},
author={Elisa Diel and Sabrina Marczak and Daniela S. Cruzes},
booktitle={11th IEEE International Conference on Global Software Engineering (ICGSE)},
title={Communication Challenges and Strategies in Distributed DevOps},
year={2016},
......@@ -310,7 +310,7 @@ publisher = {IEEE},
}
@inproceedings{olsson2012stairway,
author={H. H. Olsson and H. Alahyari and J. Bosch},
author={Helena H. Olsson and Hiva Alahyari and Jan Bosch},
booktitle={38th Euromicro Conference on Software Engineering and Advanced Applications},
title={Climbing the "Stairway to Heaven" -- A Mulitiple-Case Study Exploring Barriers in the Transition from Agile Development towards Continuous Deployment of Software},
year={2012},
......@@ -536,7 +536,7 @@ note={Code: I77}
@inproceedings{dyck2015release,
author={A. Dyck and R. Penners and H. Lichter},
author={Andrej Dyck and Ralf Penners and Horst Lichter},
booktitle={2015 IEEE/ACM 3rd International Workshop on Release Engineering},
title={Towards Definitions for Release Engineering and DevOps},
year={2015},
......
......@@ -3,7 +3,7 @@
\begin{table}[ht]
\centering
\caption{Classification of the main selected studies}
\caption{Classification of core papers}
\label{tab:papers-classification}
\begin{tabular}{l r r} \hline
......
......@@ -22,7 +22,7 @@ Jabbari \cite{Jabbari2016SLR} & & & X
\hline
Lwakatare \cite{Lwakatare2015SLR} & X & & X & X & X & X & X & 22 \\
\hline
Our survey & X & X & X & X & X & X & X & \numberofselectedpapers (\numberofmainselectedpapers)
This survey & X & X & X & X & X & X & X & \numberofselectedpapers (\numberofmainselectedpapers)
\end{tabular}
\end{adjustbox}
\end{table}
......
......@@ -15,15 +15,15 @@ RQ1: What is the meaning of the term \devops? &
\begin{tabular}{@{}c@{}}\cite{travassos2016SLR}, \cite{Erich2017SLR}, \cite{gill2017SLR}, \\ \cite{Jabbari2016SLR}, \cite{Bosch2017SLR} \end{tabular} \\ \hline
RQ2: What are the issues motivating the adoption of \devops? &
\begin{tabular}{@{}c@{}}\cite{travassos2016SLR},\cite{Erich2017SLR},\cite{gill2017SLR} \\ \end{tabular} \\
\begin{tabular}{@{}c@{}}\cite{travassos2016SLR}, \cite{Erich2017SLR}, \cite{gill2017SLR} \\ \end{tabular} \\
\hline
RQ3: What are the main expected benefits of adopting \devops? &
\begin{tabular}{@{}c@{}}\cite{travassos2016SLR},\cite{Erich2017SLR}, \\ \cite{gill2017SLR}\end{tabular} \\
\begin{tabular}{@{}c@{}}\cite{travassos2016SLR}, \cite{Erich2017SLR}, \cite{gill2017SLR}\end{tabular} \\
\hline
RQ4: What are the main expected challenges/impediments of adopting \devops? &
\begin{tabular}{@{}c@{}}\cite{Paasivaara2015LSR},\cite{travassos2016SLR}, \\ \cite{Erich2017SLR},\cite{gill2017SLR}\end{tabular} \\ \hline
\begin{tabular}{@{}c@{}}\cite{Paasivaara2015LSR}, \cite{travassos2016SLR}, \\ \cite{Erich2017SLR}, \cite{gill2017SLR}\end{tabular} \\ \hline
%RQ5: What is known about the \devops Tools? &
%\cite{gill2017SLR} \\
......
......@@ -9,14 +9,14 @@
\emph{Category} & \emph{Examples} & \emph{Actors} & \emph{Goals} & \emph{Concepts} \\ \hline
\begin{tabular}{@{}c@{}}Knowledge \\ sharing\end{tabular} &
\begin{tabular}{@{}c@{}}Rocket Chat\\ GitLab wiki\end{tabular} &
\begin{tabular}{@{}c@{}}Rocket Chat\\ GitLab wiki \\ Redmine \\ Trello \end{tabular} &
\begin{tabular}{@{}c@{}}Everyone \end{tabular} &
\begin{tabular}{@{}c@{}}Human \\ collaboration\end{tabular} &
\begin{tabular}{@{}c@{}}Culture of collaboration\\ Sharing knowledge\\ Breaking down silos\\ Collaborate across departments\end{tabular}\\
\hline
\begin{tabular}{@{}c@{}}Source code \\ management\end{tabular} &
\begin{tabular}{@{}c@{}}Git\\ SVN\end{tabular}
\begin{tabular}{@{}c@{}}Git\\ SVN \\ CVS \\ ClearCase \end{tabular}
& Dev / Ops &
\begin{tabular}{@{}c@{}}Human \\ collaboration \\ and \\ Continuous \\ delivery\end{tabular} &
\begin{tabular}{@{}c@{}}Versioning\\ Culture of collaboration\\ Sharing knowledge\\ Breaking down silos\\ Collaborate across departments\end{tabular}\\
......
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