implementation of a continuous integra- tion pipeline at ...implementation of a continuous...

Department of Computer Science at

Friedrich-Schiller-University Jena

Implementation of a continuous integra-tion pipeline at Carl Zeiss AG

Master's Thesis

submitted for the degree of

Master in Computer Science

submitted by

Vaso Diakonidze

supervised by

Prof. Dr. Birgitta König-Ries,

Michael Orthey

Dirk Hendel

PhD Candidate Sirko Schindler

January 13, 2018

Abstract

The tremendous growth of complex software requirements with short de-

velopment cycles has been discussed widely in the last decades and has led

to the development of new software engineering methods. One approach

to cope with these issues is a continuous integration process. It tries to im-

prove the productivity and transparency of software development.

The goal of this thesis is the elaboration of an automated software develop-

ment process, which enhances the daily productivity and simplifies com-

munication between project managers, team members, customers and ot-

her stakeholders. Furthermore, it simplifies projects by making them more

transparent, prevents errors by continuous testing and enables developers

to deploy their work in proper time.

For the purposes of our research, the software development process of the

Carl Zeiss AG is analysed. The thesis consists of three parts, starting with

the interviews that we conducted with the participants within the software

development process, followed by the analysis of one particular project, and

closes with the proposal of new comprehensive architecture, that can foster

productivity and create much more collaborative working environment.

Author’s Statement

I hereby certify that I have prepared this diploma thesis independently, and that only

those sources, aids and advisors that are duly noted herein have been used and / or

consulted.

January 13, 2018

Vaso Diakonidze

Acknowledgements

Foremost, I would like to express my sincere gratitude to my supervisor Prof. Dr. Bir-

gitta König-Ries for providing invaluable feedback and continuous support.

I would also like to thank my supervisor Michael Orthey, his guidance helped me in all

the time of research and writing of this thesis.

Furthermore, if there were no continuous encouragement from Dirk Hendel his ideas,

writing the thesis would have been unimaginably daunting.

I would also like to express many thanks to the PhD candidate Sirko Schindler who

also played a key role by supporting and helping me coordinating the whole project.

His patience, motivation, enthusiasm, and immense knowledge requires admiration.

Last but not least, I would like to thank all the members of the software development

team and managers in Carl Zeiss AG for all their help and assistance.

Contents

1 The Problem of Delivering Software 1

1.1 Manual software deployment . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Making the software development process automated . . . . . . . . . . . 2

1.2.1 All changes must trigger the feedback process . . . . . . . . . . . 3

1.2.2 The feedback must be received as soon as possible . . . . . . . . . 4

1.2.3 Reducing Errors -test code commits automatically . . . . . . . . . 4

1.2.4 Productivity and Efficiency for Reliable Releases . . . . . . . . . . 6

1.2.5 Customer satisfaction with quality improve . . . . . . . . . . . . 7

1.3 Principles of Software Delivery . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Related Work 11

2.1 Agile Software Development . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Continuouse integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Definition foundation . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Tooling support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Analysis of the current state 23

3.1 Important aspects when designing interviews . . . . . . . . . . . . . . . 23

3.2 Important aspects of effective interview questions . . . . . . . . . . . . . 24

3.3 Interview result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Summary of the current project . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Tools for fully automated process 33

4.1 Jira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Bamboo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.2 Bitbucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

x Contents

4.1.3 Crucible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.4 FishEye . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.5 HipChat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.6 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.7 Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Proposed architecture 41

5.1 Track your requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Create separate branches and label them with the issue number . . . . . 44

5.3 Develop on our branch with continuous integration . . . . . . . . . . . . 44

5.4 Create a pull request for the branch . . . . . . . . . . . . . . . . . . . . . . 44

5.5 Merge, package as a release and deploy to staging . . . . . . . . . . . . . 46

5.6 Manage to deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.7 How to start to use new tools . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.7.1 Which devices fulfill these criteria? . . . . . . . . . . . . . . . . . . 48

5.7.2 Continuous integration solution or development solution . . . . 49

6 Evaluation 51

7 Conclusion 55

8 Appendix 57

8.1 Questions for Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.2 Questions for project managers . . . . . . . . . . . . . . . . . . . . . . . . 58

References 59

List of Figures 63

Contents xi

CHAPTER 1

The Problem of Delivering Software

One of the most important question for software professionals is as follows: How do

we deliver software to users as quickly as possible?

There are many software development methodologies, which influences on the deve-

lopment work.

In most cases, the steps for software development process are defined. But the question

is how these steps join together? How could we enable developers, testers, internal and

external stakeholders and project managers, to collaborate effectively?

The idea of software development pipeline is to get software from development to re-

lease. As authors Jez Humble and David Farley [HF10] said: “A deployment pipeline

is, in essence, an automated implementation of your application’s build, deploy, test,

and release process”. Every software development company has different deployment

pipelines at work, which depends on their aim. Figure 1.1 shows a general illustra-

tion of all key elements of the deployment pipeline.The pipeline starts with the commit

stage which is entered once development has been completed. Here, executable code

is produced, compiled, analyzed and built installers. It is followed, by several testing

steps focusing on different aspects. Once installers are built, software is released.

Figure 1.1: Deployment pipeline (from [HF10]).

2 The Problem of Delivering Software

1.1 Manual software deployment

Many companies have a manual software release process. This means that the steps

are required separately, each performed manually by an individual or team.The out-

come of such kind of environment is unpredictable. Sometimes may appear unforeseen

problems. During the manual software deployment process, release needs more time

compared to an automated deployment process. When the deployments are not fully

automated, it is hard to find the causes of errors. Also, the question is, whether the

problems are significant or not? Even after the best deployment test, some bugs can

remain hidden [HF10].

Moreover, after release, developer team members try to make the software operative

and find out where the problem was. [HF10]. The main anti-patterns are:

• Different connection pool settings.

• The filesystems are in various layouts.

• Development team must answer the question why a deployment is going wrong

and software not done in a proper time, but they have no answer.

• The reliance on manual testing to confirm that the software will run correctly after

the release.

• The documentation that describes the deployment steps contains errors.

Most of the errors which could be the problems during the software development pro-

cess we can avoid with an automated process. We will explain in details chapter 2 why

the automated deployment process is essential to our goal.

1.2 Making the software development process automated

Apparently, the software professional’s goal is to deliver software to users as quickly as

possible. They are only paid once their software is released.The most important team

aim must be to determine a good solution for software development process, at the

same time reduce cycle time and find the bug as much as possible to fixed it. If the

software deployment steps are manual, every time there will be differences regarding

of the software changes, system configuration, the environments, and the result of the

release process. It implies that software developers have no chance to gain control over

the release process and hence to guarantee high quality. The steps for software deve-

lopment process should be an engineering discipline [HF10].

1.2 Making the software development process automated 3

The second important aspect of the automated process is frequency. If the release is

frequent, the differences between releases will be small. That makes the process easier

to roll back work and incorporate feedback into the product as quickly as possible. For

the automated release, continuous feedback is the standard process. There are, howe-

ver, some important criteria that Jez Humble and David Farley describe for feedback to

be useful [HF10] .

• Any changes need to trigger the feedback.

• feedback must be provided as soon as possible.

• the delivery team must receive feedback and act on it.

1.2.1 All changes must trigger the feedback process

A Software application is based on four components, such as executable code, configu-

ration, host environment, and data. When one of these elements change, it will modify

the behavior of the whole application. Hence, it follows that we have to ensure that a

change in any of them is verified carefully. Whenever the source code is changed, the

result must be built and tested. If you want to observe and gain control over this pro-

cess, you should make it automated. The process which continuously builds and tests

is known as the Continuous Integration [HF10]. This process will be described in more

details in chapter 2. Changes in the operating system configuration, the network con-

figuration, all infrastructure and external systems should be tested. The tests always

depend on the system, but the most fundamental practices are defined below[HF10].

• For the verification that the syntax of the source code is valid, the process must

be able to successfully build an executable.

• Unit tests must pass. This will check, whether the software works as expected.

• The quality criteria must be fulfilled for the software.

• The software functional acceptance tests must pass. This approach tells you that

your application suits your business criteria, which delivers the business purpose.

• Nonfunctional tests must pass. That shows that the security, availability, capacity,

and fulfills the owner’s wishes.

• Manual testing gives the product owner an overview, whether there are still bugs

that require fixing and should be covered by automated tests.

The tests must be as close as possible to the production environment, which gives the

chance to prove that the changes to our environments have not altered the software


ability to work.

1.2.2 The feedback must be received as soon as possible

The ability to get fast feedback and act on it depends on the automatization process.

During the automatization process, the company only needs the amount of hardware

that will enable creating fully automated process [HF10]. Using a manual process all

these jobs, build, test and deployment process will take longer. In another words you

depend on the team to get the job done, which is unpleasant work for most of them.

Furthermore, this results in higher costs for the company. Regarding the Figure 1.1 tests

can be characterized in the commit stage of the pipeline as follows.

• They run fast.

• Code is complete. Which gives the chance to understand very easily.

• If test fail, it means that we have the critical situation and it should not be released.

A major aspect of feedback process is to pay attention how the version control system

is used, and how the code is organized. Developers must commit the code changes in

version control system as much as possible. Which allow us to test every new commit.

It is obvious that cost savings for companies are not primary issues, it is also important

to deliver their products in proper time [HF10] . Beyond that, there are many advan-

tages.The ability to easily deploy any version of the software into any environment is

one example. Usually, several different versions of the same software are running in a

separate environments. This kind of process gives a chance the developers to see which

builds are available to be deployed into the environment. The collaborate work can be

made more efficiently because they do not need that much time waiting for good builds

to be pushing them [HF10].

