Software Engineering using DevOps- a Silver Bullet?

(1)

Software Engineering using DevOps - a Silver Bullet?

Mikaela Eriksson

(2)

(3)

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

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.

Handledare: Maryam Alizadeh

(4)

(5)

Sammanfattning

Idag har vi teknik som hjälper oss att skanna miljontals medicinska databaser p˚a ett ögonblick och självkörande bilar som är bättre än oss p˚a att köra bil. Tekniken utvecklas s˚a snabbt att nya uppdateringar i teknikvärlden är vardagsmat, och vi blir lätt frustrerade om n˚agot inte g˚ar i den höga hastigheten vi förväntar oss. Tekniken rör sig s˚a snabbt nuförtiden och för att vi människor ska kunna följa med i den utveckling som behövs inom tekniken, har olika metoder för hur man optimerar utvecklingsprocesser tillämpats. Men lika snabbt som tekniken ändras, förändras de metoder som används med dem. Nyligen har en ny term inom metoder uppkommit. Denna term sägs ge snabbare implementering, färre misslyckanden och förbättrad lojalitet inom team. Termen i fr˚aga kallas DevOps.

Denna studie handlar om att dyka ner i DevOps värld för att utforska om termen är den silverkula som det p˚avisar sig vara. Studien är baserad p˚a tio intervjuer med personer fr˚an olika organisationer som sagt att de använder DevOps och har som m˚al att ta reda p˚a hur dessa intervjuade använder och upplever DevOps. Funnet i dessa intervjuer är att b˚ade inblandning i, tolkning och genomförande av termen varierar mellan de intervjuade. Ingenting som sas var det samma mellan intervjuerna. Alla intervjuade var mycket positiva över att ha implementerat DevOps, vad det bi- dragit med till processer och skulle definitivt implementera DevOps i nya team. Men det kan ocks˚a konstateras att utvecklingen i organisationer är p˚aväg mot att bli mer enkelsinnad. Vid skapande och reformering av team utesluter organisationer hellre konstellationer av olika mänskliga tankar och avdelningar för att istället förlita sig p˚a olika utvecklingsplattformar. Slutsatsen är att DevOps kan orsaka att team tar bort samarbete mellan människor till förm˚an för den hastighet de uppn˚ar i tekniken. Detta är potentiellt alarmerande d˚a enformiga team kan missa viktiga aspekter i sin utveckling vilket kan leda till allvarliga konsekvenser. Även om detta kan vara en sanning s˚a ses DevOps som n˚agot mycket positivt och kan änd˚a vara den silverkulan som det talas om att det ska vara, men enbart om varje team kan tolka det, implementera det och använda det p˚a sitt eget sätt.

(6)

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

(7)

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 organisations 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?

(10)

• 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?

(11)

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 H¨utterman [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]

(12)

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.

(13)

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.

(14)

• 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

(15)

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

(16)

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.

(17)

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

(18)

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 H¨uttermann 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 H¨uttermanns 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 organisation 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.

(19)

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.

(20)

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.

(21)

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.

(22)

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 interview, 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 implementation 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?

(23)

• 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

(24)

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.

(25)

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 explanation 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

(26)

interviews equivalent to DevOps or stated as the following:

”Automating everything [in the process] through continuous integration.”

A few of the interviewees considered that they had been using a form of DevOps for a while before it became a term, and then just called it CI. So when asked about complications in the implementation of DevOps, over half of the interviewees said that they did not have any and that the process was very straight forward. The interviewees that mentioned complications in the implementation specifically talked about using the platforms associated with DevOps such as AWS and Azure, this mostly since the term and platforms are still quite new and therefore not tested nor denoted enough.

Even though the term perceived to be untested and not documented enough, all participants in the interview said that they would implement DevOps. This said with the following quotes:

”I would definitely implement it [DevOps] since it gives a greater understanding of the overall picture.”

”Absolutely that I would implement it [DevOps], but you have to make sure that the company is mature enough to implement it.”

A few however added to this that a key factor for them, whether or not to implement DevOps, was if there was a possibility for platforms like AWS to be used as said in this quote:

”I would implement it [DevOps], but you have to make sure that everybody understands how it works so I would want to use a platform like AWS so it gets easier for operations.”

6.2 Involvement in the DevOps Process

For this theme the interviewees explained more how their DevOps process was set up at their company.

Who were responsible for what and did they have specific teams in which their responsibility roles belonged to?

In the majority of the interviews the interviewee stated that they had a specific operations team, but what the operations team did compared to the development team varied a lot in the interviews as well as where the different teams were located opposite each other. Some of the interviewees did not even know what their operations team did or had met them even though they used a DevOps mindset, while others mentioned a close relation where they were one single team. In the interviews where specific tasks the operations team had, the following was said:

”We are two people in the operations team and we take care of the deployments.”

(27)

”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

(28)

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 manual processes and steps that came along with automating operations. Automating the entire operations part or parts of it was the most common thing to automate and interviewees said the following:

”A lot of my work is automated. Although we have to put up and maintain all automated processes manually.”

”Things that were not automated before are now but that has contributed to that other things have become more manual.”

Manual work has been mentioned by several interviewees, though with negative remarks and has been said to be one of the main reasons why a DevOps implementation was needed in the first place. The following was said by two interviewees:

”’We can do everything better without anything manual’ was our main thought when we decided to use DevOps. With the old way of doing things we had too many human errors and with automation everything became more stable since everything was done the same way every time instead of the human errors.”

”A lot of manually done work crashed since humans were mixing with things and did not do every step the same way every time.”

6.4 Collaboration Between Teams with DevOps Implemented

The collaboration between people and teams was the main subject of this theme. One of the issues discussed was how the friction between the development team and the operations team had changed after the implementation of DevOps. Almost all interviewees said that they had had friction between

(29)

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

No one mentioned that they thought that the operations team is more prioritised with DevOps, the remaining four people opine that there were no prioritising differences between the two teams what so ever. The main reason stated for this was that they prioritised the teams depending on who needed to be prioritised for the moment.

6.5 Effects of Implementing DevOps

In this last theme the general feeling before and results up to this point of implementing DevOps was discussed. The interviewees were asked what their initial thought was when they heard that they were

(30)

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

(31)

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 interpretations 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

(32)

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

Software Engineering using DevOps- a Silver Bullet?