Post on 30-May-2020
UPTEC IT 19 002
Examensarbete 30 hpJanuari 2019
Software Engineering using DevOps - a Silver Bullet?
Mikaela Eriksson
Institutionen för informationsteknologiDepartment of Information Technology
Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student
Abstract
Software Engineering using DevOps - a Silver Bullet?
Mikaela Eriksson
Today we have technology that help us scan millions of medical databases in a glimpse of an eye and self-driving cars that are outperforming humans at driving. Technology is developing so fast that new updates in the technology world are commonplace to us and we are more often frustrated in case something is not up to speed. Technology is moving so quickly and in order for humans to keep up with the development needed in the tech business, different methodologies for how to optimise the development process have been applied, some that work better than others. But just as fast as the technology changes, the methodologies used change with them. Recently a new term has entered the methodologies field. This term is said to bring faster deployment, decreased failures and improved the loyalties within the teams. The term in question, is called DevOps.
This study is about uncovering the world of DevOps. This thesis is exploring the term in real teams in order to find out whether or not DevOps is the silver bullet it makes out to be. The study is based on ten interviews with people at different organisations, using DevOps, and will find out how these interviewees use and feel about DevOps. Found in these interviews is that both the involvement in, interpretation and implementation of the term varies between the interviewees. Nothing was all the same between them. All interviewees were very positive about the term and its contributions to the process and would definitely implement it in any new team. However, also found is that development in organisations is leaning towards becoming more single minded. When creating and reforming teams, organisations rather exclude constellations of different human thoughts and departments in order to rely on different development platforms instead.To conclude from this is that DevOps might take away work from collaborating humans in favour of the speed we achieve in the assisting technologies. This in a possible alarming way since single minded teams can miss important aspects in development which can have a dangerous outcome. Even though this might be a truth, DevOps is seen as something very positive and could just be the silver bullet it is talked about it to be, but this only if each team can interpret it, implement it and use it in their own way.
Tryckt av: Reprocentralen ITCUPTEC IT 19 002Examinator: Lars-Åke NordénÄmnesgranskare: Åsa CajanderHandledare: Maryam Alizadeh
Software Engineering using DevOps - a Silver Bullet?
Sammanfattning
Idag har vi teknik som hjalper oss att skanna miljontals medicinska databaser pa ett ogonblick
och sjalvkorande bilar som ar battre an oss pa att kora bil. Tekniken utvecklas sa snabbt att nya
uppdateringar i teknikvarlden ar vardagsmat, och vi blir latt frustrerade om nagot inte gar i den
hoga hastigheten vi forvantar oss. Tekniken ror sig sa snabbt nufortiden och for att vi manniskor
ska kunna folja med i den utveckling som behovs inom tekniken, har olika metoder for hur man
optimerar utvecklingsprocesser tillampats. Men lika snabbt som tekniken andras, forandras de me-
toder som anvands med dem. Nyligen har en ny term inom metoder uppkommit. Denna term sags
ge snabbare implementering, farre misslyckanden och forbattrad lojalitet inom team. Termen i fraga
kallas DevOps.
Denna studie handlar om att dyka ner i DevOps varld for att utforska om termen ar den silverkula
som det pavisar sig vara. Studien ar baserad pa tio intervjuer med personer fran olika organisa-
tioner som sagt att de anvander DevOps och har som mal att ta reda pa hur dessa intervjuade
anvander och upplever DevOps. Funnet i dessa intervjuer ar att bade inblandning i, tolkning och
genomforande av termen varierar mellan de intervjuade. Ingenting som sas var det samma mellan
intervjuerna. Alla intervjuade var mycket positiva over att ha implementerat DevOps, vad det bi-
dragit med till processer och skulle definitivt implementera DevOps i nya team. Men det kan ocksa
konstateras att utvecklingen i organisationer ar pavag mot att bli mer enkelsinnad. Vid skapande
och reformering av team utesluter organisationer hellre konstellationer av olika manskliga tankar
och avdelningar for att istallet forlita sig pa olika utvecklingsplattformar. Slutsatsen ar att DevOps
kan orsaka att team tar bort samarbete mellan manniskor till forman for den hastighet de uppnar
i tekniken. Detta ar potentiellt alarmerande da enformiga team kan missa viktiga aspekter i sin
utveckling vilket kan leda till allvarliga konsekvenser. Aven om detta kan vara en sanning sa ses
DevOps som nagot mycket positivt och kan anda vara den silverkulan som det talas om att det ska
vara, men enbart om varje team kan tolka det, implementera det och anvanda det pa sitt eget satt.
2
Software Engineering using DevOps - a Silver Bullet?
Acknowledgements
This study would not have been possible to complete without the help and support from the following
people which deserve a special thank you.
Asa Cajander. Thank you for agreeing to be reviewer and for coming up with the idea to discover
DevOps and to view it from a human-computer interaction point of view. Thank you for helping me
with the process, insightful thoughts and for reading and commenting on my report almost every week,
it has been gold. Also thank you for saying that ”good enough” is a more than an acceptable result,
without that this report would have been much harder and not as fun to write as it was.
Maryam Alizadeh. Thank you for being there in exactly the right way, for always asking in case
you can help and for setting up things to enable the interviews and presentation. Thank you for taking
time reading my report and supporting me with ideas along the way.
Omegapoint. Thank you for the opportunity to write this thesis at your company and office even
though it always was very cold. You all have been so including and kind that it is hard to leave.
Especially thank you to Tatiana, Bettan, Apparna, Gustav and the others around the table for making
the time fly with laughter, hopefully the connections will remain.
Mum and dad. Thank you dad for helping me with all your knowledge about the subject, for set-
ting up interviews and for giving important suggestions at the last hours. Especially thank you for
your enthusiasm about the subject chosen, it was much appreciated. Thank you mum for the support
in the darkest times, for always believing in me and for always being the inspiration. Mum and dad,
this report is dedicated to you.
3
Software Engineering using DevOps - a Silver Bullet?
Contents
1 Introduction 6
2 Background 8
2.1 Interpretation of DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Platforms and Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Other Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Scope, Goal and Limitations 13
3.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Related Work 14
4.1 Interpretation and Implementation of DevOps . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Involvement in the DevOps Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Automating Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Collaboration Between Teams with DevOps Implemented . . . . . . . . . . . . . . . . . 15
4.5 Effects of Implementing DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 The Contribution of this Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Method 17
5.1 Preparatory Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 The Interview Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1 Quantitative Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2 Interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Analysing Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Results 22
6.1 Interpretation and Implementation of DevOps . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Involvement in the DevOps Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Automating Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4 Collaboration Between Teams with DevOps Implemented . . . . . . . . . . . . . . . . . 25
4
Software Engineering using DevOps - a Silver Bullet?
6.5 Effects of Implementing DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7 Discussion 28
7.1 Interpretation and Implementation of DevOps . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1 The Developers Own Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.2 DevOps Used Before as Continuous Integration . . . . . . . . . . . . . . . . . . . 30
7.1.3 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4 Implementation of DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Involvement in the DevOps Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2.1 Establishment of the Development Team and the Operations Team . . . . . . . . 32
7.2.2 The Organisations with no Operations Team . . . . . . . . . . . . . . . . . . . . 33
7.3 Automating Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3.1 Manual Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3.2 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.4 Collaboration Between Teams with DevOps Implemented . . . . . . . . . . . . . . . . . 35
7.4.1 Change in Team Collaboration with DevOps . . . . . . . . . . . . . . . . . . . . 36
7.4.2 Team Prioritised in the DevOps Process . . . . . . . . . . . . . . . . . . . . . . . 36
7.5 Effects of Implementing DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.5.1 Initial Thought of Implementing DevOps . . . . . . . . . . . . . . . . . . . . . . 37
7.5.2 Changes in the Process by Using DevOps . . . . . . . . . . . . . . . . . . . . . . 38
7.6 General Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8 Conclusion 40
9 Future Work 43
10 References 44
5
Software Engineering using DevOps - a Silver Bullet?
1 Introduction
Technology is amazing. We have inventions that allow us to visualise things in the real space with
augmented reality, computer systems that out-compete human physicians when it comes to finding the
right diagnosis in the health business and self-driving cars that slowly are taking over driving from us
humans. Never before has technology been this prominent in our lives, but so far, there are still humans
that are the creators of all these inventions. Humans are falling behind the machines when it comes to
speed and accuracy so in order to keep up with the fast changes needed in technology, we need to look
at new methods of developing.
For many years, new methodologies for how to optimise the development processes has arisen and
been applied, but just as quickly as new technology is developed, these development methodologies
change. The question whether to use a development methodology or not is non existing for organisa-
tions these days, instead they ask themselves whether or not to use something like a Waterfall [8] or
a more Agile [4] methodology for their projects. The list of development methodologies can be made
endless. Especially if organisations make minor changes to existing methodologies in order to fit their
specific organisation structure better. However recently there is one term for development methodology
that has entered the field in a revolutionary way: DevOps.
From studies found online it is possible to read praise for this methodology. Companies who state
that they have implemented a DevOps methodology state that they have decreased the amount of
failures, improved the loyalty within and thus accelerated their entire process [34]. If this is the case,
DevOps might just be the new buzzword that has revolutionised the industry, but it can also just be
that companies present to sound up to speed and on the market. This while employees working with it
has no clue what it means in practice and nothing really has changed. In order to see how DevOps works
in real life settings, the bases of this thesis is an interview study with several different companies and
teams where the following questions were used with the intention to uncover the truth about DevOps:
• What is the interpretation of DevOps in different companies and how has it been implemented?
• How are different compnay teams involved in the DevOps process?
• How much of the developers work is automated with DevOps and are there specific software
platforms that are used to facilitate the development process?
6
Software Engineering using DevOps - a Silver Bullet?
• Are there major differences between development and operations? Can both sides work together
with DevOps or is one team prioritised in the implementation so that the teams still have a
disagreement?
• How do different teams (development, operations etc.) respond to DevOps? Are there specific
approaches to get the teams to handle DevOps so it actually makes a difference in production?
Is DevOps the silver bullet that saves the day, or is it the bullet that kills it all?
7
Software Engineering using DevOps - a Silver Bullet?
2 Background
Today the term ”DevOps” is frequently used in companies worldwide. [13] Many claim that they either
work with DevOps in their teams or that a specific person is a DevOps Engineer and it is clear that
no established definition of the word is to be found. In books and online, each author has made their
own interpretation of the word which also applies to the companies with the ambition to use it as well.
DevOps is in constant movement and might never settle for a clear definition so therefore the following
is a perception of the word based on the different explanations found.
2.1 Interpretation of DevOps
DevOps is a term that first arised on a DevOps conference in Ghent, Belgium in 2009. The founder
of the conference Patrick Debois coined the term and explained ”the new way of development” which
would eliminate the silos that many experience between the development team and the operations
team. [38]
For a long time, the development team (eg. programmers, quality assurance personnel and testers)
and the operation team (eg. system administrators, network technicians and database administrators)
have had friction between them. According to Hutterman [37], this is mostly since the development
department usually wants to release their changes quickly while the operation team rather have stability
in their work and therefore have a slower approach to changes. In order to improve the process for both
teams, so development and operations teams can experience the entire process unitedly and thereby
create a more fluent production, DevOps was created (see figure 1)[14]. DevOps is the combination of
the words ”Development” and ”Operations” and refers to the interaction between the development and
operation team. [24]
Figure 1: Visualisation of the DevOps process [14]
8
Software Engineering using DevOps - a Silver Bullet?
Michael S. Cuppet suggests in his book DevOps, DBAs and DbaaS - Managing Data Platforms to
Support Continuous Integration that if a company includes four pillars in their work, the DevOps
process has a better likelihood of being successful. These pillars are [30]:
• Culture: In order to obtain a new way to work, the entire team at the company needs to be on
board in the changing process. The core of the company usually is its culture, since the culture
describes how the organisation ”does its business” and processes as well as engagement with others
and how well the teams interact with other employees [33]. If the company culture is strong it
can be difficult to change the culture and its staff towards a DevOps mindset, which is about
workflow [25], feedback and continual learning. This since strong cultures usually have a rigid set
of goals, processes, roles etc. which may make it problematic to implement new processes [32].
In order to work with DevOps, the culture needs to accept the different direction of working and
since the DevOps culture strive to be as agile [4] as possible it is fundamental that employees
working with it has an open mindset to change and work agile.
• Automation: Since DevOps strive to be agile, automation [5] is a good way to achieve that
since it enables processes to be more efficient and effective. With automation, a process that is
done without a human, testing, installations, allocations and much more can be done at a much
quicker rate without the human error factor, which can be things such as typing errors and lapses
of memory, or unnecessary discussion between parties with different views.
• Measurement: In order to improve work, feedback is necessary since it enables to see what has
been good and bad with a process, and one good way to collect feedback is by doing measurements.
By measuring work done at a workplace or automate processes, the development can be enhanced
further and so forth be more agile.
• Sharing: DevOps was created to bridge the gap between the development team and the operations
team, and so for that gap to be closed the two teams need to share their knowledge and work
together. To have a movement of DevOps sharing between people, processes and platforms is
required to get to the shared goal without mixed signals and beliefs.
However as mentioned before, there are (yet) no set ways of how or what to implement in order to work
”the DevOps way”, these points mentioned above are merely prospects that has been seen to prosper
the usage of a DevOps movement and should only be seen as a recommendation. Consequently, DevOps
is not a new technical invention, it is a way of improving collaboration in working processes between
the operation team and the development team. This in order to create a more fluent production.
9
Software Engineering using DevOps - a Silver Bullet?
2.2 Platforms and Tools
In order to facilitate the usage of DevOps, different platforms and supporting tools has been developed.
The most frequently used cloud services platforms are presented in this section.
2.2.1 Amazon Web Services
Amazon Web Services (AWS) is Amazons subsidiary that provide a cloud service platform that offers
its users a wide range of infrastructure services. The service allows users to access a ”virtual cluster
of computers” at all times. The virtual computer has the possibility to emulate attributes like a real
computer which includes hardware, memory, choice of operation system with pre-loaded application
software and plenty more. The application is connected through a modern browser which performs as
a window to the virtual computer. With this, the AWS consumers can automate a lot of otherwise
manual work such as test flows and configuration management. When it comes to integrating AWS with
DevOps, Amazon state that AWS provides a number of adaptable services that are designed to allow
companies to ”more rapidly and reliably build and deliver products”. AWS facilitate provisioning and
management of infrastructure as well as deployment of application code and automating the software
releases. This in combination with monitoring everything in the application allows improvement of
the products for organisation costumers at a quicker phase than it was without AWS. [9] On Amazons
website, AWS is said to be of benefit to DevOps organisations because of the following:
• Fast start up: No setup required nor software to install.
• Fully managed services: AWS provides services in order to help the organisations focus on what
is important for them.
• Built for scale: AWS allows the user to manage a single instance or scale to thousands if needed.
• Programmable: There is the possibility to use each service via the AWS Command Line Interface
or APIs and SDK.
• Automation: With automation, AWS lets its user build faster and more efficiently.
• Secure: Users have the control over how and who have access to the resources.
• Large partner ecosystem: With AWS, consumers can use a chosen third-party and open source
tools accompanying AWS to build end-to-end solutions.
10
Software Engineering using DevOps - a Silver Bullet?
• Pay-as-you-go: AWS allows users to pay for the services as they need them for the time that they
plan to use them.
Amazon is an American based company with servers worldwide, but this year (2018), Amazon opened
AWS servers in Sweden. This not only allows Amazon to connect with more companies in the north,
but also favours Swedish companies to utilise AWS services at a lower latency which is of benefit for a
fast DevOps production.
2.2.2 Microsoft Azure
Azure is Microsofts equivalent to AWS. It is a cloud computing service which facilitate for its users
with building, testing and deploying together with managing applications and services. [19] Azure have
several different services to assist in a DevOps working organisation. An organisation can choose all the
DevOps services or just the one needed for the organisations own workflows. The services include agile
tools (e.g Azure DevOps service) to plan and track work, pipelines and test plans to build, test and
deploy work and Git repos to cloud host code in an advanced file management system. Furthermore
can Azure connect extensions to over 1,000 different apps and services to be the best it can for the
users. [3] The Azure DevOps tool, a part of the Azure stack and is the latest version from Microsoft
in a series of collaborative software development tools, provides the users with the following DevOps
support:
• Azure Boards: Gives the possibility to track work done on the project
• Azure Pipelines: The tool to continuously build, test, and deploy to any platform and cloud.
• Azure Repos: Cloud-hosted private Git repos for the project.
• Azure Artifacts: Create, host, and share packages with the team to support the continuous
integration/continuous delivery process.
Just like Amazon is Microsoft and Azure based in America with several servers in different countries.
At the moment are the closest servers in Germany but Microsoft has announced that they will build
Azure servers in Norway soon as well as rumours that they have bought land in Sweden.
2.2.3 Other Tools
Two other tools that are worth a brief mention when it comes to DevOps support are Microsoft Team
Foundation Service (TFS) and Atlassian product stack JIRA. These tools are to some seen as more
11
Software Engineering using DevOps - a Silver Bullet?
DevOps oriented then the two cloud services mentioned above since they are focusing more on the
team management and sharing assistance compared to AWS and Azure whose main function is cloud
storage. [10]
TFS
TFS is an on-premise solution by Microsoft for collaborative software development that supports ap-
plication life cycle management and enables DevOps capabilities. [22] The main functionalists are:
• Project management that gives the possibility to track work with Kanban boards, backlogs, team
dashboards, and custom reporting.
• Source code management.
• Automated builds, testing and release management capabilities.
JIRA
The company Atlassian provides with JIRA a large package of different products that supports the
development and operation of a software product that DevOps processes need. [17] Some of JIRAs
features are the following:
• Jira Software, the possibility to track work with Kanban boards, backlogs, team dashboards, and
custom reporting.
• Bitbucket, collaborate on code, build and ship software.
• Continuous integration, deployment, and release management.
• Confluence, document and file sharing collaboration tool.
• Collaboration tool Trello.
12
Software Engineering using DevOps - a Silver Bullet?
3 Scope, Goal and Limitations
3.1 Research Questions
Since there is no definite explanation of nor a rule book to follow to use DevOps, many different
interpretations of the term has emerged and been applied in companies worldwide. Furthermore it is
easy for companies to just ”jump on the bandwagon” without seeing to the needs and interests of the
employees who are going to work with it. Due to this, the goal of this project is to get an insightful view
of the usage of a DevOps driven process. To understand this, the following questions will be researched:
• What is the interpretation of DevOps in different companies and how has it been implemented?
• How are the different teams involved in the DevOps process?
• How much of the developers work is automated with DevOps and are there specific software
platforms that are used to facilitate the development process?
• Are there major differences between development and operations? Can both sides work together
with DevOps or is one team prioritised in the implementation so that the teams still have a
disagreement?
• How do different teams (development, operations etc.) respond to DevOps? Are there specific
approaches to get the people to handle DevOps so it actually makes a difference in production?
3.2 Limitations
In order to narrow this project down, it has been limited by the following factors:
• The report will only examine the DevOps platforms the different companies use and compare
them. That means that platforms not used by the companies are excluded from the study.
• The DevOps platforms will not be examined in a deeper technical level but rather examined to
get an overview and compare the major differences.
• A limited number of companies will be selected for interviews.
• Since the quotes will be translated from Swedish to English, some meaning may be lost in trans-
lation.
• Branches to DevOps like NoOps and BizDevOps will not be explored.
13
Software Engineering using DevOps - a Silver Bullet?
4 Related Work
In this section related work to the research questions are presented. The following research papers are
divided into how they relate to different parts of the research and how they differ from this study.
4.1 Interpretation and Implementation of DevOps
In an article by Alison DeNisco Rayome [40], it is stated that there are some important steps needed
to implement DevOps the right way. The first step state to start small, with implementing for example
continuous integration, in order to get an easier implementation. This instead of implementing a lot
of different things at the same time which requires a lot of management at different places and have
therefore a higher risk of failure. The remaining steps all in some way talks about the importance of
the culture in a company as well as finding potential bottle-necks in the upcoming implementation.
According to the article, the way the culture works in that particular organisation need to be reviewed
before implementing to see if the people in the teams are ready for a change. Both in their way of
working and that they have the same interpretation of what is going to happen. This in correlation to
what was mentioned in background about DevOps needing a faster more open culture in order to thrive.
The article here gives a good base of the need for human integration in order for DevOps to work, but
it does not mention any need of aid from computer programs nor how these steps have affected teams
in real organisations.
4.2 Involvement in the DevOps Process
In another article named What Team Structure is Right for DevOps to Flourish? [42] by Matthew
Skelton and Manuel Pais, several different team structures of DevOps and who is responsible for what
in the different teams is presented. Skelton and Pais describe that different topologies of DevOps,
and so how different teams involvement in the DevOps process will suit different types of organisation.
This depending on several things. For example, how big the product is, the technical knowledge in the
team, possibility of change within the teams responsibilities and the organisations skills. What is also
viewed are bad examples of the teams involvement in the DevOps process. These bad examples include
DevOps teams where the teams do not talk to each other, where the development team ”does DevOps”
with cloud platforms and do not need an operations team as well as the development team and the
operation team being the same people. It is said that these are bad examples of DevOps mostly due
14
Software Engineering using DevOps - a Silver Bullet?
to inefficiency and that in most cases it does not remove the silos and problems that were there in the
beginning. The good examples and involvement in the different teams include descriptions where the
two teams work together and take on there said specialities or where they have mastered each others
work and can help out where it is needed at the moment. The last one mentioned however is said to
be a branch to DevOps called NoOps [7]. This research also briefly say which type of set up is good for
which type of start teams but it does not say how to implement them nor how the different people in
the teams respond to the formations.
4.3 Automating Work
In the book DevOps for Developers [37], Michael Huttermann brings up approaches, processes and
platforms that can support collaboration between software development and operations. What this
book have compared to the others mentioned here is that it further explores how to actually implement
DevOps into the organisation with examples of code and useful platforms to increase the automation
in teams, however there is no information provided of how teams respond to each platform nor what
platform is beneficial for a specific interpretation of DevOps. Since Huttermanns book is targeted
towards developers, the operations team is not considered in the statements provided by the book and
would for this research project also be a group to examine.
4.4 Collaboration Between Teams with DevOps Implemented
The book Effective DevOps - Building a culture of collaboration affinity and platforming at scale by
Jennifer Davis [31] provide several methods for improving collaborations in teams, create a sympathy
between the team members and encourage the usage of helpful platforms in DevOps. Davis emphasises
what makes a team work better or worse and talks about different strategies that will help an organi-
sation with the usage of DevOps, for example CAMS (culture, automation, measurement and sharing)
that can be read about in background. To be noted with this book is that it focuses on set strategies
that should work to improve the usage of DevOps in an organisation, Davis does not broadly speak
of DevOps nor does she point out that DevOps can be interpreted in different ways. The things she
brings up are stated as ”concrete, actionable steps they [organisations] can take toward implementing
or improving a DevOps culture in their work environment” and is therefore rigid in the way to look at
and use DevOps.
15
Software Engineering using DevOps - a Silver Bullet?
4.5 Effects of Implementing DevOps
In 2016 the DevOps Research and Assesment (DORA) [12] together with Puppet [21] did a state of
DevOps report [34] where they have surveyed over 25 000 technical professionals on an international
level in order to understand how DevOps practices effect IT and organisational performance. Their
key findings in this were that organisations that uses for example DevOps ”deploy 200 times more
frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower
change failure rates” [34]. These organisations also have better loyalty within the different groups,
spend less time on unplanned work and improve their returns and performance. With this research
it is shown how DevOps can improve the organisations performance, however this research does not
look at what the major differences is between the work for development and operations nor at specific
development platforms that are used in order to achieve the results.
4.6 The Contribution of this Study
What all of these researches have in common is that they state, what to them are, facts about DevOps.
They set a definition of the word and project their content and solutions from that definition. Moreover
do they not look at how DevOps can differ between different organisation structures nor how their
statements are received by the people who are working with DevOps on a daily basis. Compared to this
will this study instead try to look at different organisations to see what has made their way successful
or not with the usage of DevOps. This will then be present in the overall results as knowledge sharing
that can be used as guidelines if an organisation wish to implement DevOps.
16
Software Engineering using DevOps - a Silver Bullet?
5 Method
The method of the project was divided into three different parts: preparatory research, interview process
and analysing the interviews. Below follows explanations of the different parts.
5.1 Preparatory Research
In order to obtain a sufficient background and an understanding of the term DevOps, background
research was conducted from different books, articles and blogs. The articles and blogs did not all
have to be scientific since DevOps is an evolving term, articles and blogs on the subject was at points
more up to date of how the term is seen currently. The scientific books and articles that contributed
with the preparatory research were found at Google Scholar mainly under the search words ”DevOps
Development”, ”DevOps Culture” and ”Agile Development”. The importance of this phase is to prepare
for the interviews. This in order to better understand the response from participants of the interviews
and ask relevant follow up questions and thereby collect data to evaluate and draw conclusions for the
project. Furthermore, in this part, the initial questions for the interviews were formulated.
5.2 The Interview Process
The main part of the project was built around the individuals met that use or have considered using
DevOps so the majority of this project was conducted by interviewing employees at different companies.
Interviews was the selected way to collect information for this project because it is possible to see more
of the underlying reasons for a persons answers. In questionnaires it is possible to receive a lot of
answers to a specific question, but it is not possible to ask the right follow up questions nor to observe
the person answering the questions. Furthermore were interviews better choice for this study since
if the interviewee were confused with a specific question they could ask. The disadvantages of using
interviews however was that it was time-consuming and that the environment might have had an impact
on the results [26]. It was of importance that the interview was held at a location where the interviewee
felt comfortable and the interview was not disturbed, this to enhance the feasibility of an adequate
reliable result. For this study these factors were negligible compared to the advantages the interviews
produced, but was taken in consideration when writing the discussion.
17
Software Engineering using DevOps - a Silver Bullet?
5.2.1 Quantitative Research
Since the interviews are the base of this project, a qualitative research design was chosen. In a qualitative
research, understanding the underlying meaning is more important than the amount of collected data,
that is the foundation of a quantitative research. Qualitative research is about recognising thoughts
and feelings that might have effect on a persons behaviour in a particular situation [44], which was
profoundly meaningful in this project. In a paper of J Smith it is suggested that a quantitative research
needs two different principles to be of use. The first one is that the interviewer needs to understand the
signification of what people describe of their lived experiences, the second is that the interviewer have to
be able to go beneath what is said to understand the underlying meaning of the persons words. For this,
the interviewer needs to have some knowledge in the subject to better interpret the persons background
and actions [43]. For this project, the base to bring these principles to an interview was collected in the
preparatory research phase. Even though correlations between collected information is not the most
important part in a qualitative research, as it might be in a quantitative research, it was of great interest
for this research since the interviews were later compared (see section 5.3) to see what was similar or
not. If there were correlations between two interviews it was not seen as a coincidence but rather the
opposite and sometimes was of significant meaning. There was great chance that an underlying reason
for the similarities was of considerable value that was worth looking into [39]. Important to remember
when using qualitative research is that a lot of the authors own perception of what is said and observed
can be found in the discussion and conclusion. Especially since the information collected is interpreted
by the author and is not universal. The quantitative research will therefore have an unique view to it
and should not be take as a truth but rather an impression of the information. [41]
5.2.2 Interviewees
The majority of the subjects considered suitable to interview were provided by the company Omega-
point [20]. In addition to this, companies that were found through personal inquiry were added in the
research. Study subjects that were suitable for the profile of this project, which were people that were
or have thought about working with DevOps, was contacted through email and asked if they wanted
to participate in the study. Both subjects that were working with DevOps and subjects that have
considered working with DevOps were of interest for this project since they could give different views
on the term. Those who were using DevOps could give their views on how it works and feels to use it,
while the people who had only thought about using it could give insight to what they were looking for
or why they choose not to implement DevOps.
18
Software Engineering using DevOps - a Silver Bullet?
5.2.3 Interviews
Subjects interested in participating in the study received an information sheet where they could find
details about the project, the interviews and what was expected of both them and the interviewer.
Furthermore they received a consent form which they would sign and submit on the day of the inter-
view, this in order to fairly use the material collected and that the participant agrees to the ways the
information was used. The interviews was preferably held at the participants work place to get a better
view of the implementation and general feeling within the company and group. If a person was located
too far away from the city of Stockholm, was unable to move or unable admit the interviewer to the
company, the interview was held via Skype. Set time of the interviews was around 30-60 minutes but
could be longer depending on follow up questions and possible show end tell of specific platforms or set
ups at the company.
The interviews were mainly in Swedish since this was the native tongue of both the interviewer and
the interviewees. However for the purpose of this paper the questions have been translated to English.
The following were the initial questions for the interviews:
• What is your definition of the term ”DevOps” and what do you see is included in the term?
Please explain in short.
• What is your role in a DevOps context?
• What was your initial thought when you heard that you and your team was going to work with
DevOps?
• How was DevOps introduced to the team? Were there any complications?
• How did the transition from the original way of working to the DevOps way of working?
• Is/was there any differences between development team and operations team in the implementa-
tion of DevOps?
• Are there big differences between development team and operations team in using DevOps and
possible platforms?
• Are you using any platforms to work the DevOps way? If that is the case, which ones?
• Is one of the teams prioritised in the usage of DevOps?
• If there was friction between the development team and the operations team, has that diminished
since DevOps was introduced?
19
Software Engineering using DevOps - a Silver Bullet?
• Have you seen or/and felt any change in the processes and production?
• How much of the current work is automated with DevOps?
• What is your over all feeling about DevOps? Would you implement it in a team that was not
using DevOps?
• Is there something else you would like to add that you believe is of benefit for this project?
Notes of the interviewees answers were taken by the interviewer on a computer. Important to remark is
that all interviews was anonymous and that there should be no possible way to identify the interviewed
person through name, company or other form of information. Furthermore it was always possible for the
interviewee to withdraw his or her participation in the project and with that, all collected information
related to that interviewee would be deleted.
5.3 Analysing Interviews
After all the interview data was collected, it was analysed in a thematic way. A thematic analysis
was chosen because it seeks to reveal patterns within the data collected, and this in particular was
useful for this project since it aims to see connections in the different definitions of DevOps [27]. In a
thematic analysis the first step was to familiarise with all the data and to get a better understanding of
how to sort data under different themes. The themes were created based on the interview questions in
connection with the interviewees answers and then linked to the research questions. The main themes
were mapped to a research question as seen below:
Figure 2: Research Questions to Themes
20
Software Engineering using DevOps - a Silver Bullet?
These themes then became the subsections for the result section. Not all sub-themes were chosen to
be written about in the result section, some themes emerged from the data and not all questions and
sub-themes had sufficient content nor relevant quotes to the research questions to be of value to the
discussion.
21
Software Engineering using DevOps - a Silver Bullet?
6 Results
The following section is divided into the different themes described in the method section and in the
different themes quotes from interviews are presented. Important to signify is that of the ten interviews
that were held, two subjects were in the operations team and eight subjects in the development team.
Moreover in three of the interviews the DevOps project team did not have a specific operations team,
instead the developers were responsible for the typical operation exercises such as testing, deploying
and maintaining the code and systems.
6.1 Interpretation and Implementation of DevOps
One of the major subjects in this theme was the interpretation the interviewees had of DevOps. Several
different explanations arose but a few key words stood out and occurred in more than one interview.
In half of the interviews the phrase ”own responsibility of the processes” or equivalent was mentioned.
Many of the interviewees expressed that with DevOps the developers took more responsibility, from
creating the code through the whole process, until launch and after. It was mentioned that before
DevOps, the responsibility was more spread out between management, development and operations.
This was said by both people that had a developer role in a DevOps project and people that were in
the operations team of DevOps. One interviewee put it very simple and is also a good representative
for the others interpretation as well:
”As a developer you are more aware of the entire process chain and can take a product all
the way.”
Another interviewee emphasised the power the responsibility brought by saying the following about
what DevOps meant to them:
”With DevOps, you as a developer have access to the machines which run the software as
well as access to deploying it. You have the possibility to automate and control the entire
infrastructure, and the infrastructure is there when you need it without having to go through
another department first. Developers have the possibility to take complete responsibility.”
Furthermore was the word ”automation” [5] along with ”continuous integration” mentioned as expla-
nation for what DevOps is. Continuous integration (from now on written as CI) here referred to the
term of a development practice where developers integrate their code into a shared repository with
testing multiple times, acknowledging teams about problems early [35]. CI was at many times in the
22
Software Engineering using DevOps - a Silver Bullet?
interviews equivalent to DevOps or stated as the following:
”Automating everything [in the process] through continuous integration.”
A few of the interviewees considered that they had been using a form of DevOps for a while before it
became a term, and then just called it CI. So when asked about complications in the implementation
of DevOps, over half of the interviewees said that they did not have any and that the process was very
straight forward. The interviewees that mentioned complications in the implementation specifically
talked about using the platforms associated with DevOps such as AWS and Azure, this mostly since
the term and platforms are still quite new and therefore not tested nor denoted enough.
Even though the term perceived to be untested and not documented enough, all participants in the
interview said that they would implement DevOps. This said with the following quotes:
”I would definitely implement it [DevOps] since it gives a greater understanding of the overall
picture.”
”Absolutely that I would implement it [DevOps], but you have to make sure that the company
is mature enough to implement it.”
A few however added to this that a key factor for them, whether or not to implement DevOps, was if
there was a possibility for platforms like AWS to be used as said in this quote:
”I would implement it [DevOps], but you have to make sure that everybody understands how
it works so I would want to use a platform like AWS so it gets easier for operations.”
6.2 Involvement in the DevOps Process
For this theme the interviewees explained more how their DevOps process was set up at their company.
Who were responsible for what and did they have specific teams in which their responsibility roles
belonged to?
In the majority of the interviews the interviewee stated that they had a specific operations team, but
what the operations team did compared to the development team varied a lot in the interviews as well
as where the different teams were located opposite each other. Some of the interviewees did not even
know what their operations team did or had met them even though they used a DevOps mindset, while
others mentioned a close relation where they were one single team. In the interviews where specific
tasks the operations team had, the following was said:
”We are two people in the operations team and we take care of the deployments.”
23
Software Engineering using DevOps - a Silver Bullet?
”We have an operations team that take care of the databases and make sure that the test
and deployment environments are working.”
In the interviews where the interviewee mentioned that they did not have an operations team the
interviewee instead mentioned that they were switching roles daily between developer and operations
responsibilities. This stated by an interviewee:
”We are only developers that use DevOps so we do not have different teams. We basically
have different hats that we put on and become a role [developer, operations etc.]. If something
goes wrong in deployment we become an operations team.”
Two out of the ten interviewees said that they were in the operations team, but out of the remaining
eight interviewees three stated that they did not have a set operations team. They instead were
responsible for both development and deployment, thus both in the development and the operations
team. However important to point out is that for some interviewees assignments such as testing was
a clear operations team responsibility while for other interviewees it was seen as a clear development
team responsibility. This to underline that the lines between the development team and the operations
team does not have an universal regulation of what types of responsibilities belong to whom, and that
someone who sees themselves as a development team member might be seen as a operations team
member through another companies definitions of team responsibilities.
6.3 Automating Work
As the theme indicates the central discussion for this theme was automation. All interviewees said that
they had their work automated in combination with implementing DevOps but what was automated
was different between all the interviewees and companies. Some examples of automated work can be
seen in the following quotes:
”Almost all my work is automated with DevOps. I mostly monitor and develop some now
when the flows between every step are completely automated.”
”We are automating new stuff all the time. Releases are automated for example but we have
to put what was created in to production manually.”
In order to automate work almost all of the participants mentioned that they used a platform developed
to help a DevOps process. Most of the interviewees used AWS [2.2.1] but some used Azure [2.2.2], a few
in combination with tools like TFS or JIRA[2.2.3]. Those interviewees that did not mention any of the
24
Software Engineering using DevOps - a Silver Bullet?
platforms above either did not use a platform or had a platform that was created by the company, this
since their company was responsible for sensitive information that could not leave Swedish boarders.
Azure and AWS are American companies that either store information in America or in another country
where critical Swedish data can not be stored in case of leakage according to the interviewees as said
here:
”We use a lot of internal platforms that takes care of all the DevOps work. This since we
can not put things on cloud services due to security breach if the information we handle
crosses borders.”
These platforms allowed participants to get a lot of work automated, but some also mentioned the man-
ual processes and steps that came along with automating operations. Automating the entire operations
part or parts of it was the most common thing to automate and interviewees said the following:
”A lot of my work is automated. Although we have to put up and maintain all automated
processes manually.”
”Things that were not automated before are now but that has contributed to that other things
have become more manual.”
Manual work has been mentioned by several interviewees, though with negative remarks and has been
said to be one of the main reasons why a DevOps implementation was needed in the first place. The
following was said by two interviewees:
”’We can do everything better without anything manual’ was our main thought when we
decided to use DevOps. With the old way of doing things we had too many human errors
and with automation everything became more stable since everything was done the same way
every time instead of the human errors.”
”A lot of manually done work crashed since humans were mixing with things and did not do
every step the same way every time.”
6.4 Collaboration Between Teams with DevOps Implemented
The collaboration between people and teams was the main subject of this theme. One of the issues
discussed was how the friction between the development team and the operations team had changed
after the implementation of DevOps. Almost all interviewees said that they had had friction between
25
Software Engineering using DevOps - a Silver Bullet?
the two teams and that it was better now after a DevOps process and mindset had been implemented.
The following was said:
”When I came in to this project it was a lot of frictions since we felt like the development
team was not interested in what we [operations team] were doing, but everything has changed
now with DevOps”
”It did not work so good with all the manual deployments and so on, everybody just blamed
each other. Now with DevOps everybody is a part of everything and so the friction has
decreased.”
Those who did not state that it was friction before either said that nothing had changed due to that
”people are people so friction will always occur” or that the relations between the teams were good
before the implementation of DevOps and it has not become bad after. No one said that DevOps have
created more friction between the teams.
Furthermore was the question ”Is one of the teams prioritised in the usage of DevOps?” asked to the
interviewees. Six out of the ten interviewees said that they considered the development team to be
more prioritised with DevOps. All had different reasons for why they thought so, here follows a few:
”It’s harder to give the operations team members development assignments than it is for
developers to take operations assignments. The operation team could maybe be removed
completely, so development team is more prioritised in my meaning.”
”The operations team is a support team to the development team. The development team is
the main team so to say so it should be more prioritised.”
”The operations team disappears with all the platforms so the development team is priori-
tised.”
No one mentioned that they thought that the operations team is more prioritised with DevOps, the
remaining four people opine that there were no prioritising differences between the two teams what so
ever. The main reason stated for this was that they prioritised the teams depending on who needed to
be prioritised for the moment.
6.5 Effects of Implementing DevOps
In this last theme the general feeling before and results up to this point of implementing DevOps was
discussed. The interviewees were asked what their initial thought was when they heard that they were
26
Software Engineering using DevOps - a Silver Bullet?
going to use DevOps in their projects. Half of the asked interviewees said that they had a neutral feeling
about the DevOps implementation process. This either because it was an obvious implementation or
that they did not have a set point for the implementation and instead had a such a slow transformation
towards DevOps that it had no major effects on their feelings towards the change. The following quote
indicates the aforementioned:
”I did not know that we were going to use DevOps at a specific time, we all realised that we
were using it after a while when the term had become a thing.”
Just like the above quote indicates, that the DevOps process might had been used before it was a set
term, another interviewee mentioned that DevOps for them was just another term for the same things
they had been using before and therefore had a neutral feeling towards the implementation.
Three of the interviewees had a positive initial thought about implementing DevOps, mainly because
it was needed and nice to let platforms handle a lot of the work, while the remaining two interviewees
had a negative initial thought which one said the following about:
”I had to get used to transferring things over to the operations team which I did not have
daily contact with so I was no longer responsible for 100 per cent of my work. It feels like
using a black box.”
No matter the initial thought, all interviewees said that DevOps had brought along positive changes
to their projects. Most of the interviewees mentioned that it has to do with the automated steps and
so forth no more human errors. The implementation of DevOps has in many of the interviewees eyes
made their processes faster, with less errors and more stable. The following quotes underline that:
”There are major differences that has come gradually along the way. The biggest differ-
ence is the way we implement different processes and get feedback so we can change things
continuously. Everything goes a lot faster so we get more efficient.”
”You can no longer do things halfway, instead you have to do everything properly otherwise
a lot of errors will occur. Since we directly can get feedback we can solve a lot of errors as
they happen and we get fewer bugs since it is more test driven. Everything is faster.”
27
Software Engineering using DevOps - a Silver Bullet?
7 Discussion
The discussion is divided into the same themes as in the results, some with subsections in order to
deeper discuss topics within the themes. In the end, an overall discussion covering the results as a
whole can be found.
7.1 Interpretation and Implementation of DevOps
In the results it is seen that the interviewees were not united in the interpretation of DevOps and
its meaning. Three different explanations were brought up, which were mentioned more then once by
interviewees: own responsibility, continuous integration and automation. By having different interpre-
tations and explanations of the same term, it could have consequences when new teams are created,
both within the organisation and between organisations. This since the silos may still exist or arise due
to misunderstanding and underlying expectations of how the work is going to be done with DevOps
implemented. If different explanations are used, DevOps might instead of solving problems and binding
teams together, create confusion and disagreement within and between teams. An unified explanation
of DevOps could be of importance if DevOps is to be established as the current essential concept to
use.
7.1.1 The Developers Own Responsibility
The ”own responsibility” was the explanation that was used the most to describe DevOps. DevOps
seem to give at least developers more responsibility of the whole process, from creating the code to
launching it at a later stage. Both developers and those in the operations team responded that it was
developers that had gotten more responsibility for the process, and no one mentioned whether or not
the operations team also had gotten more responsibility. Is it beneficial or not that the developers cross
the line over to the operations side to take more charge of the product all the way? A possible benefit
with developers being more in charge of their work the whole process is that they can be more aware of
how the code respond at all times and thereby have the possibility to change it if needed. This would
indicate that they no longer ”throw their code over the wall” for the operations team to catch and
make something of, instead they would proceed with their code and would therefore also be in charge
for their code to work all the way. The developers expressed strongly in the interviews how much they
appreciated being a part of the entire process since this gave them more flexibility but also enhanced
28
Software Engineering using DevOps - a Silver Bullet?
their concern of the product. This could possible be the reason why the silos that has been there
before between the operations and development team has been reduced since the two teams now work
together on the same part of the process. The operations team no longer have to take responsibility for
something that they did not create. All this suggests that it eventually create an improved end product
and a better work environment for the both teams.
This sounds great, an improved product and more work satisfaction in the teams, so what could
be the downside about giving more responsibility to the developers. Well one interviewee mentioned
that they no longer have to go through another department in order to effect the process, they could
implement what they wanted and had access to more. The first warning flag about this is that with
more responsibility, more stress for each person can arise. In a world were stress (along with depression)
is the second largest cause of people taking time of sick from work [45] it is crucial to reduce factors for
stress, such as large responsibility at work. In case one developer at a company becomes responsible
for the entire process and consequently too much work, it could result in organisations losing essential
employees and so forth ground breaking work.
The other warning flag that arises with giving developers more responsibility, especially when it comes
to not having to go through another department, is the things that possibly could be missed. Earlier
this year (2018) a driverless test vehicle by Uber [23] was involved in a fatal pedestrian accident, and
when asked about this, Uber software developers and engineers stated that they had been struggling
with ethical concerns regarding algorithms they had created. The reason for this was discussed to be
the confusion of responsibility with no one to talk about this with. Due to this, the developers did
not really looking into ethical aspects while coding since it was not their main concern. [36] Sure this
could be argued to poor information within the company and that this is not true in all cases, but the
underlying fact here was that the developers only looked into the code that they were creating and did
not take in consideration the surrounding impacts. If a developer, or development team, is responsible
for everything from start to finish without having to go through other departments for quality check
of all aspects considered, this could have catastrophic results. With the rise of AI [1], this could go
as far as developers creating several Frankensteins monsters: ”A thing that becomes terrifying and
eventually destructive to its maker” [15]. In order to prevent this to happen, it can be argued that it
is of importance to have more specialists from different departments and with different views in charge
of a single product. ”Good thing that we combine two different teams with DevOps” you might think.
Yes, but not all interviewed people, said to be using DevOps, had two different teams in their project
29
Software Engineering using DevOps - a Silver Bullet?
but instead had the developers in charge of the operations responsibilities as well. If developers can
take over operations work with platforms like AWS and Azure, then the operations team might be
sorted out to save time and money. So a project of only developers will be created.
7.1.2 DevOps Used Before as Continuous Integration
Some interviewees said that they had been using DevOps before it became a term, but then called it
Continuous Integration (CI). Technology is constantly changing [16] so in order for companies to keep
up they usually also have to change the way they work. One question is though ”How much are they
really changing?”. Maybe all these terms, where both CI and DevOps are included, are basically the
same thing but with small changes. Or maybe even exactly the same things but with different names
to be more in time. This theory could be the base for a completely new study so this report will not
dig in to whether or not this is the case, instead let us consider the following: that maybe it is just
like the development of technology. When technology evolves, so does the way we work, and when we
have evolved far enough from one place it needs a new name. Since some said that they had been using
DevOps before it was a term, this explanation could not be too far off. Maybe teams saw that to only
use CI in their work did not work completely so they changed it to work for their needs, and so DevOps
was created. However, the term DevOps did not become a concept until someone brought it in to light.
Another reason worth bringing up is the psychology of new things. In an article by Belle Beth Cooper
it is mentioned that dopamine [18] is released when we are in contact with new things, no matter the
sense (sight, touch, smell and so on) [29]. So maybe this could all be a psychological way to get people
to think that work is more fun and then possibly also work more and better? Since new things releases
dopamine to the brain, a new methodology like DevOps, and any other new methodology to come,
could just be created to enjoy the way we work again. Dopamine releases even though we have been
doing the same thing for a while, but just because it has a new name it is the shiny new toy that is
(again) fun to play with.
7.1.3 Automation
The word automation, ”the use or introduction of automatic equipment in a manufacturing or other
process or facility” [5], may be used as an explanation for DevOps since all interviewees had had some
part of their project automated. The question though is whether teams automated their processes
when they started to use DevOps, or if they already had automated work and then had to come up
30
Software Engineering using DevOps - a Silver Bullet?
with the term DevOps, like discussed above. The connection however between automation and DevOps
is possibly just because automation seem to help break the silos between the development team and
the operations team. This since the automation does all the intermediary work and could therefore be
seen as the foundation of DevOps. How the automation has affected the teams work will be discussed
further down under ”Automating Work”.
7.1.4 Implementation of DevOps
All interviewees said that they would implement DevOps in new teams since it has helped in their work,
but some of them mentioned criteria for this to happen though. One of the interviewees mentioned
that the company has to be mature enough in order to implement it. How do you know if a company
is mature enough? What does a company need in order to be mature for DevOps? By looking at
Atlassians DevOps maturity model [11] it is possible to see some connections with Michael S. Cuppets
DevOps pillars mentioned in the background section [2]. The first step according to the maturity model
to a adequately mature company for DevOps is the people and culture. Here it is talked about to put
the people first, and if the people that work at the company is not ready to change, it could be hard
to implement DevOps. As mentioned earlier about culture, it is seen as the foundation for a successful
team and DevOps seem to need team work in order to reach its full potential. The second step is to
be more agile and work across teams with the project. Again this can be linked to Michael S. Cuppets
pillars where he talks about measurement and sharing. In this step, according to Atlassians maturity
model, teams need to work with feedback and learning across teams. In the following steps of the
maturity model, continuous integration is mentioned as well as DevOps automation platforms to help
the team reach its full DevOps potential, both which was mentioned by interviewees as descriptions of
DevOps. So from this it is possible to suggest that a company is sufficiently mature for DevOps if their
culture and people are ready for it. If you as a company has not laid out the right base before building
DevOps on it, it is highly possible that you encounter some obstacles. However, this is just a thesis and
nothing in the interviews stated that this was true and that culture had affected their process. On the
contrary, no one mention anything about culture having a connection to DevOps. Why this is, could
be because the mentality and culture is so grounded in everyday life so when asked about it, it does
not come to mind. It could also however be mainly because in the real work environments, DevOps
and culture is not connected as it is believed in the related research found online.
31
Software Engineering using DevOps - a Silver Bullet?
7.2 Involvement in the DevOps Process
When it came to involvement in the DevOps process, the interesting parts were how the development
and the operation team were collaborating, both responsibilities and locations, and how it worked if
the organisation did not have an operations team.
7.2.1 Establishment of the Development Team and the Operations Team
Most of the interviewees said that they had an operations team, however, the responsibilities and set
up of each teams vary a lot. Someone knew that they had an operation team, but they had never
met them, while another said that development and operations worked closely together in the same
team. Furthermore did the responsibilities differ between development and operations. Someone said
that operations was responsible for just deployment, while another mentioned that the operations team
were responsible for testing, databases and in the end also deployment environments. How is it possible
that they all say that they use DevOps, but otherwise there were no similarities? A possible reason for
this is that they are on the path of being a full DevOps team, but are only in the beginning of their
journey there. Another thinkable reason is similar to the previous section where there were different
definitions of DevOps as there is no real set way to do DevOps. At least not yet. DevOps might be such
a flowing term that just like animals evolved from one single cell in to different species, different ways
of using DevOps evolved from a single issue that was not solved with previous methodologies. The two
reasons mentioned here could be combined in the matter of that if all teams, or even team members,
have their own definition, they could all be on different stages of DevOps towards different objectives
with DevOps. Furthermore might this also be the reason why, as stated in results, someone who sees
themselves as a development team member might be seen as a operations team member through an-
other companies definitions of team responsibilities. All organisations has taken what they need from
DevOps and changed it to fit their structure and process, and there is no best practice [6] for DevOps.
Eventhough it seem to work to have different constellations, it can still bring consequences. That
an organisation still have an operations team, but not really knowing who they are and exactly what
they are doing, does not seem as the best way to go after reading Michael S. Cuppets DevOps pillars,
described in background[2]. He says that the culture is significantly important for DevOps and with
that the interaction between employees and departments. It is therefore interesting that the team who
are not talking to their operations team feel that they are working with DevOps implemented. Are
the silos gone even though they are not talking to each other, or have they just automated processes
32
Software Engineering using DevOps - a Silver Bullet?
which could be what DevOps is to them? Here again finding the problem with not having a common
explanation for what DevOps includes. It makes it impossible to say if their constellation is DevOps
or not. Nevertheless is communication seen as a fundamental part in DevOps, and by not talking to
each other could create problems in the process in the future. Furthermore could a universal under-
standing of what the development team do and what the operations team do would be handy. First,
as mentioned before, without an overall explanation, it could be a catalyst for confusion within and
between organisations, but it can also make it hard for the term ”DevOps” to someday receive a proper
definition. If it is not clear what responsibilities belongs to which team, it is difficult to understand
whether or not a team is using DevOps because it can easily be mixed up with other terms or just ”good
communication” between the teams. With this, we will forever be stuck in a grey zone of DevOps where
everybody can say that they have implemented DevOps and nobody really knows what that implies.
7.2.2 The Organisations with no Operations Team
Those teams who did not have an operations team, nor a specific person responsible for the operations
work said that they swapped between a development role and an operations role. This depending on
what area needed the attention. What positive and negative aspects this type of constellation could
bring to a process was discussed earlier in 7.1.1 and instead here it is possible to look at this from a
different aspect. It might be that this ”no operations team” way of working is not DevOps at all, but
instead something called NoOps. NoOps is the idea that an IT environment can be so automated that
there is no longer a requirement for a committed team to manage maintenance and other tasks usually
seen as operations [7]. This definition appears to be similar to what the interviewees explained apart
from that they said that they do some operation work if it is needed. However, as time goes by and
platforms develop, they might be able to automate even more operations parts and the only thing they
have to do is to maintain, so forth they will become a thorough NoOps team. Maybe DevOps is on
its way out and NoOps is the new way of working with more and more teams implementing automatic
processes on their operations segment in order to remove it completely. Something to keep in mind is,
as mentioned in the results and in the previous section, that ”the lines between the development team
and the operations team does not have an universal regulation of what types of responsibilities belong
to whom”, which suggests that an operations team for someone might not be considered an operations
team for someone else. So someone might call themselves developer in a team that are using NoOps
but is seen as an operations member for someone else and is therefore defined as a DevOps team and
vice versa. Because the DevOps world seem to be so undetermined, that definitions and rules vary,
33
Software Engineering using DevOps - a Silver Bullet?
it is difficult to set labels on people and processes to determine whether a process is DevOps or not.
This, as discussed before, have the risk to create confusion and possibly more disagreement between
employees then it was before DevOps came in to the market.
7.3 Automating Work
The results show that all interviewees had something automated and that it had been benificial. Though
the interviewees all had implemented different things, even if automating things are associated with
operations were common due to platforms. This implies that there are no specific automated thing that
helps the process the most nor that if a team wants to use DevOps they need a specific part automated.
Instead teams seem to have automated what they need automated and what they can automate for
the moment, and maybe a team does not need anything automated in order to be a DevOps team. It
however seems from the results that the operations parts are the easiest to automate. A lot of the jobs
we know today will be replaced by automated versions [28] so maybe it is not so strange that the work
of operations is on its way out with automation platforms. Though it seems for some of the interviewees
that when they automated some things, other things became manual, and that the work assignments
instead had shifted. One of the interviewees said that all previous work was now automated and that
now they had to maintain all the automated processes manually instead. So by just automating things
does not mean that a specific part of the project is taken care of, instead the worker has to take care
of other things that may be less stimulating. The automation might facilitate the process but it will
not remove the work completely. A possible future scenario, with automating processes included in
methods like DevOps, will not get us to work less, it will just take away the work that challenge and
inspire us daily.
7.3.1 Manual Work
One of the reasons why the interviewees wanted to automate work was because they considered manual
work to induce a lot of errors. The study results indicates that we are moving so fast in technology
that we need our processes to be fast in order to stay on the market. We can no longer risk and spend
time on human errors. Instead of spending time on time consuming amendment we decide to automate
so the processes are performed in a similar way every time. A computer is mostly more reliable then
a human because they do not (yet) need to eat or sleep and they usually do not have a bad day. It
is interesting to see how we humans are no longer sufficient and demise all our work to the machines
34
Software Engineering using DevOps - a Silver Bullet?
instead. Although, a question to ask ourselves if all the processes are automated: if the machine makes
an error, who gets blamed then? We can argue that all errors are human fundamentally, since so far
the programs and processes are written by a human, but should a human be blamed? In a world that is
evolving to become more technological than human, it is important not to loose the humanity by firing
people and putting blame where it should not belong just in order to be up to date on the market.
7.3.2 Platforms
In order to automate parts of the process several, but not all, of the interviewees have utilised platforms
and supporting tools. The type of platforms used varied between interviewees but the most common
ones were AWS and Azure for storage on the cloud, and those who did not use these as platforms said
that they had developed their own platforms in order to keep their information within the Swedish
boarders. This indicates that in order to do DevOps, you do not have to use specific platforms, and
that the organisations that decide to use existing services probably do it mainly because of simplicity.
When it comes to these platforms it can be suggested that the usage of platforms like AWS and Azure,
as well as supporting tools like TFS and JIRA, in some ways take over parts of the complexity. By
taking over parts from example operations, it can make the process less DevOps since the meaning of
DevOps can be seen as the collaboration between the two teams, so if one team disappears because of
platforms, should it then no longer be called DevOps but instead be called NoOps? Maybe, but since
there are yet no set definition, this way might also be DevOps depending on who is asked.
For some organisations in Sweden it seems to be necessary to create own DevOps platforms to fa-
cilitate the process. This since companies like Amazon, that owns AWS, and Microsoft, that owns
Azure, are based in America which means that American government can request to see all material
Amazon and Microsoft store, no matter where in the world the data is stored [2]. To create own plat-
forms could be both good and bad for organisations. Bad because they might miss out on new features,
big storage space and so on, while it is good since they can create platforms that work exactly for their
structure instead of having to fit into a specific template.
7.4 Collaboration Between Teams with DevOps Implemented
Overall was all interviewees united when it came to that DevOps had made changes to improve the
relationship between the development team and the operations team. What can be said from the
35
Software Engineering using DevOps - a Silver Bullet?
results is that the collaboration between the development team and the operations team has become
considerably improved since the implementation of DevOps but when it came to state which team is
prioritised in the DevOps process, the interviewees were divided.
7.4.1 Change in Team Collaboration with DevOps
For the connection between the two teams, one interviewee mentioned that before DevOps the devel-
opment team did not care about what operations did, but this has become much better now when they
are talking to each other. It is fascinating to see that implementing DevOps can have these results, and
from the interviews it seems to be because of what DevOps has brought to the table with automation
and continuous delivery combined with an overview of the project. What is not clearly mentioned is
what could be seen as a base of it all, communication. With DevOps, both teams had to get together
and set up the bridge between them in interest of making the processes faster. It can be argued that
DevOps was just the spark needed in order for the teams to talk to each other and see each others point
of view. This can be connected with what was presented before, regarding automation and removing
manual work, that people may think that the automation made everything better, to remove human
parts, but it might just be that the human part of talking to each other and working together is what
really makes DevOps successful. For those who said that DevOps had not made a change, either that
they had a good relationship between the teams before DevOps or that they still had some difficulties
between the teams, also mentioned the human aspect as the reason for this, that the connection was
either good between the teams or that it will always be some friction due to the integration of people.
Overall does this study result demonstrate that in order to get the best out of the DevOps process,
teams need to get together and work uniformly.
7.4.2 Team Prioritised in the DevOps Process
Six out of ten interviewees considered that the development team was more prioritised in the usage
of DevOps and the remaining four said that the teams were prioritised depending on who needed the
focus at the time. The reasons for these believes of prioritisation differed from person to person. One
stated that the development team can do the operations work but the operations team could not as
easily do the developers work, and so are the development team more prioritised since the operations
team can be removed completely. The reason for this assumption is not stated but it could be seen
from two aspects. The first is that the operations team is, as mediated, supernumerary in competence
and actually are there to assist the development team. If this is the case, the development team can
36
Software Engineering using DevOps - a Silver Bullet?
be seen as more prioritised since their work might be seen as more important and flexible. It could
for example be seen as ”no operations team needed without anything developed to operate on.” The
second aspect is that the development team might not see the worth and effort of the operations teams
work. Why this could be a reason might be because of attitude or even culture. That developers might
just seen as the more valuable party.
Another reason mentioned for DevOps being more development prioritised was that the platforms
used can ”take over” the operations work, that the automation created with platforms makes the op-
erations team unnecessary since it costs more time and money to have. It could though be seen the
other way around, that operations is more prioritised since these platforms facilitates for the operations
team so they can focus on more meaningful things, though this is not mentioned in the research but
an interesting thought if you are looking at it from the outside.
7.5 Effects of Implementing DevOps
All interviewees said that DevOps have brought along positive changes to their projects, but a positive
feeling might not have been the initial thought of using DevOps.
7.5.1 Initial Thought of Implementing DevOps
In the results it was shown that half of the interviewees had a neutral feeling about the implementation
of DevOps. What is interesting is that one of the interviewees mentioned that they realised after a
while that they were using DevOps. This indicates, like discussed before in section 7.1.2, that DevOps
might have been in usage before it became a term and that it maybe got a name because more and more
teams were using this way of working. A question to ask is what the teams called what they were using
before if they already used DevOps in some way? Also, why was it then necessary to name it DevOps if
they already was using something that was DevOps but with another name? Maybe it has to do with
being on the market by saying that they are also using DevOps or maybe it is simply because they did
not have a name for what they were using and when DevOps came they saw the similarities. This in
connection with that no real explanation and way of working have yet been found about DevOps, so
that those who say that they were using DevOps before might just have taken the term DevOps and
made it their own.
37
Software Engineering using DevOps - a Silver Bullet?
Some interviewees had a positive feeling about implementing DevOps due to the necessity of it, but
the remaining interviewees had a negative feeling about the implementation. An interviewee who was a
developer mentioned that it was not preferably to hand over things to the operations team, since they
in the development team did not have daily contact with operations. The developer did not like to no
longer be 100 per cent responsible for the work and to hand things over made it feel like a black box
where they had no clue of what was going on. This however sounds like the opposite of what has been
discussed to be DevOps, to talk to each other between the teams, to work together. This sound like
what they are using might not be DevOps, or that they are not using DevOps to its full potential yet.
It is nevertheless interesting to hear that some developers do not like to hand over things to operations
and that they want to be responsible for all the work. Perhaps it is because they feel like operations are
not doing as well of a job taking care of their creation as they are or it might be because they just have
not established how everything works between the two teams. The later is suggested to be the reason
in this case since the mention of ”black box”, but it seems that in order to be able to use DevOps the
best way, good teamwork between the development team and the operations team is necessary.
7.5.2 Changes in the Process by Using DevOps
Even though the initial thoughts as well as how they implemented DevOps differed between the in-
terviewees, all interviewees thought that DevOps had helped their processes. Most of the interviewees
mentioned that it was due to the removal of manual error and continuous feedback. So mainly the
reason why the interviewees thought that everything was better with DevOps was due to the imple-
mentation of automated steps. No one mentioned the relationship between the development team and
the operations team to be a major factor for the changes in the process. Almost like the positive change
between the teams was a bieffect of implementing DevOps and automating parts. It could be that way,
that communication came from automating things in DevOps, but it could also be that the good com-
munication helped the team automate necessary parts. Even though it is not said in the interviews,
the communication between the teams might play a bigger role in the changes then the interviewees
recognise. No matter the over all reason for DevOps being successful, it is no doubt according to the
study that DevOps have had a major impact on the processes in a very positive way.
38
Software Engineering using DevOps - a Silver Bullet?
7.6 General Discussion
The results implies that there are no real explanation of what DevOps is nor that there is a specific
way of doing DevOps. This may bring some difficulties when implementing DevOps since the people in
the teams might have different understanding of what DevOps involves. This might also create more
frustration within and between the teams than it was before the implementation of DevOps, unless it is
clarified in advance what DevOps mean to them. It also seem that DevOps can bring more responsibility
upon some people and that people need to be able to adopt to fast changes in the structure in order to
work with DevOps. The way of working with DevOps might then not be suitable for everybody since it
appears that DevOps require people that are flexible and appreciate team work. This can suggest that
the human attitude towards DevOps is the base of success within the field. Maybe that is why Jennifer
Davis [31], mentioned in related research, talks about culture as a main pillar in DevOps since culture
has to do with a group of peoples attitude towards different things. Nevertheless does it seem from
the results that different parts in team work and automation have worked wonders for the companies
processes. The keyword here is ”different” because maybe it is not the term DevOps that is the silver
bullet talked about, since there are no one bullet that works perfect for all, instead it is a bullet that
each team can take and make their own of. The possibility to take the term DevOps and use what is
needed for a particular team might be the answer to whether the silver bullet DevOps is what we all
need.
39
Software Engineering using DevOps - a Silver Bullet?
8 Conclusion
From this study it is possible to say that there is no one definition nor way to do DevOps. It is hard
to tell who are using DevOps and who might not be since there are no set explanation for the term.
DevOps seem to be different to each and every one of its users and everybody implements DevOps in
their own way. All interpretations mentioned to describe DevOps are all good explanations on their own
but together ”responsibility”, ”continuous integration” and ”automation” probably describe DevOps
the best. Moreover was the way the two teams were set up differently from organisation to organisation
and also this implies that there are no set way of doing DevOps. Instead since there are different needs
in the teams, the organisations decides to implement DevOps to suit their requests. Teams might be
on different stages in the DevOps process, but they could all be working towards different types of
DevOps. Furthermore might not all people interviewed in this study use DevOps but are rather using
something called NoOps, which is said to be when a team no longer really need an operations team due
to automation. This since some teams said that they do not have a team and instead switch between
the roles. However this can not be said to be true nor false since NoOps is not studied in this report
and that it, as mentioned, are supposedly different ways of doing DevOps.
One of the reasons why teams decided to implement DevOps was to remove the manual errors that
otherwise occurred. The interviewees had automated different things but they all said that it had
helped the process go faster. Manual work was seen as something that took resourses and was un-
wanted but by implementing automatic processes did not mean that the manual work was removed
completely. Instead the workers are left with assuring that the automated processes run, which could
imply that the work is no longer challenging and inspiring. Yet can it occur blaming on the human
part since the automation’s faults is initially created by the human who programmed it. Furthermore
does these automated processes, done by different platforms, also seem to take over some departments
work, here leaning towards the removal of the operations team. Even though DevOps indicate that
team work between the development team and the operations team is necessary, DevOps platforms can
now manage work that should be done by the operations team. This supposedly makes the operations
team redundant and costly. DevOps might with this be on the path on becoming NoOps, which could
have alarming consequences since there is major value in having different types of teams and people
discussing a single creation. Without the collaboration between different minds, products will be single
minded made and can loose vital information in the process.
40
Software Engineering using DevOps - a Silver Bullet?
The implementation of DevOps seem to have improved the relationship between the ones that had
a development team and an operations team. Interviewees mentioned that it was due to automation,
continuous delivery and a improved overview of the project, but not to be forgotten is the communi-
cation that can have been a contributing factor to the improved relationship. Mentioned in relation to
this was that for those who did not get a better connection between the two teams, or already had a
good connection, said it was mainly due to the interaction between people. The communication and
teamwork between the teams seem to be of importance in order to be a successful DevOps project. So
when asked whether or not a team was seen as prioritised it was interesting to hear that the develop-
ment team was seen as the top team. This possibly due to the need for something developed in order
to operate, operations seen as less competent since it is not as easy for them to take over developers
work as it is for developers to do operations work or even due to the attitude and culture towards
the different teams in the organisation. Platforms could also be a reason since many of the platforms
implemented are used to perform some of the operations work, but this could also indicate that the
operations team is more prioritised since they get facilitating platforms, but no interviewee mentioned
that they thought operations was seen as more prioritised. It was either the development team or a
change in prioritisation due to which team needed it at the time.
The initial thought about implementing DevOps also varied a lot between the interviewees but they all
said that implementing DevOps had brought changes to the process. Someone said they were positive
since an implementation was necessary, another said they were neutral because they had used something
like DevOps before so this was just another name, while a third was negative to the implementation
due to the distribution of tasks. Some developers seem to not like to share the responsibility for reasons
unknown to this study, but suggested that it has to do with poor communication and/or establishment
between the teams. Nevertheless have DevOps brought changes to the processes in a very positive
way where interviewees state that everything is faster and more stable. This mainly believed is due to
automation, but the initialisation of communications between the team should not be forgotten as a
possible major contributor as well.
All interviewees said that they would implement DevOps in a new team, but it is also said that an
organisation need to be mature enough in order to implement it. Its people, and with that culture,
should be flexible and promote team work in order for the organisation to be seen as mature enough
for DevOps. It is also seen from this study that it is of importance that a definition of DevOps needs
to be set within the team, otherwise conflict can occur due to different beliefs of what DevOps implies.
41
Software Engineering using DevOps - a Silver Bullet?
To conclude, communication both within and between the team could be seen of essence in order for
DevOps to bloom and if that core is set then platforms can facilitate the work. Even if the work can be
facilitated so much that an entire team can be seen as redundant to the process for some. Nevertheless
does it seem that the keyword in explaining DevOps is ”different” and that is because everybody in-
terviewed said different things about everything and no unity could be seen except for that everybody
likes what it has done to the process. DevOps as a singularity might not be the silver bullet we have
been looking for since there seem to be so many ways of doing DevOps. Instead DevOps could be seen
as multiple different types of silver bullets, made to work on multiple different types of constellations,
and that is what makes DevOps successful.
42
Software Engineering using DevOps - a Silver Bullet?
9 Future Work
This study only contains two interviews of people in the operations team. This made it harder to
discuss the effects of DevOps and results equally since it becomes heavily development sided. To have
more people from the operations team to be studied would give the research questions and findings a
better basis. Furthermore in order to broaden the study would interviews with people from other de-
partments, such as management, be interesting to study. This to get a better understanding of DevOps
at the entire company and to understand how DevOps has affected the part of the organisation that
is not directly working with DevOps. Other interesting groups to find interviewees at would be people
that work with back-end development. This was missing in this report and to interview and see the
back-end developers role in DevOps would be a good complement to the results. Questions like ”Are
back-end developers included in the development part in DevOps?” and ”How do the organisations and
teams work to get back-end development included in the DevOps process?” could be a strong starting
point.
Moreover would the similarities and differences between DevOps and other agile methods, such as
continuous delivery, be a valuable angle of incidence in order to see whether or not the theory of De-
vOps being basically the same thing as the other agile methods but with a different name. Lastly could
branches to DevOps like BizDevOps and NoOps be studied. This to see firstly, the differences between,
and secondly the development from DevOps and why companies decide to implement one or another
as well as where DevOps is headed.
43
Software Engineering using DevOps - a Silver Bullet?
10 References
[1] “Ai (artificial intelligence),”
https://searchenterpriseai.techtarget.com/definition/AI-Artificial-Intelligence, [Accessed: 2018-11-
27].
[2] “American law cloud act,”
https://www.safespring.com/blogg/cloud act/, [Accessed: 2018-12-13].
[3] “Azure devops,”
https://azure.microsoft.com/en-us/services/devops/, [Accessed: 2019-01-07].
[4] “Definition agile,”
https://en.oxforddictionaries.com/definition/agile, [Accessed: 2018-09-07].
[5] “Definition automation,”
https://en.oxforddictionaries.com/definition/automation, [Accessed: 2018-09-11].
[6] “Definition best practice,”
https://searchsoftwarequality.techtarget.com/definition/best-practice, [Accessed: 2018-11-30].
[7] “Definition noops,”
https://searchcloudapplications.techtarget.com/definition/noops, [Accessed: 2018-12-13].
[8] “Definition of ’waterfall model’,”
https://economictimes.indiatimes.com/definition/waterfall-model, [Accessed: 2018-11-19].
[9] “Devops and aws,”
https://aws.amazon.com/devops/, [Accessed: 2018-11-19].
[10] “Devops: Breaking the development-operations barrier,”
https://www.atlassian.com/devops, [Accessed: 2019-01-14].
[11] “Devops maturity model,”
https://www.atlassian.com/devops/maturity-model, [Accessed: 2018-11-28].
[12] “Devops research and assesment,”
https://devops-research.com/, [Accessed: 2018-09-07].
44
Software Engineering using DevOps - a Silver Bullet?
[13] “Extent of devops adoption by software developers worldwide in 2017 and 2018,”
https://www.statista.com/statistics/673505/worldwide-software-development-survey-devops-adoption/,
[Accessed: 2018-09-07].
[14] “Figure 1,”
https://upload.wikimedia.org/wikipedia/commons/0/05/Devops-toolchain.svg, [Accessed: 2018-
09-24].
[15] “Frankenstein,”
https://en.oxforddictionaries.com/definition/frankenstein, [Accessed: 2018-11-27].
[16] “It over time,”
https://www.washingtonpost.com/graphics/2017/entertainment/tech-generations/?noredirect=
on&utm term=.c79b62cf9aaf, [Accessed: 2018-10-19].
[17] “Jira,”
https://www.atlassian.com/software/jira, [Accessed: 2019-01-14].
[18] “Medical definition of dopamine,”
https://www.medicinenet.com/script/main/art.asp?articlekey=14345, [Accessed: 2018-11-27].
[19] “Microsoft azure,”
https://azure.microsoft.com/en-us/overview/what-is-azure/, [Accessed: 2019-01-07].
[20] “Omegapoint,”
https://omegapoint.se/, [Accessed: 2018-09-21].
[21] “Puppet,”
https://puppet.com/, [Accessed: 2018-09-07].
[22] “Team foundation server,”
https://visualstudio.microsoft.com/tfs/, [Accessed: 2019-01-14].
[23] “Uber,”
https://www.uber.com/about/, [Accessed: 2018-11-27].
[24] “What is devops?”
https://newrelic.com/devops/what-is-devops, [Accessed: 2018-09-07].
[25] “What is workflow,”
https://www.process.st/what-is-a-workflow/, [Accessed: 2018-09-24].
45
Software Engineering using DevOps - a Silver Bullet?
[26] “How to evaluate eis,” eVALUEd, 2006,
http://www.evalued.bcu.ac.uk/tutorial/4c.htm, [Accessed: 2018-09-21].
[27] J. Attride-Stirling, “Thematic networks: an analytic tool for qualitative research,” Qualitative
research, vol. 1, no. 3, pp. 385–405, 2001.
[28] C. Benedikt Fey and M. A Osborne, “The future of employ-
ment: how susceptible are jobs to computerisation?” Oxfordmartin)
https://www.oxfordmartin.ox.ac.uk/downloads/academic/TheFutureofEmployment.pdf, 2013.
[29] B. B. Cooper, “Novelty and the brain: Why new things make us feel so good,” Lifehacker)
https://lifehacker.com/novelty-and-the-brain-why-new-things-make-us-feel-so-g-508983802, 2013.
[30] M. Cuppett, “Devops, dbas, and dbaas: Managing data platforms to support continuous integra-
tion,” Apress, Dec 13, 2016.
[31] J. Davis, “Effective devops: Building a culture of collaboration, affinity and tooling at scale,”
O’Reilly Media, Inc, 2016.
[32] P. Dawnson, “Managing change, creativity innovation. 2nd edition,” Sage, 2014.
[33] D. Denison, “Corporate culture and organizational effectiveness.” John Wiley Sons, Oxford 1990.
[34] D. N. Forsgren, “2016 state of devops,” Puppet and DORA, 2016,
https://puppet.com/resources/whitepaper/2016-state-devops-report/thank-you, [Accessed: 2018-
09-07].
[35] M. Fowler and M. Foemmel, “Continuous integration,” Thought-Works) http://www. thoughtworks.
com/Continuous Integration. pdf, vol. 122, p. 14, 2006.
[36] B. C. Gain, “Devops ethics: The danger of unethical code,” DevOps) https://devops.com/devops-
ethics-the-danger-of-unethical-code/, 2018.
[37] M. Huttermann, “Devops for developers,” Springer Science and Business Media, New York 2012.
[38] S. Metzger, “eddy4r 0.2.0: a devops model for community-extensible processing and analysis of
eddy-covariance data based on r, git, docker, and hdf5,” Geoscientific Model Development, 2017,
https://www.geosci-model-dev.net/10/3189/2017/, [Accessed: 2018-09-07].
[39] A. Onwuegbuzie, “Validity and qualitative research: An oxymoron?” Springer, 2006.
46
Software Engineering using DevOps - a Silver Bullet?
[40] A. D. Rayome, “How to implement devops: 5 tips for doing it right,” ZDNET)
https://www.zdnet.com/article/how-to-implement-devops-5-tips-for-doing-it-right/, 2017.
[41] A. Shenton, “Strategies for ensuring trustworthiness in qualitative research projects,” Division of
Information and Communication Studies, School of Informatics, 2004,
https://pdfs.semanticscholar.org/452e/3393e3ecc34f913e8c49d8faf19b9f89b75d.pdf, [Accessed:
2018-09-20].
[42] M. Skelton and M. Pais, “What team structure is right for devops to flourish?” DevOpsTopologies)
https://web.devopstopologies.com/, 2016.
[43] J. Smith, “Beyond the divide between cognition and discourse: using interpretative phenomeno-
logical analysis in health psychology,” Psychol Health, 1996,
https://www.tandfonline.com/doi/abs/10.1080/08870449608400256, [Accessed: 2018-09-20].
[44] J. Sutton, “Qualitative research: Data collection, analysis, and management,” The Canadian
Journal of Hospital Pharmacy, 2015,
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4485510/, [Accessed: 2018-09-20].
[45] M. Thompson, “The growing problem of depression and stress,” The Telegraph)
https://www.telegraph.co.uk/news/uknews/1553558/The-growing-problem-of-depression-and-
stress.html, 2007.
47