1.2.3 Reducing Errors -test code commits automatically

Developers will be notified by feedback from the code commit stage after they check in

their code.The software configuration management stage triggers automatically. This

step compiles the source code and performs the unit tests. If the step fails and shows

errors, the pipeline will stop, and notifications will be sent to the software developers.

After the bug is fixed the stage triggers again and again until everything passes the

tests. The continues delivery pipeline will then automatically move to the next stage

[Che15].

1.2 Making the software development process automated 5

Figure 1.2: The CD pipeline’s (from [Che15]).

The build stage is the step where the Unit test is executed to generate a code coverage

report. At this also integration tests and different static code analyses are performed.

All this analysis is a precondition to build the artifacts necessary for a release. The ar-

tifacts will be uploaded to the repository which will be used afterward for deployment

or distribution [Che15]. The automated software delivery idea is generally based on

the continuous software testing process. Figure 1.2 shows that all these steps are im-

portant to deliver our products on production stage with minimal risks. One of the

most important issue for software developers during the automated software develop-

ment process is to get the feedback quickly as soon as possible. Because such kinds of

possibility improve productivity and efficiency significantly.

The acceptance test stage is mainly responsible that the software meets all defined user

requirements. The pipeline creates the test environment similar to a production envi-

ronment and deployed to it. The fully automated process is more comfortable for de-

velopers because of, they do not need to create test environment manually; the pipeline

automatically sets up the environment for acceptance test in a few minutes [Che15].

Similarly to other stages the pipeline in case of errors stops and automatically notifies

the developers regarding the problems. Otherwise, it moves to another stage.

Performance Testing does not happen during the development, it will only be exe-

cuted before the final release. The pipeline sets up a test environment and gives all

information to the software that centrally maintains software quality. Hence it follows

that the developers can get feedback quickly if the code has errors. Fixing bugs and

diagnosis will be easier and cheaper before a release than after [Che15].

Without continuous delivery manual testing is required to set up a manual testing en-

vironment. With CD, they do not need to care about this.The pipeline automatically

sets up the test environment and sends the required information for accessing the de-

ployed application to the testing team. When the tests are over, the set of artifacts is


promoted to a potential release candidate. This means that the quality checks passed

and the product is ready to be deployed to the production stage.

1.2.4 Productivity and E�ciency for Reliable Releases

Durig the automated process, the CD pipeline automatically sets up the environment.

Hence it follows that the productivity and efficiency also will improve. During the auto-

mated software delivery process, you only need to click a button [Che15] . The general

goal of developers is to reduce risks before as much as possible possible goes to the live

server. As we said the software codes will be tested regularly before it goes to the live

server.Most significant errors will be discovered and fixed by the team beforehand (See

Figure 1.3). Nevertheless, if some hidden errors are not found, the automated pipline

can automatically roll back a release [Che15].

Figure 1.3: Automatically roll back (from [HF10] ).

1.3 Principles of Software Delivery 7

1.2.5 Customer satisfaction with quality improve

As the Mojtaba Shahin and Muhammad Ali Babar [SBZ17] said, observations show that

due to the automated software development the product quality has improved consi-

derably. With continues software test the errors are discovered and get fixed, which

results faster releases in a matter of days. During automated software delivery practice,

we are trying to reduce errors until production stage. Also, frequent releases give the

opportunity to software developers to use quick feedback from the users. Continuous

software tests during the development process reduce risks in the code which by itself

increase consumer satisfaction[SBZ17].

1.3 Principles of Software Delivery

In this section there are some important issues of software delivery process that we can

not ignore during the software development process.

When we are building a massive software project, the complexity is evident, but so-

mehow people are not good at controlling complexity. But they are good in finding

solutions for problems in a critical situation. One approach for reducing complexity is

to partition a system into many parts. Each part represents a subsystem that includes

everything for performance. Such kind of technique gives the team possibility to cont-

rol divided parts easily.

As the Jez Humble and David Farley [HF10] says “The repeatability and reliability de-

rive from two principles: automate almost everything, and keep everything you need

to build, deploy, test, and release your application in version control”.

Deploying the software eventually includes three things:

• Hardware configuration, software configuration, infrastructure, and external ser-

vices.

• Installation of the correct application

• Configuration of the application regarding your requirements.

The deployment process of the application can use a fully automated process from ver-

sion control. Application configuration also can be fully automated with scripts in a

version control system.

Automation is an essential for deployment pipeline because it is the only way to push

a button. Nevertheless, most of the software developers do not try to automate the re-


lease process; they think that it is not safe [HF10]. The software development company

must promote automatization as much as possible. For example acceptance test, up-

grade and downgrade, and also you can automate network and firewall configuration,

etc. Practice [HF10] shows that at the beginning you do not need to automate every-

thing. You have to pay attention to your build, deploy, test and release process, and

you can automate continuously over time.

The version control system is the place where you have to save everything you need

for building, testing and releasing your application. As the Jez Humble and David

Farley [HF10] says “This includes requirement documents, test scripts, automated test

cases, network configuration scripts, deployment scripts, database creation, upgrade,

downgrade, and initialization scripts, application stack configuration scripts, libraries,

toolchains, technical documentation, and so on ”. All this information gives the pos-

sibility to recognize build number, version control number, and developers can run

projects in different environments at any time including the local development work-

station [HF10].

“Build quality in” was the motto of W. Edwards Deming [SPP10]. Who was among

his other distinctions, one of the pioneers of the lean movement. The primary goal of

the continues integration, automated testing, and automated deployment process is to

find defects as early in the delivery process as possible. The next step is to fix all these

errors. The software development team must be acting and fixing the errors as soon

as they receive an error notification. In other words, during the software development

process, everybody must be responsible for the quality of the product[HF10].

If you are working in a small company, it is easy to control everything you need for rele-

asing the software. In big company when something goes wrong, people spend much

time blaming each other. Communication between the people who are involved in

the software development process must occur continuously. One has to establish a sy-

stem where everyone will see the status of the application, its condition, builds, which

tests have already passed, and the stage of the different environments they must be

deployed to. Collaboration is the central principle which focuses on the involvement

of all team members in the software delivery to release a quality product in proper

time[HF10]. The continues improvement of the process during the software develop-

ment is based on the team. Developers and testers must reflect on the delivery process.

In other words, the team members must discuss the result which show them what has

gone well and what has gone badly. Everybody is involved in this process and they

should report on their opinion what happened. This type of involvement process helps

1.4 Summary 9

the team to answers an important question which can improve software production

process. The guideline structure is known as the Deming Cycle (See Figure 1.4).

Figure 1.4: Deming cycle (from [SPP10]).

1.4 Summary

This chapter describes preparative work for understanding problems which perform

in Zeiss during the software development process.The idea of this chapter is to show

the general view the reader how big the differences between manual and automated

process are. What are the advantages of the automated software development process?

What is the significant issues for Releasing Software to create Repeatably, Reliable Pro-

cess? etc.

The automated software development gives the many benefits. As the author of book

[HF10] said. The automated build, test, and deployment make the process reproducible

across a range of environments and improve the ability to find errors into production.


To bring business benefits more quickly is important to deploy changes.

The automated test, deployment, and release is a straight line to reduce the costs of

releasing software and increase the quality.

The benefits which can gain from the automated process is not fully achieved at Zeiss.

Especially the test results, are not consolidated in one view. They are not able to see

which test on which version of the code is completed successfully. In following chap-

ters, we will spread necessary aspects for automated software delivery. Furthermore,

we will describe entire software development process at Zeiss with the concrete Project.

In the final sections will be presented proposed architecture for improving transparency

and reliability in the software development process for Zeiss.

CHAPTER 2

Related Work

This chapter covers background information which can be relevant to the reader. Soft-

ware development processes are usually related to like rules, and rules are a particular

concept that describes phases of a software development process discipline, and the

order in which phases are performed. There are some different kind of models known

and used, and many software development companies choose their own. This chapter

is served by a presentation of what the author considers agile software development

and lastly more detail a formal definition of continuous integration, continuous de-

livery, and continuous deployment.How they are running together and additionally

necessary aspects of a fully automated software delivery process.

2.1 Agile Software Development

If anything can be characterized today as an omnipotent and omnipresent, that is com-

puter software. Programs and Software are running most of the services in modern

world in almost all sectors of economy [Sza04]. Since the internet is getting more and

more widespread with almost 2 billion users worldwide, novel innovative communica-

tion technology products and software market are offering new and alluring business

opportunities.

Since the emergence of the first Software in 1940s (though mostly for military purposes)

its development process has been very complex. 1970s was dominated by the so called

Waterfall approach. As Szalvay [Sza04] describes, "the essence of waterfall software

development is that complex software systems can be built in a sequential, phase-wise

manner where all of the requirements are gathered at the beginning, all of the design is

completed next, and finally the master design is implemented into production quality

12 Related Work

software". In short, "Waterfall" is kind of a linear approach, in a sense that there is no

going back and revisiting requirements or decisions since complex systems are built in

a single pass [Li10].

Nonetheless, globalization and the emergence of the World Wide Web led to unimagi-

nable changes in the software industry. Inflated exponentially leading to the increased

frequency of updates in the approaches and methodology. Subsequently, huge inves-

tments in the IT sphere, daily birth of new high-tech start-ups and multiple mergers

and acquisitions, dramatically transformed the software industry [Sch16]. Since the

number of users of different programs and applications has also increased exponenti-

ally, the demand for user-friendly interfaces has become immense. That led to the need

of including user feedback in the development process and to be able to do constant

changes in the end-user requirements.The only way to meet such a demand was by

changing the software development process and moving to a shorter product life-cycle

approach. This is how the so called lightweight methods were born, becoming an "op-

