Software Engineering using DevOps - a Silver...

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


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


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


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


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.3 Automating Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


4



7 Discussion 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.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.1 Change in Team Collaboration with DevOps . . . . . . . . . . . . . . . . . . . . 36

7.4.2 Team Prioritised in the DevOps Process . . . . . . . . . . . . . . . . . . . . . . . 36


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


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


• 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


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


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


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


• 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


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


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


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


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


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


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


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


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


• 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


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


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.


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


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.”


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


”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


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.”


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


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.


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


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


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.


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


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


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


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



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


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


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


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.


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


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


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.


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


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


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


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


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


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


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


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

https://searchenterpriseai.techtarget.com/definition/AI-Artificial-Intelligence

https://www.safespring.com/blogg/cloud_act/

https://azure.microsoft.com/en-us/services/devops/

https://en.oxforddictionaries.com/definition/agile

https://en.oxforddictionaries.com/definition/automation

https://searchsoftwarequality.techtarget.com/definition/best-practice

https://searchcloudapplications.techtarget.com/definition/noops

https://economictimes.indiatimes.com/definition/waterfall-model

https://aws.amazon.com/devops/

https://www.atlassian.com/devops

https://www.atlassian.com/devops/maturity-model

https://devops-research.com/


[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

https://www.statista.com/statistics/673505/worldwide-software-development-survey-devops-adoption/

https://upload.wikimedia.org/wikipedia/commons/0/05/Devops-toolchain.svg

https://en.oxforddictionaries.com/definition/frankenstein

https://www.washingtonpost.com/graphics/2017/entertainment/tech-generations/?noredirect=on&utm_term=.c79b62cf9aaf

https://www.washingtonpost.com/graphics/2017/entertainment/tech-generations/?noredirect=on&utm_term=.c79b62cf9aaf

https://www.atlassian.com/software/jira

https://www.medicinenet.com/script/main/art.asp?articlekey=14345

https://azure.microsoft.com/en-us/overview/what-is-azure/

https://omegapoint.se/

https://puppet.com/

https://visualstudio.microsoft.com/tfs/

https://www.uber.com/about/

https://newrelic.com/devops/what-is-devops

https://www.process.st/what-is-a-workflow/


[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

http://www.evalued.bcu.ac.uk/tutorial/4c.htm

https://puppet.com/resources/whitepaper/2016-state-devops-report/thank-you

https://www.geosci-model-dev.net/10/3189/2017/


[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

https://pdfs.semanticscholar.org/452e/3393e3ecc34f913e8c49d8faf19b9f89b75d.pdf

https://www.tandfonline.com/doi/abs/10.1080/08870449608400256

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4485510/

Software Engineering using DevOps - a Silver...

Documents

Transcript of Software Engineering using DevOps - a Silver...