Implementation of a continuous integra- tion pipeline at ...Implementation of a continuous...
Transcript of 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
4 The Problem of Delivering 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
6 The Problem of Delivering Software
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-
8 The Problem of Delivering Software
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.
10 The Problem of Delivering Software
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
2.2 Continuouse integration 17
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.
2.2 Continuouse integration 19
• 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.
2.2 Continuouse integration 21
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-
26 Analysis of the current state
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.
28 Analysis of the current state
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
3.4 Summary of the current project 29
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
30 Analysis of the current state
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.
3.4 Summary of the current project 31
K - Development
I - Development
Q- Development
P- Development
Automated
Manual
Automated
Automated Manual
CAB
Figure 3.4: VISUSTORE Quality ensures stages
32 Analysis of the current state
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
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-
36 Tools for fully automated process
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
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
38 Tools for fully automated process
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
40 Tools for fully automated process
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/
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
44 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
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
46 Proposed architecture
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
48 Proposed architecture
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.
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.
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/.
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