posite pole" of the heavyweight centrally planned "Waterfall" development approach

that quite soon became obsolete [Sza04].

2001 marks the most important year for the emergence of lightweight software deve-

lopment methods, as this is when 17 advocates of that approach gathered to discuss the

future plans and introduced the term "agile methods". They wrote the so-called "Agile

Manifesto" [Sch16] which consists of the 4 core values enlisted below:

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

Waterfall approach had 6 to 18 months development period with pre-defined potential

risks. By contrast, Agile methodology with its integrated feedback mechanism led to

the delivery of the usable product versions every 1 to 4 weeks [www16].

Apart from those 4 core values, the manifesto consists of 12 principles, outlined as

follows [www16]:

• Customer Satisfaction - Highest priority is given to satisfy the requirements of

customers through early and continuous delivery of valuable software

• Welcome Change - Changes are inevitable during software development. Ever-

changing requirements should be welcome, even late in the development phase.

Agile processes should work to increase customers’ competitive advantage.

2.1 Agile Software Development 13

• Deliver a Working Software - Deliver a working software frequently, ranging from

a few weeks to a few months, considering shorter time-scale

• Collaboration - Business people and developers must work together during the

entire life of a project.

• Motivation - Projects should be built around motivated individuals. Provide an

environment to support individual team members and trust them so as to make

them feel responsible to get the job done.

• Face-to-face Conversation - Face-to-face conversation is the most efficient and ef-

fective method of conveying information to and within a development team.

• Measure the Progress as per the Working Software - Working software is the key

and it should be the primary measure of progress

• Maintain Constant Pace - Agile processes aim towards sustainable development.

The business, the developers, and the users should be able to maintain a constant

pace with the project.

• Monitoring - Pay regular attention to technical excellence and good design to en-

hance agility.

• Simplicity - Keep things simple and use simple terms to measure the work that is

not completed.

• Self-organized Teams - An agile team should be self-organized and should not

depend heavily on other teams because the best architectures, requirements, and

designs emerge from self-organized teams.

• Review the Work Regularly - Review the work done at regular intervals so that

the team can reflect on how to become more effective and adjust its behavior

accordingly.

Agile method, unalike Waterfall, instead of formalizing and pre-defining the develop-

ment process, provides continuous feedback based approach of software development.

It is a more evolutionary method characterized by incremental progress and an itera-

tive process.

Agile approach has number of different methodologies, from which the most famous

and widespread is Scrum and Extreme Programming [Sch16]. Below we will provide a

brief review of both.

14 Related Work

2.1.1 Scrum

A Large number of professional software development teams find Scrum as the most

efficient methodology. But to be more precise, it is more like a project management

framework than a method. Figure 2.1 shows a graphical illustration of all key elements

of Scrum.

Figure 2.1: Scrum Development Framework (from [www16]).

The Scrum team usually consists of up to ten people, from which two have a specific

role, ScrumMaster and Product Owner. The main role of a ScrumMaster is to facilitate

the project development, identify all potential problems and ensure the work frame

efficiency. The job of the Product Owner is representation of the customer’s intere-

sts and incorporation in the process of project development [www16]. The rest of the

team members do the software development, ranging from design to validation. Ho-

wever, team members often share the work, therefore their expertise should be cross-

functional. In short, in Scrum, there is no strict role for a team member such as for

instance user interface developer or tester.

As Schmidt [Sch16, p. 17] describes, “Scrum teams pursue an iterative work mode and

split the development project into short development cycles, so-called development

sprints”. Each sprint usually lasts from one to four weeks. At the end of each cycle the

product is presented to the customer and based on the feedback received, modifications

are augmented.

Additionally, the product backlog is used to organize the development tasks. Usu-

2.2 Continuouse integration 15

ally, the backlog is a list of prioritized tasks as defined by the Product Owner. Using

a burndown chart, that is a ratio of accomplished vs. prioritized tasks, the progress is

observed [www16].

2.1.2 Extreme Programming (XP)

In a rapidly changing environment of requirements, another popular lightweight met-

hodology for small to medium sized teams of developers is XP. "The general idea be-

hind Extreme Programming is to take beneficial ideas and concepts of software engi-

neering to "extreme" levels" [Sch16][p18]. The major component of the XP methodology

is its superior approach of simplicity, testing and communication. The emphasis goes

to the software code instead of the plans and documentation. Automated tests con-

stantly check the quality of the project development. Three different types of tests are

conducted [Sch16]:

• Unit Tests – Checking the quality of the certain parts of the software.

• Acceptance Tests – Monitoring the user satisfaction during the development pro-

cess, and

• Integration test – controlling the coherence between different parts and modules

of the program.

Extreme programming is characterized by certain types of development practices, such

as a) pair programming – two programmers sharing a single workstation, so one can

write code while the other is checking the chosen approach; b) Code Review – after each

cycle, the finalized software code is reviewed by at least one colleague, c) Continuous

Integration – a practice when any finalized code is continuously integrated to the final

project, and etc.

2.2 Continuouse integration

Continuous integration is the process which automatically builds and tests software on

a regular basis. The main idea is to test code as often as possible so one can catch is-

sues early on. During the continuous integration process, most of the work is done by

automated tests which require a unit test framework. Continuous integration is good

practice for developers to merge requests even while tests are performing [KA14].

Continuous delivery is the next step after continuous integration. If tests run regularly

and the developer’s trust their test framework which provides them a guarantee for

16 Related Work

software quality, it is evident that release can be provided for anytime. The main idea

of continuous delivery is that you are always ready to release the code .

The necessary implication for the continuous deployment process is to use continuous

integration and continuous delivery, which is used to avoid getting errors in the release

[KA14]. The reason why we should we do continuous deployment is reasonable, we

have to use all advantages from integrated tools to make automated process, and con-

sequently, the process must serve our goals (See Figure 2.2). Continuous deployment

means a transparent development process, in other words, the main version is always

ready to branch in a releasable state.

Figure 2.2: The relationship between continuous integration, delivery and deployment(from [SBZ17]).

2.2.1 De�nition foundation

Many research finds [HF10][DMG07][SBZ17] that a continuous approach leads to sig-

nificantly reduced integration problems and enabled a team to develop software more

quickly. According to Duvall’s book [DMG07] continuous integration implies that as-

pects:

• Error correction has the highest priority.

• Developers must submit their code to review control more than one time per day.

• In the continuous integration server integration happens many times a day.

• Every build must pass the necessary test to be approved as eligible.

• The test result must be visible for the team.Team members will be notified of the

current state of the software.

Continuous integration reduces the complexity of the project, due to a decrease in the

amount of manual work.As Mojtaba Shahin and Muhammad Ali Babar [SBZ17] des-

cribe, continues practices,i.e., continuous delivery, integration, and deployment enable


software companies to regularly and reliably release new features and products. It is

evident that we must periodically review and update the approaches, tools and met-

hods implement of new continuous practice.

The article "Asystematic review on approaches,tools,challenges and practices" [SBZ17]

identifies approaches and tools importent for implementation continouse practices.

• Reduce time for test and build regarding of continuous Integration.

• Gain clarity and knowledge on build and test during the CI.

• Suport automated test .

• Detecting all errors in CI.

• Security and scalability issues in Deployment pipline.

• Team perception and transparency.

• Well designed principles.

• Dependability and safety of software deployment process.

A general continuous integration life cycle is illustrated in Figure 2.3. At the beginning

developers submitting code to the version control system. The continuous integration

system monitors the repository for changes. When The CI server identifies some chan-

ges, it takes the last version of the code from the version repository and starts the build

process. After that, the server will send the feedback to the team. The Continuous

integration will do above steps again and again before any changes in the repository

happen[DMG07] .

The first rule of developers is to run own builds. Each developer does so after finishing

their tasks. If the integration of this code with the rest of the code of the developer team

is successful, developers submit their code to the version control system. This step is

essential since it prevents the submission of broken code [DMG07].

For continuous integration version control repository is fundamental part.The primary

goal of version control repositories is to control in the source code changes. All files and

all source code versions which were created during the development process,are stored

in the version control repository (See Figure 2.3).

One of the most important part of the entire system is continuous integration ser-

ver. After in the version control system changes are made, an integration server creates

an integration build. Usually, the server is configured to track changes in the version

control repository. Also, the version control system can notify continuous integration

server that a build is required. The CI server receives files of source code and runs build

18 Related Work

Figure 2.3: CI life cycle (from [Coi17] ).

scripts [DMG07]. Today there are many continuous integration servers free for use for

example Jenkins,Buildbot,Travis CI, etc.

Feedback instrument is one of the most important duties in CI, because it gives results

after of integration build. Feedback can be present in many ways. In cases when the

provided result shows that the build has failed, developers can start to fix the problems

immediately.

As Duvall [DMG07] describes, there are four elements used to implement continuous

integration. Source code compilation could be the simple tasks in continuous integra-

tion. That is a process which creates of machine readable executable code from source

code, and this process depends on the type of the programming language during the

project.

Database integration could be involved in the integration phase.The implementation

of continuous integration system can guarantee integration of database using version

control repository in a project. On these terms, version control repository serves as the

consolidated source.Continuous Integration in databases covers three central principles

of process. [DMG07].

• It confirms the status of the database after changes have appeared.

• After changes, it always runs the tests.


• It will be updated when changes in a target database happen.

As Duvall [DMG07] describes, using these techniques, continuous integration will de-

tect any problems which have not been noticed by Database administrator starting from

deployment to production. Figure 2.4 demonstrates continuous integration operating

process, where CI gives database integration during a build.

CI Server Integration Build Machine

Feedback Machine

BuildScript Database Scripts

Version Control

RepositoryDatabase

Developer DeveloperDeveloperDeveloper

Figure 2.4: Database integration

Addition necessary component of CI system is testing. Regarding the automated tests,

team members can trust changes, as long as the tests show their exactness. The popular

unit testing tools such as JUnit, NUnit, and others provide full reports the developers.

The unit test verifies the authenticity of the code.Furthermore, there are other tests,

which are searching for errors in an application [DMG07]. Also, most of these tools

produce total reports to users, and they appear in the form of charts or graphical sum-

maries. Unit testing checks the reliability of the code component tests. It examines

the functionality and search defects in the application. System test checks functional

and non-functional specifications of the complete system. Functional tests based on the

purposes performed by the system and it could be carried out at every level of testing.

According to Duvall [DMG07] CI brings the following advantages to the software de-

velopment process.

• Continuous integration reduces the number of manual processes and automates

repetitive processes.

20 Related Work

• Continuous integration is able to generate deployable software at any time.

• Continuous integration facilitates much project clarity and performs project trans-

parent to the developers during a development process.

• Continuous integration establishes and it gives building a process of software a

high confidence.

2.2.2 Tooling support

The successful use the continuous practice in a company depends on organizing a reli-

able and stable CI practice and environment. Continuous integration must be a priority

for the company if they want to use continuous delivery and deployment practices.We

must understand how these practices are related to each other and what tools and ap-

proaches are supporting continuous practice [SBZ17]. The Figure 2.5 shows tools that

consequently increases performance and efficiency of continuous integration practice.

A number of papers [SBZ17] [KA14] [HF10] about continuous integration, concur that

without correct tools it is impossible to use continuous integration practice. A deploy-

ment pipeline must include build and packaging stages to transfer code from code re-

pository to the production environment. However, sometimes manual tasks in deploy-

ment pipeline are unavoidable.


Figure 2.5: An overview of tools used to form deployment pipeline (from [SBZ17]).

CHAPTER 3

Analysis of the current state

The purpose of this thesis, based actual state of the software development process and

current "VISUSTORE" project to improve the transparency and productivity of daily

work in Zeiss company. To learn what types of work could be executed a series of in-

terviews, as well as a study, was performed. The respondents I conducted an interview

was four developers and three project manager in Zeiss Company. The need for auto-

mated software development process has been confirmed after the research.

I had several specific goals in my mind when I approached for the interview. First of

all, I wanted to develop a deeper understanding of the technical issues and form visual

model how the software development framework works at Zeiss. On the other hand, a

big part of interview questions emphasized actual matters such as collaboration work

point, continuous monitoring process and continues reporting process for the project

managers and extern stakeholders.The most significant and interesting aspect for me

was to listen and analyze the problems from the developers, standpoints regarding the

developing process. The problems mentioned include inflexible communication bet-

ween project managers and developers, outdated software, not user-friendly and unin-

tegrated tools.

In section 3.1 will be presented, the necessary background for the design and execution

of interview. In section 3.2 will be given relevant insights and information that we have

taken into the account when we are designing our interviews. In finally, section will be

described the interview result and complete architecture for the current project.

3.1 Important aspects when designing interviews

Interviews are one of the most challenging and used methods of quality assessment.

The right question-and-answer format requires sensitivity and flexibility, as well as

24 Analysis of the current state

well-designed plans. It does not need clear proof that the qualitative research depends

on the level of experience of a researcher, in most cases, they have a particular type

of methodology. The point of a qualitative interview research is to let respondents tell

their story on their terms [Wil05].

The designing strategy is a general term that covers some separate but relevant issues,

connected with your research. It includes the aim of the study, the final selection of the

appropriate technology, information collection techniques you plan to use, the target

group of participants, the chosen methods of data summary and at the end display the

given result. Designing strategy is how all of these relevant issues fit together [KCS94].

Advice to take the following points into consideration when preparing for the inter-

view research, before starting to write the questionnaire. One of the most important

aspects of any interview methods is the "devil training" of the interviewers. The result

from an interviewed group is your measure of the quality work, and the quality of the

research is entirely in your hands. In spite of the research being based on a small num-

ber of interviewees, it is necessarily important to organize in detail the methods and

build the interviewing process before starting the formal study [DBC06].

In most cases, the question-and-answer format is boring for the participant. The reasons

could be various, for example, the interviewees don’t have sufficient information about

the research study. Sometimes they do not understand your infinitely long sentences,

and they are trying to repeat the question as the answer which you already asked. Or

oftentimes, they are using just "Yes" or "No" which will reflect off the research.

3.2 Important aspects of e�ective interview questions

Before handling interviews, you need an interview guideline which you can use to the

conversation and all these remarkable methods you need for your studies. The well

defined techniques help you how to ask right questions for the particular audience, in

what sequence, how to pose your question, and how to pose follow-ups. That could

consider a guidance about what you want to say or ask next after your participant fi-

nishes the current question [DBC06].

Before we start to describe quality interview methods, we must understand that a rese-

arch question is not an interview questions. If you want to learn about a simple topic

like why people hate politicians, you can ask this participants this question right away:

"Why do you think that people hate politicians? “ In that situation, your research que-

stion is broad to serve as a productive interview question [Boe02]. In different cases,

you need clear guidelines for your interview. Once you have a research question, you

3.3 Interview result 25

should create evidence collection plan which helps you gather all important clues for

your study. Your research question is the problem that is behind the questions. During

the question developing process for the interview, we must consider some important

issues.

• The question should be simple. Avoid to ask more than one question at the same

time.

• Try not to ask question which can be answered with one word. The best question

is one, which elicit a comprehensive response from the respondent.

• Do not pose a question which requires an analysis: this is your Job!

• Direct questions: Do you think? Are you sure that? Such kind of questions are

best asked towards the end of the interview, in order not to impact the direction

of the conversation too much.

• Structure questions: I would like to stop and move on the topic.

• Ask follow-upquestions: get the participants to refine their answers. Could you

give more details? What does it mean?

• Use probing questions: follow up on what said through direct questioning.

• Specify questions about concrete situations: What did you do? How did you fix

the Problem?

• The most important aspect for the interviewer is to interprete questions during

the interview: Do you mean that the trouble comes from his behavior? If I right

understand, do you want to say that..?

3.3 Interview result

The software development framework at Zeiss is based on Scrum concept which is a

subset of Agile development techniques. The daily work starts for developers with in-

specting the scrum board. They have two different version control systems. The first

one is Git version control system and second is the Subversion. After all preparation

process is done, they are ready to start the developing process.

Regarding the question which described the "code review" practice during the software

development process at Zeiss company, the developer’s response was as follows : for

reviewing the code, they have no special software, which means that the developer

group cannot discuss the changes, share knowledge, and identify defects across Git. It

means that one developer uses another developer’s experience to prove the code qua-


lity.

The question which aimed to understand the collaboration point between developers

and team leader gave the following answer: As the collaboration point, in most cases,

they use face to face communication rather than writing periodical comments on the

ticket. Their conversation also with Team leader is determined by email or face to face

communication. As they said, the most problematic questions come from business is-

sues. So it is important to have a flexible connection to the respective project manager

to solve these issues within a short period of time.

The question which aimed to understand if product owner involved in project mo-

nitoring process, gave the following answer: The continuous monitoring process for

external stakeholders is not transparent to understand in which development layer is

their product before the developers finish their work and run on the live system. After

this, the stakeholders have information about the final version.

The question regarding continuous reporting process which aimed to understand how

flexible is the reporting process for project managers and team leader gave me the fol-

lowing answer: The daily reporting process can be characterized as communication

between developers, team leader and also project managers in Jira where they have

the possibility to see the tasks which are already done and which are scheduled for the

near future. Additionally, the developers use daily stand-up meetings for developing

process. Here they discuss the problems, the work which is already done, and future

tasks which means that they are obliged to inform the team leader about the status of

the developing process. It is also worth mentioning that the Team Leader is also scrum

master.

The last question - which process would you like in the future - gve me the most inte-

resting answer. One big problem for developers is code review with regard to the two

different code repositories. They have no possibility to see the complete code base to-

gether at the same time. Every developer agrees with the fact that for future work they

need more flexible integrated tools for the developing and reporting process which it-

self increase continues deployment process at Zeiss company .

Interview answers from project managers were almost equal. If we will show the reader

original results what they answered, it would be easier to understand the problems and

aims from project managers side.

• How transparent is for Project Managers daily developing work and do you have

continuous reporting?

Answer: Today the reporting process during the development process is limited

3.4 Summary of the current project 27

to the standard functions of Jira.

• Do you want to see the Project actual state during the developing process?

Answer: No as transparent as needed, for example we do need to track the pro-

gress for each sprint, connect it with the release information, connect it with the

information which release is deployed to which environment (I, K, Q, P).

• Why is this information relevant to you?

Answer: Easier communication with our stakeholder, operations and business.

• How does it increase your productivity?

Answer: Avoid duplicate work, avoid manual maintenance of this information in

other systems.

• Is it relevant for you to see the new software test report? Why?.

Answer: Yes, track the overall status of the product, support Go / No-Go calls for

release deployments with test and quality facts.

• Is it important to know which software version is running in which environment

(Deployment status)? And Why?.

Answer: Yes, easier test and release management.

• Could you tell me what tools/support or process would you like in the future?.

Answer: Release management and reporting, test automation and reporting, code

analysis with Unit test case coverage, wish to have automated security testing.

3.4 Summary of the current project

Based on the interviews I described the entire software development process at the

Zeiss company. However a software development process for different projects uses

different architectures and tools. Working Agreements of the team represent how the

team collaborates during a sprint. One of the most frequent questions in each daily

meeting is as follows - "what have I done yesterday?" What will I do today and where

are the problems.


Figure 3.1 shows all three roles are "management" roles in Scrum with different respon-

sibilities. By clear responsibilities, the process will be stabilized. The framework during

the development includes Roles, Meetings, and Artefacts.

The collaboration point for the VISUSTORE Project is in Jira and Confluence, where the

team makes the collaboration work during the development. Additionally, they use

face to face communication, where they discuss the problems and the work which is

already done. During the meeting, they also inform the team leader about the status of

the developing process.

Figure 3.1: Managment roles in Scrum with different responsibilities

The application development process in The VISUSTOR application is based on the

internal shop architecture shown in Figure 3.2. For the application development, deve-

lopers use local development system with a GIT repository, which is connected to the

Jenkins, Nexus and four (I, K, Q, P) different quality assurance systems.

Regarding this Project, we have four different systems (See Figure 3.3) available which

are currently hosted in different data centers. Each system consists of an edit and live

environment.

The I-system is the working environment for the Diva-e development team. New fea-

tures are developed on this system.

The K-system is the test environment for the Diva-e development and the Carl Zeiss

Vision quality assurance team. New features are tested here.

The Q-System can be seen as additional quality assurance system. It is used in order to

test new features, the order process and the performance within the Atos environment

without endangering the daily business.

The P-System is used from shop managers, channel managers and the customer service

to configure back office settings and to maintain the content of the storefront. All these

changes will be published to customers indeed.

VISUSTORE uses a system structure of two different back office installations because it

raises the security and stability of the online shop. On the one hand we have an edit

system which you can consider as pre-system of the live system. To maintain content

or to make configuration changes you should usually work on the edit system first. If


Rej

ect

LT

-Sys

tem

K-S

yste

m

Nig

htly

-Bui

ld

Las

test

go

live

Q-S

yste

m

I-Sy

stem

Dep

loym

ent +

Tes

t aft

er e

very

spr

int

Git

Jenk

ins

Loc

al D

evel

opm

ent

Syst

em

Dev

elop

er

Com

mit/

Push

in G

ITP-

Rep

lica

Nex

us

Tea

m J

ena

P-S

yste

m

Dep

loym

ent,a

fter

Rel

ease

Figure 3.2: VISUSTORE development chain


I System K System Q system P system

EDIT LIVE EDIT LIVE EDIT LIVEEDIT LIVE

Production EnvironmentDevelopment Environment

Figure 3.3: I,K,Q,P system architecture

the effects have been successfully checked on the edit storefront, all adjustments can be

additionally transferred through a staging process to the live system.

We have those systems in place to do different types of quality checks as shows Fi-

gure 3.4 . Currently, those tests, especially the results, are not consolidated in one view.

So coming back to the development process, which starts in Jira with a task for the deve-

loper, we are not able to see which test on which version of the code in Git is completed

successfully. As a consequence, we can not see the coverage of a user story or an epic as

both are parents for tasks. Figure 3.5 shows a graphical illustration of the tools which

are used during the VISUSTORE development process. As we said in the beginning of

the section , the development process for different projects is not the same. Test results

combined with one view or to know which versions code on which environment runs

are the problem.


K - Development

I - Development

Q- Development

P- Development

Automated

Manual

Automated

Automated Manual

CAB

Figure 3.4: VISUSTORE Quality ensures stages


Pro

ject

Mgt

Figure 3.5: Visustor

CHAPTER 4

Tools for fully automated process

As described in Chapter 3 only the wish to have a fully automated process is not

enough. For an automated process, we need properly defined tools. This chapter will

describe different tools which simplify collaboration between developers and project

managers, reduce bugs using continuous testing and establish a continuous reporting

process. This can reduce a developer’s manual work and thus improve the quality of

the code. The wish to use Atlassian tools was the default by the software development

team at Zeiss.

4.1 Jira

JIRA is designed for project management and issue tracking. Although JIRA does not

provide all the features, it is used as the focal point that combines other Atlassian tools

like the ones presented in the next sections and other commercial or free plugins from

the Atlassian marketplace. JIRA is an issue tracking system with a customizable work-

flow, agile development features, task tracking boards and multi-tiered issue types.

Jira software gives companies the opportunity to create transparent process monitoring.

That enables external stakeholders to inform during the software development pro-

cess and assess the current situation without any additional efforts by the development

team. Workflow triggers help to keep JIRA software issues synchronized with the in-

formation in other development tools FishEye, Crucible, Bitbucket, HipChat, Bamboo,

and Git. Developers do not need to update the status of an issue manually anymore

after a commit, the completion code review, or the creation the branches. We can confi-

gure triggers for our workflow to automatically adapt issues when something changed

in a development tool. Additionally, connected Jira software tools can be used to mo-

nitor the progress of a version (see Figure 4.1). These tools can help users to spot pro-

34 Tools for fully automated process

blems early, as well as support developers to release their software on schedule[Fra17]

[sup16].

Figure 4.1: Release Version (from [DT16]).

4.1.1 Bamboo

Bamboo is a commercial continuous integration tool developed by Atlassian. It combi-

nes automated builds, tests, and releases in one unit workflow.

Bamboo gets new branches from Git, or SVN1 repositories and then automatically ap-

plies the main code line. It can also be used for deployments. New branches in the

repository can be automatically built and tested using the same build configuration

as the origin plan. Additionally, any branches which are deleted from the repository

can be removed automatically from Bamboo based on certain settings. Additionally,

Bamboo can be extended by plugins to be of equal use as Jenkins. Notifications can be

exported in many different ways like, for example by email, RSS seeds, or information

window. This information is based on the event types. Event types are Jira versions,

Jira software sprints, Jira issue dates, code color events and filter events [Att17a] .

It is an easily configurable tool and maintains multiple programming languages.Additionally,

it supports builds in any programming language working any build tool. Nevertheless,

we have to know, when configuration.

To use a traditional continuous Integration server for continuous delivery is not perfect.

During the traditional software delivery process, we have some common difficulties,

1https://en.wikipedia.org/wiki/Apache_Subversion

https://en.wikipedia.org/wiki/Apache_Subversion

4.1 Jira 35

for example: deployed builds are hard to find, it is not easy to determine what chan-

ges are made between deployments, it is also difficult to know what, when and where

an artifact was deployed. Bamboo, however, provides the following concepts how to

perform deployment projects work [Att17a]. We have three main concepts during the

software Project deployments, artifacts, environments and releases (See Figure 4.2).

Figure 4.2: Deployment Project with Bamboo(from [Att17a]).

Deployable artifacts will be created and tested with build plans. Guarantee each arti-

fact we want to deploy with Bamboo is shared to the deployment instructions of the

environment. All artifacts that were successfully tested can be used for a release. With

Bamboo, we can create as many releases as we want. With Jira, we can track each

release and commits through our environment. Bamboo presents the development,

testing, and production environments which means that at any time with bamboo (See

Figure 4.3), we will be able to see which release is running in each environment, which

release it had replaced and where is deployed. Furthermore, monitoring the status of

Bamboo in Bitbucket regarding builds, deployments and commits gives the possibility

to see all this information [DT16].

4.1.2 Bitbucket

Bitbucket is a web-based hosting service that is maintained by Atlassian, and it is for

source code and development projects that use Git repository. Bitbucket has three de-


Figure 4.3: Atlassian Launches Bamboo 4, Continuous Integration Server: DevelopersCan Now Test More, Configure Less (from [Att17a]).

ployment models: cloud, Bitbucket server, and data center [Wik17]. As Jack Moxon,

Product Manager at SauceLabs team says "We believe that Bitbucket Pipelines is a novel

approach for helping customers achieve continuous delivery quickly. Bitbucket pipeli-

nes make continuous integration much more efficient and achievable. It helps speed

up the continuous integration pipeline through massive test parallelization, and the in-

tegration seemed like a no brainer" [Att17b]. Integrate bitbucket with JIRA, FishEye,

and Bamboo for full end-to-end visibility and automation across entire development

process [Att17b].The notable point is a possibility to create Bitbucket branches from

within JIRA Software (See Figure 4.4). Jira automatically establishes information for

our new branch in Bitbucket and transit issues without leaving Bitbucket. With crea-

ted triggers in JIRA for actions which occur in Bitbucket, we can synchronize commits,

and branches in Bitbucket to our JIRA workflow, it means that issues will automatically

update.Track the status of our next release in JIRA Software, release Hub2 addresses to

Bitbucket to prove that complete code is done and there are no inconsistencies or risks

before launch day [Att17b].

2https://confluence.atlassian.com/jirasoftwarecloud/checking-the-release-status-of-a-version-764478180.

html

https://confluence.atlassian.com/jirasoftwarecloud/checking-the-release-status-of-a-version-764478180.html

https://confluence.atlassian.com/jirasoftwarecloud/checking-the-release-status-of-a-version-764478180.html

4.1 Jira 37

Figure 4.4: Bitbucket branches from a JIRA Software issue and transition an issue wit-hout leaving Bitbucket (from [Att17b]).

4.1.3 Crucible

Crucible is a collaborative code review application. Similar other Atlassian products,

it is a web-based application and certain characteristics that allow review of a code-

base. Crucible empowers teams for code reviewing, editing, commenting and recor-

ding outcomes. Code review increases code quality by identifying bugs earlier in the

development. Cooperation in reviews with Crucible is very simple. Once a problem

is discovered in the code, the development team member selects the line of code and

adds a comment as shown in Figure 4.5. Crucible converts review comments into issues

within Jira with one click. Additionally, Jira software will automatically update issues

based on review activities. We can connect Crucible to Bitbucket and create reviews

directly for all new branches[Att17c].

4.1.4 FishEye

FishEye is a product by Atlassian, which helps developers keep tabs on what is going

on in the code repository using a web interface. It provides developers with advanced

browsing and searches for SVN and Git repositories. It is graphical represents of acti-

vity in a source code, address on lines of code over time, and get a visual report way

of changes. FishEye commit graph data contains complete information about change-

sets in the code repository. Additionally, it is getting information about modifications


Figure 4.5: crucible (from [Att17c]).

and files review indexed by Crucible. Furthermore, it performs queries on a repository

[Atl17b].

4.1.5 HipChat

Another Atlassian product is HipChat which is an online, private and group chatting

application with video conferences and real-time file sharing. In HipChat team, ca-

lendar event reminder is a possibility which highlights personal and project tracking.

HipCHat is especially helpful if multiple communication channels are used. JIRA soft-

ware and HipChat enables remote work because people are working with the same

source code can communicate in real time from anywhere.

Additionally, a connection of Bitbucket repositories with HipChat rooms gives the pos-

sibility to get notifications from Bitbucket in HipChat to get notified when code is com-

mitted, or when a pull request is created[Att17d].

4.1.6 Nagios

Nagios is open source tool that provides instant company information of mission "IT"

infrastructure. Nagios is used for systems monitoring, networks, and infrastructure. It

allows to detect and fix problems and decrease future problems before they hit users

4.1 Jira 39

and customers. Integrate Nagios with JIRA bring full status information of "IT" infra-

structure to issue tracker or customer support tool. It is also easy to use non-technical

team members. The Nagios for JIRA overview page allows users to zoom in on specific

status messages like alerts and critical system crash information [Atl17a].

4.1.7 Ansible

Ansible is an entirely simple Information technology automation engine that automates

and facilitates the automation of general IT tasks such as configuration management,

deploying and updating applications on bases or in the cloud and creating develop-

ment environments. Ansible has three main components: An automation language

that describes application infrastructure in Ansible Playbooks, an automation engine

that operates Playbooks, Ansible Tower, that controls, secures and manages automa-

tion [Dok17]. Automated workflows allow for faster software development changes.

It gives compatibility across environments, role-based principle/self-service work and

knowledge, which means visibility across teams. In other words, Ansible was created

to enable rolling out upgrade across clusters of servers.

Ansible uses "YAML playbooks" for describing flows of operations to be executed on se-

veral hosts. "Playbooks"3 are Ansible’s configuration and deployment language which

can define remote systems to enforce or a set steps in a general IT process. A simple

level "Playbooks" can manage configuration and management of remote machines. At

an advanced level, it can roll out updates, authorize operations to another host, as well

as communicate with monitoring servers and load balancers along the way [Dok17].

We can use Ansible to manage the deployment and upgrade of the application level

software[Smi17]. A workflow can, for example, look like this:

• Download Build artifact from Bamboo.

• Fetch Ansible from Git Repository.

• Fetch Ansible playbooks from Git.

• Run the required playbook.

3http://docs.ansible.com/ansible/latest/playbooks.html

http://docs.ansible.com/ansible/latest/playbooks.html


Figure 4.6: Ansible

CHAPTER 5

Proposed architecture

Using tools for a requirement and design management, issue development tracking

and tests is not enough. All these activities have to be connected to each other. The idea

of combining all these tools is to design a continuously report system, whose result has

to be visible in Jira for project managers, stakeholders, scrum masters, and developers.

Including Confluence, JIRA and other continuous deployment plugins for test mana-

gement these links can be created with a high level of automation as all these products

belong to the same family and thus are interlinked. In Jira, we have many types of

issues with different data and workflows. The idea of s workflow is that every issue

always has a status which will be reported in Jira. That status can be, the version num-

ber in the current environment, test result, code review result, etc. In other words, the

reports in a Jira panel must reflect a project’s current development process status conti-

nuously [DT16]. As a consequence, my continuous deployment workflow will include

the following tools. JIRA would take the primary position of collecting issues project

reports and project management tools Figure 5.1.

• JIRA Software for issue tracking.

• Git1 for version control system.

• Bitbucket for repository management.

• Bamboo for build, test, and deploy automation.

• FishEye for search, track and visualize code changes.

• Crucible for code review.

• HipChat for group chat, video chat, and screen sharing.

1https://git-scm.com/

https://git-scm.com/

42 Proposed architecture

• Ansible for cross-host coordination.

• Nagios for monitoring systems, networks and infrastructure.

The Proposed architecture shows the various Atlassian products available, and how

they could be combined to form multiple solutions. Concerning example, Bitbucket,

Bamboo, Crucible, and FishEye can be combined and form the core of a development

solution. Atlassian solutions can be settled together to create comprehensive solutions.

For example, the Agile Project Management and Development solutions can be joined

to make a larger solution that meets everything from requirements to source code ma-

nagement. Some Atlassian products could be used for the whole business. An excellent

example of this is HipChat, which enables users to communicate with each other secu-

rely within company business, improving productivity and collaboration. With a blue

background is not used for our architecture but could be used for future.

Development - BitBucket uses the Git system to store code and manage branching and

merging. BitBucket integrates with JIRA to present access control and real-time process

updates to the project management system. BitBucket also integrates with Bamboo for

continuous integration.

Testing - Jira and testing addon allow us to manage, testing record execution and track

defects.

Automated Test Tool - Tools such as Selenium and Ranorex.

Continuous integration - Bamboo integrates with Bitbucket and tests management

tools to provide continuous integration. It defects code changes in Bitbucket and will

build, test and deploy the code.

Agile Project management - Jira software, Confluence and testing tools make power-

ful, end to end agile project management solution.

5.1 Track your requests

For each development task like, for example, bug or feature requests, we have to create

a unique issue to track the respective progress. In fact, it is good practice, because we

can use each unique ID to follow the changes from concept to deployment. Most of the

big project has "Epic" issues that all the task issues connect. Jira is a starting point. But

for continuous deployment, we have to use some other tools. Furthermore, Jira enables

some other tools integration, which should be useful for the continuous deployment.It

5.1 Track your requests 43

1.Pl

ug-I

ns2.

Core

Pro

duct

s3.

Prod

ucts

Figure 5.1: Proposed architecture


follows that without much effort, we can track the state of the work[Smi17].

5.2 Create separate branches and label them with the issue

number

Git and Bitbucket are very compatible tools, and in Jira, they have excellent integration

point. We have to use Git for version control and Bitbucket to manage our repository.

Regarding the issue tracking of step 1, we can use Bitbucket to create a branch which

will contain the issues number and a short report of the change. The "Source Tree"

manages our repositories with a simple interface, which gives us the chance to pick up

and check new branches. After Jira will query Bitbucket to list all branches linked to

all given issues, forward with some commits to the branch. Jira aggregates this data on

the dashboard to get an overview of the status of the development[Smi17].

5.3 Develop on our branch with continuous integration

We know that Git can easily do commits on a branch and then merge when we are

ready. We can use full integration test suites against every commit on all current bran-

ches. With the branch builds feature which by Bamboo we can automatically create

build configurations for each branch. Jira can display the status all branch plans con-

nected with tickets, and see the feature development. Additionally Bamboo will inform

Bit Bucket of the status of builds for a branch, and it performs when we get to pull

request[Att17a].

Push our changes to a "rush box"2 . This step is valuable when we have a customer

or internal stakeholder involved in our feature development. We give them a report of

changes and allow them to review them. The advantage of this process is that we do not

use any additional infrastructure or tools, but can perform this process automatically

with the same infrastructure and tools[Smi17].

5.4 Create a pull request for the branch

We have to use the "No direct merge" settings that expect that all merges come via a

pull request. When the development regarding a ticket is finished, we can create a pull

2https://en.wikipedia.org/wiki/Dailies

https://en.wikipedia.org/wiki/Dailies

5.4 Create a pull request for the branch 45

request for the branch.

• All pull request must have approval from at least one reviewer.

• All Bamboo tests from this branch must pass.

In most software development companies, development team members always colla-

borate with each other to get work done. Most of the issues with different functions like

code development, code review, and various software testing methods are transitioned

between team members. The main idea of transitioning issues between the developers

is to reduce the number of errors. One of the best practice for software developers du-

ring the development process is reviewing code. Code review is the way to changes

knowledge, make the team more flexible and fault tolerant[Att17c].

Jira issue tracking provides dashboard for the code reviewer to use in his or her review

of the code see Figure 5.2 [Rad].

Figure 5.2: Track issues

We have two different code statuses in JIRA. First: is writing code and second revie-

wing code. Tests results and code review makes easy for the team to see the current

state of their work. Code expecting review is known to be checked in, built, and appro-

ved by automated testing. Jira’s workflow triggers make it easy to automate updating

issues between states [Rad]. Using this architecture when the developer creates a pull

request JIRA will automatically send the issue from in the state "in progress" to the

state "in review". All involved parties like project managers, developers, and product

owners know the status of all issues. These works come from Bitbucket. Fail or pass


information executed by the Bamboo to Bitbucket (See Figure 5.3). The software deve-

lopment board in JIRA shows each branch, commit and pull request for direct access.

The developers or project managers also can see a history of pull requests that have not

get merged[Smi17].

Figure 5.3: Pass/fail notification

5.5 Merge, package as a release and deploy to staging

When the pull request passed, the merge to the release branch can be performed. Next,

we can perform a full release of the software. At this point, we must use a separate

Bamboo build plan, which first runs the full test suite before incrementing the version

number and pushing to our build repository. Most of the work was about continuous

deployment, but also the work deploy to staging can also be fully automated. To create

a release version of the software, we can create an automatic deployment to our pre-

production stage. This step allows the quality assurance performed on it and possible

review by owners or software development team[Smi17].

5.6 Manage to deployment

The best practices are that we must never push directly out to production server. First

of all, we have to go through quality assurance using the pre-production server. That

5.7 How to start to use new tools 47

is the point where we use Bamboo to control which builds are deployed where and.

Additionally Bamboo reports this information back to JIRA where it is presented inside

the issue tracking that work.

If we do all these jobs described above, we have a release we can do built, deployed

to development, quality assurance and also production environment[Smi17]. The VI-

SUSTORE project development which I described in chapter 3, was missing some im-

portant information for project managers during the software development process.

The questions were:

• How do we know which versions of the software are deployed where?

• How can we manage the development of quality?

• How can we guarantee only some users can make these improvements?

Bamboo’s specific deployment capabilities provide the new deployment environments

possibility. The idea is the same as standard build plans. But the main difference which

is that a single build can deployed to multiple environments and additionally moved on

other servers [Att17a]. Figure 5.4 shows an example overview which version is running

on which environment.

Dogfooding 2.12 branch

Dogfooding 2.13 branch

Staging

Production

atlassian-plugins-release-5.7

atlassian-plugins-release 2.13_(108)

atlassian-plugins-release-5.7

25 sep 2013 07:07 AM

30 Jan 2013 07:07 AM

25 sep 2013 07:07 AM

Figure 5.4: Verion control

5.7 How to start to use new tools

The goal of this research is to facilitate automation process, which increases collabo-

ration between the developers and project managers and also presents internal and

external stakeholder-oriented reporting systems at Zeiss company. As we detailed in

chapter 4 and 5, there are some tools and technologies by Atlassian that support conti-

nuous integration and collaboration practices.

However, for Zeiss, it is important to know which tools should be handled the first


to support software development process and continuous integration process. But the

question is, what are the criteria that confirm that the work should be done in a particu-

lar sequence? and which tool installation should be firstly managed from developers?

To answer these questions we can use the following criteria:

• Tools installation process and compatibility with current devices must not require

lots of efforts for Developers.

• The second criteria could be that developers need less time to learn how the new

tools are working and this process is not delaying their daily development pro-

cess.

5.7.1 Which devices ful�ll these criteria?

The features that we want to use when developers connect JIRA to the development

tools are various, but the recommendation would be to use the latest version of each

application.

If we recall current VISUSTORE architecture for continuous integration chain uses Jen-

kins, and for version control system is used GIT repository.

For example, if developers first install at the same time HipChat, FishEye, and Cruci-

ble it will not bring any problems for developers. Maybe developers need time to learn

how new tools work. But, it will not dealy software development process because these

tools are linked to each other, and in case of unforeseen problems developers can con-

tinue software development process with old architecture.

The second could be installed the Bitbucket. It will provide Git repository manage-

ment. After the installation, these tools bring many advantages for developers and

project managers, for example: After committing code, completing reviews, creating

branches, developers can configure triggers in their workflow to automatically transi-

tion issues if these events occur in development tools. Additionally, developers can set

up a trigger to automatically send a result from "ToDo" to "InProgress" when a branch

is created.

We must not forget that we also aim to build continues integration practice which

brings many advantages for developers and project managers. For this practice, we

want to use Bamboo. It is obvious that Bamboo will be a new tool for developers. Be-

cause currently, developers use alternative tool which is Jenkins. Without Bamboo, we

can not use all the advantages which are offered by Atlassian products. Bamboo for

developers will be new and take some time to understand its specifics. And it impacts

5.7 How to start to use new tools 49

developers productivity.

My recommendation would be that Bamboo must be installed at the end.

5.7.2 Continuous integration solution or development solution

We have to identify two individual solutions to accomplish software development,

transparency and collaboration improvement at Zeiss company. The first represents

software development solution and the second continuous integration solution.

The software development solution would be at Zeiss of tools support that uses the

latest methodologies by Atlassian. With Bitbucket, Fisheye, and Crucible working in

close integration, this development solution provides source code management based

on Git, code reviews, and an excellent code searchability. It unites upstream with pro-

ject management and downstream with continuous integration, empowering the team

to achieve fast and be more productive in project delivery. For software development

improvement we have to first start with these tools:

• Bitbucket.

• Fisheye.

• Crucible.

• HipChat.

To improve continuous integration solution at Zeiss company, we have to use Bam-

boo. Bamboo is scalable, able to run some builds in parallel and has some significant

features. Compare to Jenkins who is currently used at Zeiss, Bamboo simultaneously

supports faster and also controlled release management. Regarding the Bamboo, users

have control over every critical issue. Tasks can be added, edited, and updated with mi-

nimal trouble. Joined with a Git repository and Bamboo’s core features, development

teams benefit from efficient, convenient continuous integration and improved producti-

vity. For continuous integration improvement we have to first start with these tools:

• Bamboo.

• Deployment environments.

• Git.

CHAPTER 6

Evaluation

Uninterrupted progress of the development process simultaneously enhances the soft-

ware quality and increases the efficiency, while making the process itself much more

transparent. These reasons are the basis for most of the applied software methods.

Nevertheless, it is clear-cut that the implementation of any of the new method, regard-

less of how beneficial and efficiency increasing it could be, causes certain costs to the

company. However, in most of the cases, the implementation costs are not considered

detrimental, since we observe firms continuing their effort of increasing efficiency and

transparency of the development process by applying new approaches and reducing

the customer delivery time, that itself in long run results to the reduction of the pro-

duction costs. In order to study and analyze the development process, I did a survey

and conducted number of interviews. Depending on the specific issues during the in-

terview, some of the answers from the developers were subjective. This is obvious, as

everyone would prefer to work in an already accustomed atmosphere

Regardless of the distinction on different issues, every interviewee conceded that they

would have agreed to work with a new architecture that would reduce the routine

and increase the transparency. The initial goal of the thesis was to create a test system

that would have shown us the distinction and pros and cons between the existing and

proposed development methodologies in all the components, such as simplified rela-

tionships, continuous reporting, less errors at QA stage, etc. However, as it appears,

due to the time constraints generating such a complex results and illustrating all these

information merely based on the test system is not sufficient. Using the test systems,

we can show how to connect different tools to each other and how compatible they

could be. But, this won’t illustrate the extent to which the new process simplifies the

communication between the developers and project managers, information flow to sta-

keholders regarding the errors, or decline in errors at the testing stage after the launch.

Having said all these, my proposal is to evaluate the effectiveness of the new system

52 Evaluation

based on three criteria:

• Creating graphical illustration identifying the errors per stage during the conti-

nuous testing process in comparison with the old results.

• Based on the creation of new system, conduct another round of interviews with

the project managers and developers.

• Developer time distribution i.e. illustrating the time spent with e-mail communi-

cation and how the new architecture simplifies their collaboration.

Security of software development goes beyond the effectiveness of the code. It consists

of number of factors, such as planning, developing, testing and production. The quality

and the duration of each step determines the final value of the product. It is obvious

that the team of software developers should always be oriented to reduce the number

of errors by instantaneous spotting and solving. For instance, the following graphical

illustration Figure 6.1 identifies the most important stages during the development pro-

cess that could be useful to avoid increase in errors on the live system. The blue colour

shows that most errors appeared on the final stages which are Production and testing

stages. It is bad for a company because to uprooting errors on the lives system means

increased costs for the company.

Figure 6.1: Unsuccessful software development practice

Planning Development Testing Production

Figure 6.2: Successful software development practice

53

Based on Figure 6.2, we can say that the developing process which is run by the develo-

pers in their local environment is important. Bugs that are spotted and resolved at the

early stages prevent errors during the QA stage and reduce the probability of having a

serious blocking issues at product launch.

The automatic process proposed by me enhances the continuous testing of the develo-

pers codes, enabling us to reduce the emergence of errors on the next stages dramati-

cally. Uninterrupted testing has a direct effect on the final quality of the product. That

can be seen in the following graphical image (See Figure 6.3). After the continuous in-

tegration process if developers get more errors on their local environment and the final

stage will appear fewer errors, it would be the good criteria to prove that continuous

integration practice got advantages for a company.

Figure 6.3: continuous integration testing result

2. Implementation of the proposed architecture should be followed by another survey

of the developers and project managers. That allows us to see the change in the re-

porting system for the managers, increase in transparancy, and what additional infor-

mation with what frequency could automatically be retrieved. Additionally, we should

also interview the developers on the issues such as whether the testing process has been

simplified or not; what is the change in the bug quantity on certain stage; and what’s

their stand on the effectiveness of new architecture.

3. The third evaluation criteria slightly differs from the previous two as it is more in-

dividual. If we assume that on average developers need certain hours for the commu-

nication and reporting via e-mail, one could say that it is an opportunity cost over the

developing process. Nonetheless, as I pointed out, this is still individual, as developers

might spend different amount of time on doing same tasks.

CHAPTER 7

Conclusion

This chapter summarizes the work done in this master thesis, the most relevant results

and the benefits the thesis could deliver for Zeiss.

The master thesis aims at increasing the continuous delivery practices to promote the

transparency and productivity during the software development process at Zeiss com-

pany.

In the beginning, the thesis informs the reader with basic principles and problems of

software delivering, Agile software development methods, continuous integration and

discusses the real integration approaches.

Moreover, in the later chapter the reader is informed, that we used interview research

to understand how software development process works at Zeiss. It was reasonable to

identify the strong and weak sides of software development process which helped us

to develop our proposed architecture.

These chapters cover three main parts, starting with the interviews that we conducted

with the participants within the software development process, followed by the analy-

sis of one particular "VISUSTORE" project.

Finally, the study allowed us to propose a new comprehensive architecture, which can

foster productivity and create much more collaborative working environment. Also,

the reader can see the graphical illustration of approached architecture, selected tools

and also proposed installation steps in detailed.

CHAPTER 8

Appendix

8.1 Questions for Developers

1. Could you explain your daily developing workflow?

2. Could you describe your collaboration with other developers?

3. Which kind of mechanisms do you use for collaborative code review? And how

does it work?

4. What do you think will get you more productive in the future if you will use

collaboration tool (crucible for code review)?

5. How often do you communicate with Project leaders?

6. Do you make an adjustment in the project content at any time during the develo-

ping process?

7. Is it flexible enough your system to discuss technical issues with Project managers

in the Urgent situation?

8. If yes: Could you tell me a simple example?

9. Does Project owner involved in Project development monitoring process?

10. How much transparent your daily developing work and do you make daily re-

porting?

11. If yes: Who can see your current report except your team leader?

12. How often do you have Bug tickets?

13. Does your fixed problem is reported automatically?

14. Does every time Team leader have the new information?

58 Appendix

8.2 Questions for project managers

1. How transparent is for Project Managers daily developing work and do you have

continuous reporting?

2. Do you want to see the Project actual state during the developing process?

3. Why is this information relevant to you?

4. How does it increase your productivity?

5. Is it relevant for you to see the new software test report? Why?

6. Is it important to know which software version is running in which environment

(Deployment status)? And Why?

7. Could you tell me what tools/support or process would you like in the future?

References

[Atl17a] Atlassian. Access real-time status information, 2017. https:

//marketplace.atlassian.com/plugins/net.collabsoft.plugins.jira.

nagios-for-jira/server/overview.

[Atl17b] Atlassian. Search, track, and visualize code changes, 2017. https://www.

atlassian.com/software/fisheye.

[Att17a] Attlasian. Atlassian launches bamboo 4, continuous integration

server: Developers can now test more, configure less, September

2017. http://www.businesswire.com/news/home/20120329005736/en/

Atlassian-Launches-Bamboo-4-Continuous-Integration-Server.

[Att17b] Attlasian. Bitbucket and jira software are seamlessly integrated, from branch

to deployment, September 2017. https://www.atlassian.com/software/

jira/bitbucket-integration.

[Att17c] Attlasian. Lightweight, formal code review, September 2017. https://www.

atlassian.com/software/crucible/features.

[Att17d] Attlasian. Team communication, built for the enterprise, September 2017.

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

[Boe02] Hennie Boeije. A purposeful approach to the constant comparative method

in the analysis of qualitative interviews. Quality & quantity, 36(4):391–409,

2002.

[Che15] Lianping Chen. Continuous delivery: Huge benefits, but challenges too.

IEEE Software, 32(2):50–54, 2015.

[Coi17] C. Aaron Cois. Continuous integration in devops, 2017. https://insights.

sei.cmu.edu/devops/2015/01/continuous-integration-in-devops-1.

html.

https://marketplace.atlassian.com/plugins/net.collabsoft.plugins.jira.nagios-for-jira/server/overview



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

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

http://www.businesswire.com/news/home/20120329005736/en/Atlassian-Launches-Bamboo-4-Continuous-Integration-Server

http://www.businesswire.com/news/home/20120329005736/en/Atlassian-Launches-Bamboo-4-Continuous-Integration-Server

https://www.atlassian.com/software/jira/bitbucket-integration

https://www.atlassian.com/software/jira/bitbucket-integration

https://www.atlassian.com/software/crucible/features

https://www.atlassian.com/software/crucible/features

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

https://insights.sei.cmu.edu/devops/2015/01/continuous-integration-in-devops-1.html



60 References

[DBC06] Barbara DiCicco-Bloom and Benjamin F Crabtree. The qualitative research

interview. Medical education, 40(4):314–321, 2006.

[DMG07] Paul M Duvall, Steve Matyas, and Andrew Glover. Continuous integration:improving software quality and reducing risk. Pearson Education, 2007.

[Dok17] Ansible Dokumentation. About ansible, 2017. http://docs.ansible.com/.

[DT16] Atlassian Software Development and Collaboration Tools. Deploy-

ment projects, June 2016. http://confluence.atlassian.com/bamboo/

deployment-projects-338363438.html?_ga=2.34632929.1355045129.

1504510529-1342834264.1491383069.

[Fra17] Amber Frauenholtz. Deployment projects, May

2017. https://www.atlassian.com/blog/bitbucket/

enterprise-devops-bitbucket-server-5-bamboo-6.

[HF10] Jez Humble and David Farley. Continuous Delivery: Reliable Software Relea-ses through Build, Test, and Deployment Automation (Adobe Reader). Pearson

Education, 2010.

[KA14] Stephan Krusche and Lukas Alperowitz. Introduction of continuous deli-

very in multi-customer project courses. In Companion Proceedings of the 36thInternational Conference on Software Engineering, pages 335–343. ACM, 2014.

[KCS94] Nigel King, C Cassell, and G Symon. Qualitative methods in organizational

research: A practical guide. The Qualitative Research Interview, 17, 1994.

[Li10] Jinjin Li. Agile software development, 2010.

[Rad] Dan Radigan. 5 tips for great code reviews. https://www.atlassian.com/

blog/software-teams/5-tips-great-code-reviews?_ga=2.26894205.

1355045129.1504510529-1342834264.1491383069.

[SBZ17] Mojtaba Shahin, Muhammad Ali Babar, and Liming Zhu. Continuous inte-

gration, delivery and deployment: A systematic review on approaches, tools,

challenges and practices. IEEE Access, 5:3909–3943, 2017.

[Sch16] Christoph Schmidt. Discussion. In Agile Software Development Teams, pages

115–124. Springer, 2016.

[Smi17] Steve Smith. Practical continuous deployment: a guide to au-

tomated software delivery, 2017. https://www.atlassian.com/blog/

continuous-delivery/practical-continuous-deployment.

http://docs.ansible.com/

http://confluence.atlassian.com/bamboo/deployment-projects-338363438.html?_ga=2.34632929.1355045129.1504510529-1342834264.1491383069



https://www.atlassian.com/blog/bitbucket/enterprise-devops-bitbucket-server-5-bamboo-6

https://www.atlassian.com/blog/bitbucket/enterprise-devops-bitbucket-server-5-bamboo-6

https://www.atlassian.com/blog/software-teams/5-tips-great-code-reviews?_ga=2.26894205.1355045129.1504510529-1342834264.1491383069



https://www.atlassian.com/blog/continuous-delivery/practical-continuous-deployment

https://www.atlassian.com/blog/continuous-delivery/practical-continuous-deployment

References 61

[SPP10] M Sokovic, D Pavletic, and K Kern Pipan. Quality improvement

methodologies–pdca cycle, radar matrix, dmaic and dfss. Journal of Achie-vements in Materials and Manufacturing Engineering, 43(1):476–483, 2010.

[sup16] Atlassian support. Checking the progress of a version, August

2016. https://confluence.atlassian.com/jirasoftwareserver070/

checking-the-progress-of-a-version-762877543.html.

[Sza04] Victor Szalvay. An introduction to agile software development. Danubetechnologies, pages 1–9, 2004.

[Wik17] Wikipedia. Bitbucket, 2017. https://en.wikipedia.org/wiki/Bitbucket.

[Wil05] Amanda Wilmot. Designing sampling strategies for qualitative social re-

search: with particular reference to the office for national statistics’ quali-

tative respondent register. SURVEY METHODOLOGY BULLETIN-OFFICEFOR NATIONAL STATISTICS-, 56:53, 2005.

[www16] www.tutorialspoint. Agile software development methods, 2016. http://

www.tutorialspoint.com/agile/.

https://confluence.atlassian.com/jirasoftwareserver070/checking-the-progress-of-a-version-762877543.html

https://confluence.atlassian.com/jirasoftwareserver070/checking-the-progress-of-a-version-762877543.html

https://en.wikipedia.org/wiki/Bitbucket

http://www.tutorialspoint.com/agile/

http://www.tutorialspoint.com/agile/

List of Figures

1.1 Deployment pipeline (from [HF10]). . . . . . . . . . . . . . . . . . . . . . 1

1.2 The CD pipeline’s (from [Che15]). . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Automatically roll back (from [HF10] ). . . . . . . . . . . . . . . . . . . . 6

1.4 Deming cycle (from [SPP10]). . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Scrum Development Framework (from [www16]). . . . . . . . . . . . . . 14

2.2 The relationship between continuous integration, delivery and deploy-

ment (from [SBZ17]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 CI life cycle (from [Coi17] ). . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Database integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 An overview of tools used to form deployment pipeline (from [SBZ17]). 21

3.1 Managment roles in Scrum with different responsibilities . . . . . . . . . 28

3.2 VISUSTORE development chain . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 I,K,Q,P system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 VISUSTORE Quality ensures stages . . . . . . . . . . . . . . . . . . . . . 31

3.5 Visustor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Release Version (from [DT16]). . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Deployment Project with Bamboo(from [Att17a]). . . . . . . . . . . . . . 35

4.3 Atlassian Launches Bamboo 4, Continuous Integration Server: Develo-

pers Can Now Test More, Configure Less (from [Att17a]). . . . . . . . . 36

4.4 Bitbucket branches from a JIRA Software issue and transition an issue

without leaving Bitbucket (from [Att17b]). . . . . . . . . . . . . . . . . . . 37

4.5 crucible (from [Att17c]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Proposed architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2 Track issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Pass/fail notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

64 List of Figures

5.4 Verion control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1 Unsuccessful software development practice . . . . . . . . . . . . . . . . 52

6.2 Successful software development practice . . . . . . . . . . . . . . . . . . 52

6.3 continuous integration testing result . . . . . . . . . . . . . . . . . . . . . 53

implementation of a continuous integra- tion pipeline at ...implementation of a continuous...

Documents