automatic configuration of server side software development environments

Automatic Configuration of Server Side

Software Development Environments

by

Benjamin Ripkens

A thesis submitted in partial fulfillment

of the requirements for the Degree of

Bachelor of Information and Communication Technology

(B.ICT)

Fontys University of Applied Sciences, 2012

Bachelor Thesis Information



Student Information

Name Benjamin Ripkens

Date of birth 12 December 1987

Place of birth Goch, Germany

Institution Fontys University of Applied Sciences

Student number 2124704

Study course Informatics: specialisation Software Engineering

Thesis Information

Timeframe February to June 2012

Day of delivery 5 June 2012

Nondisclosure Not necessary

Company Information

Name codecentric AG

Address Kolner Landstraße 11

Postal code & city 40591 Dusseldorf

Country Germany

Members of the Examination Committee

dr. ir. J.W.M. Jacobs Fontys University of Applied Sciences (academic advisor)

Dipl.-Ing. A. Ebbert-Karroum codecentric AG (company advisor)

Ing. A. Boots Oce Technologies B.V. (external reviewer)

iii

Declaration of AuthorshipI, Benjamin Ripkens, declare that this thesis titled, ‘Automatic Configuration of Server Side

Software Development Environments’ and the work presented in it are my own. I confirm that:

• This work was done wholly or mainly while in candidature for a bachelor’s degree at this

University.

• Where any part of this thesis has previously been submitted for a degree or any other

qualification at this University or any other institution, this has been clearly stated.

• Where I have consulted the published work of others, this is always clearly attributed.

• Where I have quoted from the work of others, the source is always given. With the

exception of such quotations, this thesis is entirely my own work.

• I have acknowledged all main sources of help.

• Where the thesis is based on work done by myself jointly with others, I have made clear

exactly what was done by others and what I have contributed myself.

Signed:

Date:

v

Abstract



by

Benjamin Ripkens

To support the software development process, various server-side applications are used.

Setup and configuration of these applications is a repetitive task in which managers, system

administrators and other persons are commonly involved. Requests for new software develop-

ment environments, e.g., version control or continuous integration systems, are therefore ser-

viced slower and require application specific knowledge which may not be commonly available.

This thesis analyses existing applications that try to improve this process and how companies

are using them. Since no application was found that provides a solution to the problem, the

thesis further describes the development of a new application called Janus. Janus is based on

the assumption that many projects share a common structure which can be defined through

a project template. This template can later be used to generate software development envi-

ronments for similar projects. Janus supports the automatic configuration of Jenkins, JIRA,

Confluence, version control systems and the generation of source code from project templates.

Um den Softwareentwicklungsprozess zu unterstutzen werden verschiedenste serverseitige

Programme genutzt. Setup und Konfiguration dieser Programme sind wiederkehrende Auf-

gaben, bei denen Manager, Systemadministratoren und andere Personen haufig involviert sind.

Anfragen fur neue Software-Entwicklungsumgebungen, z.B. Versionsverwaltung oder Systeme

zur kontinuierlichen Integration werden daher langsamer bearbeitet und erfordern spezifis-

ches Wissen, welches moglicherweise nicht gemeinhin vorhanden ist. Diese Abschlussarbeit

analysiert bestehende Applikationen, um diese Prozesse und deren Nutzung durch Firmen

zu verbessern. Da keine Applikation gefunden wurde, welche das Problem lost, stellt diese

Abschlussarbeit ein neues Programm namens Janus vor. Janus basiert auf der Annahme,

dass viele Projekte eine gemeinsame Struktur aufweisen, welche in Form einer Projektvor-

lage definiert werden kann. Diese Vorlage kann letztlich dazu genutzt werden, Software-

Entwicklungsumgebungen fur ahnliche Projekte zu generieren. Janus unterstutzt die automatis-

che Konfiguration von Jenkins, JIRA, Confluence, Versionsverwaltungssystemen und die Gener-

ierung von Quelltext mit Hilfe von Projektvorlagen.

vii

AcknowledgementsFirst and foremost I would like to thank my advisors Andreas Ebbert-Karroum and Jan

Jacobs. Both have contributed highly valuable feedback, information and guidance. Ton Boots,

besides his role as an external reviewer, arranged a presentation in front of Oce Technologies

B.V. build managers. I am thankful for this opportunity and the good discussions. Also, a

thank you goes out to Pieter van den Hombergh for being my mentor and taking part in the

aforementioned presentation.

A special thank you goes out to my family for supporting me and enabling my studies in

the first place. I also thank Annegret and William Blackmore for improving my English. At

last, I want to thank my girlfriend Jennifer Blackmore for her patience, support and love.

ix

Contents

1 Introduction 1

1.1 Software Development Environments . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 About this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Approach 7

2.1 Software Development Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Analysis 11

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Software Development Environments . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Revision Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.2 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Existing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 GitHub Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.2 Eclipse Skalli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Design 21

4.1 Scaffolds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.2 Continuous Integration Job Configuration . . . . . . . . . . . . . . . . . 23

4.1.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

xi

5 Realisation 27

5.1 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Domain-Specific Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3 Web Service Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4.1 Behaviour-Driven Development . . . . . . . . . . . . . . . . . . . . . . . 31

5.4.2 Simulating User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 Conclusions and Future Work 35

Appendices 37

A.1 Additional Figures and Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.2 Excerpts from the Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A.3 Textual Architecture Decision Documentation . . . . . . . . . . . . . . . . . . . 53

References 59

xii

List of Figures

1.1 UML class diagram illustrating the basic software development environment do-

main concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Overview of all phases and Scrum sprints. . . . . . . . . . . . . . . . . . . . . . 9

3.1 Total number of projects that are using the open source continuous integration

system Travis. Data from [37]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Number of plug-ins per continuous integration system. Data from [2, 9, 20, 26]. 15

3.3 Google search trends for commonly used project management applications. Data

from [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Integration test strategy illustrated using a UML activity diagram. . . . . . . . . 32

6.1 An extension of the domain model shown in Figure 1.1. This domain model

illustrates the concepts of a scaffold. . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2 UML component diagram which shows the component relationships and depen-

dencies. The janus component is described as the core of Janus throughout this

thesis to create a differentiation to the UI component. The UI component is

called janus-plugin in this diagram. . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3 Semantic model for the scaffold DSL. . . . . . . . . . . . . . . . . . . . . . . . . 38

6.4 UML activity diagram illustrating the project bootstrap process. . . . . . . . . . 41

6.5 Sample sprint backlog (from sprint two) with burndown and project overview

chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.6 Architecture decisions and relationships visualised using the notation outlined

in [38]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.7 UML deployment diagram depicting interactions between the various systems

and how the Janus application is deployed. . . . . . . . . . . . . . . . . . . . . 47

6.8 A UML class diagram showing how the web service client hides the differences

between the two available web services, i.e., REST and SOAP. . . . . . . . . . 48

xiii

List of Tables

1.1 Estimated costs of project start delay. . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 VCS distribution statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.1 Product backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Non-functional requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 Architecture forces view which shows how each architecture decision is ranked

in context of its alternatives. Results of this comparison were used to support

the decision making process. The forces view is based on [38]. . . . . . . . . . . 45

6.4 Risk effect level definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5 Risk probability level definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xv

List of Acronyms

API Application Programming Interface

ASF Apache Software Foundation

BDD Behaviour-Driven Development

CASE Computer-Aided Software Engineering

CI Continuous Integration

CVCS Centralised Version Control System

CVS Concurrent Versions System

DSL Domain-Specific Language

DVCS Decentralised Version Control System

FOSS Free and Open Source Software

GUI Graphical User Interface

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

httpd Hypertext Transfer Protocol Daemon

I/O Input/Output

IDE Integrated Development Environment

JDK Java Development Kit

JSON JavaScript Object Notation

JVM Java Virtual Machine

PMC Project Management Committee

PMS Project Management System

xvii

POM Project Object Model

REST Representational State Transfer

RPC Remote Procedure Call

SDE Software Development Environment

SLF4J Simple Logging Facade for Java

SOAP Simple Object Access Protocol

SVN Subversion

TDD Test-Driven Development

TFS Team Foundation Server

UI User Interface

UML Unified Modelling Language

VCS Version Control System

XML Extensible Markup Language

xviii

Chapter 1

Introduction

Projects are started on a frequent basis in many software developing organisations. This is

especially true for companies like the codecentric AG which offer custom software development.

The codecentric AG, as this thesis’ sponsor and main stakeholder, is developing software ac-

cording to customer requirements as part of the corporate division Agile Software Factory. For

every newly started project, certain steps and activities are necessary in order to configure

software development environments (SDEs). SDEs are commonly associated with developer

workstations and the installation of IDEs, compilers and other CASE tools. This thesis is

not concerned with the aforementioned installation use case, but, as Section 1.1 details, about

automatic configuration of servers-side applications.

Manual activities in the beginning of projects result in various issues, most prominently: a

delay. This delay impedes engineers’ work and may require the involvement of third parties,

for instance, system administrators for the configuration of a new SDE. Needless to say, every

delay stresses project budgets and should therefore be strived to be avoided. Depending on

team size and the type of project, this delay may be neglectable or an impediment. The problem

is further elaborated in Section 1.2.

This thesis presents a novel approach to the acceleration of project starts. Through a new

application which simplifies and aggregates common configuration steps and allows for the

generation of an initial set of source code, not only are project starts accelerated, but new

possibilities gained. For instance, the generation of source code can explicitly be leveraged to

maintain common technology stacks and to document architecture. Also, since SDEs can be

configured in a matter of minutes, SDEs can be used for training purposes and prototypes.

1.1 Software Development Environments

As software is expected to fulfil increasingly demanding use cases, while maintaining interoper-

ability with existing systems and high quality, complexity increases. This development can be

further observed during software evolution as found in [36]. To accommodate this development,

1

2 Chapter 1 - Introduction

an increasing amount of applications and tools are used to support the software development

process. Complexity, team size, company policies, project dependencies, compliance certifi-

cations, decentralisation and others may require the addition of tools to companies’ toolsets.

Such applications and tools are generally referred to as computer-aided software engineering

(CASE) tools.

For instance, decentralisation requires that programs are used to coordinate processes that

were previously not necessary. While centralised teams might document project progress on a

wall through task boards, this is not an option for decentralised teams. In such cases, project

management tools are needed that enable sharing information over the Internet.

Most projects make use of three types of applications to support the software development

processes. The systems are shortly introduced in the following listing.

Version Control Version control systems like Subversion, Git and others maintain a history

of document and file revisions so that previous versions can be restored. This may be nec-

essary to reproduce errors or to restore application logic which was mistakenly removed.

In addition, code is commonly shared among developers and backed up through these

systems.

Continuous Integration The practice of continuous integration (CI) was introduced through

the Extreme Programming community and is nowadays considered best practice [28].

Continuous integration is the process of continuously integrating and verifying changes

in the context of the whole application.

Project Management The last application type is actually a combination of tools for docu-

mentation and issue tracking. Project hosting services like Google Code and GitHub as

well as systems like JIRA and Confluence provide a combination of issue management

and wiki for documentation and other purposes.

As Figure 1.1 shows, the systems are interacting with each other. Continuous integration

systems need access to version control systems in order to retrieve the source code and compile,

validate or fulfil other jobs with it.1 On the other hand, a continuous integration system can

update a project management system, e.g., by adding new issues to the issue tracker when jobs

fail.

1A continuous integration system activity or task is commonly referred to as a job, build or build job.

1.2 - Problem 3

ProjectSourceCode

ContinuousIntegrationSystem

VersionControlSystemProjectManagementSystem

1

1..*

*

*

*

1

1..*

*

1..*

1

1..*

1

1..*

*

1

1..*

retrieves source code from

has

updates

has

validates

is located in

has

has

Figure 1.1: UML class diagram illustrating the basic software development environment domainconcepts.

1.2 Problem

Through the growth and usage of nearshoring-teams, an impediment arose at the codecentric

AG which manifested itself especially in the beginning of new software projects. SDEs need to

be configured for every new project in order to support the development process. Since projects

are frequently started in the codecentric AG, this became problematic.

Even in quite liberal companies like the codecentric AG, only a small number of people

have the required access rights, e.g., system administrators. These are commonly the contact

persons for SDE configuration. This yields various problems.

Personnel unavailable System administrators (or the like) may be unavailable. Naturally,

this results in a delay, but it may have further consequences. For instance, the request

for a SDE may need to be queued in a ticket system. This requires the requester to write

down his request thus introducing an additional source for misinterpretations.

Misinterpretation The contact persons may misinterpret the request and thus misconfigure

the applications or choose the wrong ones. This problem is more likely to occur when

requesters are required to write down their needs.

Inflexible Since system administrators always need to be involved in the creation of SDEs, it

is not possible to create SDEs for training or other purposes that may not directly result

in a business value.

For the codecentric AG, these factors alone result in a delay of one day per project start.

This single day costs the company something between 2400e and 7200e as Table 1.1 shows.


Estimated delay 1 dayTeam size 3 - 9Working hours per day 8 hoursAverage hourly wage 100e

Estimated costs of delay 2400e to 7200e

Table 1.1: Estimated costs of project start delay. This calculation solely takes the softwaredevelopers into account. Other personnel like product-, project managers or system admin-istrators are also likely to be involved, though costs of delay for those roles are increasinglycomplex to calculate and inaccurate. The average hourly wage of codecentric AG employedsoftware developers is used.

When taking the average hourly wage of 68e for freelancing software developers as an

industry median, the total costs amount to 1632e to 4896e [35]. In addition to the delay, the

manual setup of SDEs is problematic. Many application settings are system wide, i.e., settings

apply to all projects which use the application. Due to this, a misconfiguration may hinder

many project teams and can have effects ranging from decreased productivity to data loss.

The codecentric AG is not the only company which is facing problems with setup and

configuration of SDEs, for instance, Oce Technologies B.V. has already shown interest in Janus

and is discussing further development.2 While the problem is not commonly discussed, it is

particularly visible in open source software foundations like the Apache Software Foundation

(ASF) and the Eclipse Foundation. Either foundation has a project incubator which is the entry

point into the foundation. Projects in the incubation phase are obliged to work on a whole list

of incubation items that range from copyright and distribution rights to infrastructure. The

following excerpt from the ASF project incubation guideline shows how work intensive these

tasks are.

Once the board has approved the resolution, your project PMC can work together with

the Infrastructure team to get your project established. To help facilitate this, you are

requested to file separate issue tracker requests for each category of item in this list: core,

qmail, SVN, httpd, mailing lists. For each mailing list and SVN repository you desire,

you will need to follow the list of project-specific tasks. After the above is done by the

infrastructure team, please review the tasks that the new PMC should do.

Apache Software Foundation [1]

To summarise the problem:

The start of software projects is commonly delayed through manual

activities and mandatory access rights for the setup of software development

2Oce Technologies B.V. is mainly concerned with embedded engineering and is therefore a contrast to code-centric AG’s web development. The Oce Technologies B.V. is mentioned to highlight the problem’s impact ona different software development field.

1.4 - Terminology 5

environments.

1.3 Terminology

The following terms are used regularly throughout this thesis and require further explanation.

Software development environment A combination of applications and tools that are used

to improve the software development process. This generally includes text editors, in-

tegrated development environments (IDE), issue trackers, version control systems and

more. In this thesis, the term software development environments refers to applications

that need to be configured on some kind of server, for instance, Atlassian JIRA, version

control systems or issue trackers.

Bootstrap The process of starting a new project. In the context of this thesis reduced to the

setup and configuration of software development environments.

Job and build job Both refer to configurable units of work which are to be executed by a

continuous integration system when some event occurs, e.g., a file changes, a URL is

accessed or a timer expires. Common tasks include source code compilation, execution of

tests and more.

Scaffold Basic foundation for a project’s source code. A scaffold includes directories and

files. Either of which need to be project generic so that new projects can benefit from

these scaffolds. Companies’ technology stacks may be described through scaffolds thus

capturing tacit knowledge and making it reusable. A scaffold can furthermore be executed,

meaning, the application of a scaffold for a specific project. At last, a scaffold may define

multiple CI system build jobs. Catalogues can be used to create an overview of available

scaffolds.

1.4 About this Thesis

This thesis presents the process and results of this project. Following the Scrum development

management method, a new application called Janus3 was developed to improve the bootstrap

process for new software development environments.

In general, this thesis assumes basic knowledge about continuous integration, revision con-

trol and group collaboration software likes issue trackers and wikis. Application specific knowl-

edge, e.g., about Mercurial or Jenkins, is not required but can be beneficial. Some of the chap-

ters contain references to excerpts from code listings, for instance, class-, method- or variable

3Named after the ancient Roman god of beginnings and transitions, Janus should emphasise that the projectwill be useful to bootstrap new projects [39].


names. These references are formatted using a fixed-width font. References to application

components are written in lower camel case, e.g., jira and projectManagement.

The remainder of this thesis is structured as follows:

• Chapter 2 elaborates on the approach used for this project and the development method.

It furthermore outlines the project’s schedule.

• Chapter 3 lists the requirements of the codecentric AG and analyses how they align with

the overall objective of benefiting from open source contributions. It also reviews existing

solutions with respect to the result of the previous analysis.

• Chapter 4 builds on the analysis results and shows how the functional and non-functional

requirements influenced Janus’ architecture and design.

• Chapter 5 describes the realisation of Janus’ domain-specific language, how the configu-

ration of Atlassian products is unified and the testing strategy.

The thesis concludes with a summary and ideas for future work in Chapter 6.

Chapter 2

Approach

The purpose of this chapter is to give a broad overview of the project management, respectively,

software development method. The different phases of the software development life cycle, i.e.,

analysis, design, implementation, testing and evaluation, were interleaved to accommodate

changes and leverage gained expertise. Following agile principles, none of the phases were done

in isolation.

Section 2.1 describes how the team size influenced the choice of an appropriate development

method and how the Scrum process was adapted to the team’s size. Based on the approach,

a broad plan was drawn up. This plan was used to communicate the possible goals and the

schedule with stakeholders. Section 2.2 shows and explains this plan, i.e., the work breakdown

structure. This chapter concludes with Section 2.3.

2.1 Software Development Method

Even though the project was done by a single engineer, a software development method was

followed. Scrum and other agile methods can be a good fit for small teams or even a single

person as such teams also need to react on changing and potentially unclear requirements.

Scrum was chosen for this project. The familiarity with Scrum enabled the adaptation to the

team size thus reducing the overhead which some tasks would have resulted in. From the Scrum

process, especially the following two core principles were of interest, despite the team size.

Timeboxing Timeboxing improves planning and scheduling by defining the available amount

of time in advance, i.e., before a meeting or any other activity. Considering the team size,

it is easy to forget the team or schedule when only a single person is involved. The time

box can be used as a guideline or contract. This is especially valuable since the bachelor

thesis is partially written on company hours.

Shippable code Potentially shippable products are Scrum’s definition of ”done”. The defi-

nition can be extended with continuous delivery concepts. Continuous delivery requires

7

8 Chapter 2 - Approach

automated build, test and deployment processes in order to improve reproducibility and

maintainability.

Scrum defines three roles: development team, product owner and Scrum master. For this

project, all three roles were merged and fulfilled by a single engineer. Like the roles, certain

meetings’ objectives were changed or left out completely. Above all, this applied to the daily

stand-up, sprint planning and sprint retrospective meetings. The meetings were needless as

no other engineers needed to be informed about project progress, impediments or a sprint

reflection. The latter, i.e., sprint retrospective, was useful though as it was used to consciously

reflect upon the work. Of course, this activity did not take place as part of a sprint retrospective

meeting. The same applies to the sprint planning, which was done, but not as part of a meeting.

Unlike the meetings and roles, all Scrum artefacts were used for this project since they are team

size independent.

2.2 Schedule

The project was divided into three different phases. The first one, analysis, marked the be-

ginning of the project. The phase was used to elicit requirements and to research commonly

used software development tools and applications, as well as existing applications that aim to

improve the project bootstrap process. The gathered information was used to evaluate the

aforementioned applications with respect to the requirements of the codecentric AG and open

source projects’ SDEs. Depending on the research’s outcome, the following phases might have

had completely different objectives. For the case that an existing application was found that

covers a fair amount of the requirements, the majority of the work would have required changes

to the existing application and to introduce the application to the codecentric AG, for instance,

setup of a production environment. On the other hand, if no existing application covered the

requirements, the following phases would focus on the development of a new application. Rel-

atively fast, it became obvious that no existing application fulfils the requirements, as Chapter

3 details. For this reason, the remainder of the analysis phase was used for prototyping and to

outline a preliminary architecture.

The second phase consisted of four Scrum sprints. With each sprint taking three weeks, the

second phase continued till the end of the university supervised and bachelor thesis relevant

timeframe. A three week sprint length aligned nicely with the available time and was further a

good trade-off between stakeholder availability and feedback. Shorter sprints were problematic

as the stakeholder only had limited time and thus was not able to participate in any more

meetings.

The project concluded with a six week wrap-up phase. While longer than the recommended

Scrum sprint length of four weeks [34], splitting the phase into two smaller phases would not

have provided any benefits. The larger amount of organisational tasks and the bachelor thesis

2.3 - Conclusions 9

deadline would have alleviated the benefits. This phase was used for tasks like documentation

and tooling around the Janus application with the overall objective of improving usability and

robustness of the application.

For an overview of all phases and the Scrum sprints, as well as the phases’ objectives, please

refer to Figure 2.1.

Year Month Week Sprint Description

2012

February

5

Analy

sis

6

7

8

9

1 Automatic creation of repositories; intermediate report

March

10

11

12

213

April

14

15

316

17

18

4

May

19

20

21

Wra

p u

p22

June

23

24

25

26

Requirements analysis; project plan; research; work schedule; architecture; prototyping

Scaffolding support for common project types; intermediate presentation

Automatic continuous integration job creation; JIRA research spike

Automatic creation of projects in JIRA / Confluence / Greenhopper; documentation; bachelor thesis

Buffer for any unanticipated delay; bachelor thesis; documentation; tooling; handover; bug fixing

Figure 2.1: Overview of all phases and Scrum sprints.

2.3 Conclusions

Despite the team size, a process can be followed. Scrum was adapted to fit this project’s needs

by removing meetings. Without superfluous meetings1, the process resulted in little overhead

while providing valuable information for sprint and release planning. Estimation improved

steadily and, in the second half of the project, enabled reliable planning of meetings and

presentations ahead of a feature’s actual realisation (where the feature is required or desirable

for a meeting or presentation).

Sprints were planned and progress was documented in product and sprint backlogs. The

appendix contains a sprint backlog, sprint burndown chart and project overview chart (aggre-

1Certain meetings are only superfluous due to the team’s size.

10 Chapter 2 - Approach

gated under Figure 6.5). In the beginning, task points were used to plan sprints. From sprint

three onwards, this was changed to man-hours for more reliable estimation.

Chapter 3

Analysis

This chapter covers the results of the early analysis phase. As Section 2.2 explained, the analysis

phase was used, among others, to elicit requirements. These requirements are the specific

requirements of the codecentric AG. Due to the company’s role as this thesis’ sponsor, their

requirements are important and therefore defined the outline of this thesis. The requirements

are introduced in Section 3.1.

Project start delays are not a problem which is specific to the codecentric AG, but a common

one for organisations with frequent project starts. The codecentric AG recognised this early and

is willing to take the requirements of the open source community into account. Among others,

this resulted in an analysis of commonly used server-side CASE tools. In order to identify

common CASE tools, various resources were used and evaluated. Section 3.2 elaborates on this

analysis.

One result of this analysis is that some applications were found which try to improve project

starts. Two of the most prominent ones, Eclipse Skalli and GitHub Enterprise, were evaluated

in Section 3.3 with respect to the requirements of the codecentric AG and the requirements of

the open source community. At last, Section 3.4 concludes this chapter with a summary.

3.1 Requirements

From a high-level view the project is concerned with the problem of software project start delays

as mentioned in Section 1.2. The foremost objective is to reduce this delay to a minimum. This

requires three steps as defined through the codecentric AG’s requirements. The first one is

automatic creation of VCS repositories and PMS workspace creation.

By automating the setup already two out of the three common systems mentioned in Section

1.1, i.e., all but CI, will be configured. Either system requires a small amount of project-specific

information. In an optimal case they only require the project name, but further information

like contributors and stakeholders may be necessary in order to authorise the respective parties

or to fulfil other tasks. The second step requires the generation of CI configurations, i.e., build

11

12 Chapter 3 - Analysis

jobs which are specific to a project. Source code and build job configurations are closely coupled

as build jobs describe tasks which are executed against a source code set. For this reason, the

project’s objective was extended with source code generation. Janus should be able to generate

project starting points for common project types from project templates (later referred to

as scaffolds). These starting points may contain source code and configuration files, but also

directory structures and executables. Once the whole setup of SDEs is automated, the last step

and requirement prescribed the empowerment of configuration managers, software engineers and

similar. The aforementioned persons should then be able to execute the previously mentioned

steps without active supervision, even when they were formerly not given configuration access

rights for these systems.

Some of the requirements indicate a need for tool support. CI configurations and scaffolds

are such candidates. The stakeholders requested tool support for the creation of project scaf-

folds from existing projects and the possibility to manage scaffold catalogues. In addition to

these low-priority requirements, a few others can be seen in the product backlog (Table 6.1

in Appendix A.1). Non-functional requirements are contained in Table 6.2 (Appendix A.1).

Summarising, the following functional requirements define codecentric AG’s minimum viable

product.

• Automatic workspace creation in Atlassian JIRA and Confluence

• Automatic creation of one or more build jobs per project in Jenkins

• Automatic creation of a Mercurial repository

3.2 Software Development Environments

The concept of SDEs was introduced in Section 1.1. This section analyses the various alterna-

tives for each application type. This is necessary to identify applications that appeal to a wide

range of possible users. Each section makes use of empirical evidence of popularity to identify

common tools and applications that should be supported for automatic setup and configura-

tion of software development environments. This analysis is done to ensure that not only the

requirements of the codecentric AG are taken into account, but also the requirements of the

open source community. Through this, the chances for open source contributions should be

improved and further insights into CASE tools gained.

The analysis starts with the VCSs Subversion, Git, CVS and Mercurial in Section 3.2.1.

These were found to be the most commonly used ones. The second Section (3.2.2) covers CI

systems. Jenkins, favoured by the codecentric AG, as well as Hudson and the less commonly

used CruiseControl and Bamboo are analysed with respect to the number of available plug-ins

as an indicator for popularity. PMSs, i.e., applications like JIRA and Team Foundation Server,

are covered in Section 3.2.3. At last, the findings are summarised in Section 3.2.4.

3.2 - Software Development Environments 13

3.2.1 Revision Control

Throughout this thesis, no distinction is made between centralised (CVCS) and decentralised

(DVCS) VCSs as either make revision control possible. Furthermore, the VCSs will not be

analysed regarding their features, recommendability or skill required as this was done by others

[30, 31]. Instead, this thesis covers the distribution of version control systems throughout open

source projects with the help of Ohloh1 as well as job offerings on Indeed.com2. The analysis is

limited to the VCSs Subversion, Git, CVS and Mercurial as they are the most-commonly used

VCSs according to [7]. Statistical data from the aforementioned sources was collected in Table

3.1.

VCS name Ohloh (%) Indeed.com (matches, %) Indeed.com (growth) Search term

Subversion 57 ∼0.26 <25.000 subversionGit 26 ∼0.15 ∼50.000 gitCVS 13 ∼0.05 ∼0 cvs version controlMercurial 2 <0.05 ∼200.000 mercurial

Table 3.1: VCS distribution statistics. The second column shows the number of indexed opensource projects that are using a specific VCS in percent [7]. Columns two and three containinformation about job offerings that match the search terms shown in the last column [24].

As Table 3.1 shows, Subversion is the dominant VCS for open source projects. Due to its

stability and age, many projects and organisations, e.g., Apache Software Foundation, are using

it. The Indeed.com growth figures already reveal that just a small amount of new company

driven projects will be using Subversion for revision control. Though it should be noted that

Subversion still results in the most job matches.

According to Ohloh, Git is the second most used VCS for open source projects and results

in many job matches. With growth figures of ∼50.000 it beats Subversion while only having a

quarter of Mercurial’s growth.

Mercurial does not seem to be widely used for open source projects, but many companies

seem to move towards it. Especially in the last years a significant increase can be observed.

When companies switch to DVCSs, most seem to choose Mercurial for its ease-of-use and

Microsoft Windows support.

For ease of learning and use, Mercurial and Subversion have simple command sets that

resemble each other (easing the transition from one to the other), whereas Git exposes a

potentially overwhelming amount of complexity. Bryan O’Sullivan [33]

1Ohloh is a software directory which analyses open source projects’ VCSs. By doing so, it enables monitoringof developer activity and generation of statistical data, e.g., which VCSs are commonly used.

2Indeed.com is a search engine for job listings. Unlike general purpose search engines, it is limited to joboffers and related topics, e.g., salary search and job trends.

http://www.indeed.com


At last, large amounts of source code are maintained in CVS repositories. Yet, the data

indicates that CVS is reaching its end of life.

To summarise, the majority of the projects are using either Subversion, Git, CVS or Mer-

curial for version control. Subversion and CVS have gained a strong user base over the years,

but commercial usage is static. Git and Mercurial on the other hand are gaining popularity.

Git is already commonly used for open source and commercial projects, but records a smaller

commercial growth than Mercurial. The open source community seem to prefer Git while

companies are favouring Mercurial according to Indeed.com’s growth statistics.

3.2.2 Continuous Integration

Continuous integration and its predecessor, the daily build, have been around for several years.

With the availability of applications like Hudson, Jenkins, CruiseControl and others, the prac-

tice is becoming widely used [12]. This is not only true for job trends, which record a growth

rate of more than 300% for job descriptions that contain the phrase continuous integration3,

but also open source projects are adopting it as the statistics for the free continuous integration

system Travis show (see Figure 3.1).

Dec 2010Feb 2011

Apr 2011Jun 2011

Aug 2011Oct 2011

Dec 2011Feb 2012

Apr 2012

0

2000

4000

6000

8000

10000

12000

Figure 3.1: Total number of projects that are using the open source continuous integrationsystem Travis. Data from [37].

Job offers and additionally Google search trends have been analysed. Unfortunately, the

ambiguity of the applications’ names result in inconclusive results. Matched job offers further-

more commonly contain multiple application names, probably to indicate that some experience

with continuous integration is required.

3In contrast, the number of job offers with the phrase software development increased by roughly 50% [22].

3.2 - Software Development Environments 15

As an alternative approach the number of plug-ins that are available per application were

analysed. Many continuous integration systems only provide basic functionality which can be

extended through plug-ins to match the users’ needs. For this reason they can at least indicate

trends towards certain applications. The results are illustrated in Figure 3.2.

0

100

200

300

400

500

600

521

369

92 87

Jenkins

Hudson

CruiseControl

Bamboo

Figure 3.2: Number of plug-ins per continuous integration system. Data from [2, 9, 20, 26].

As the figure shows, Jenkins and Hudson clearly dominate with respect to the number of

plug-ins. Jenkins’s amount of plug-ins is especially important given the fact that it was first

released on 2 February 2011 [27].4

The other CI systems, i.e., CruiseControl and Bamboo, only have about one sixth of Jenkins’

number of plug-ins. While this could mean that both provide more functionality out of the

box, it could also infer that the demand for plug-ins is simply smaller as fewer people are using

these systems.

Concluding, Jenkins and Hudson have a strong lead when it comes to the number of plug-ins.

Even though Jenkins is a young fork of Hudson, it managed to surpass Hudson. CruiseControl

and Bamboo only seem to be rarely used.

3.2.3 Project Management

The last group of applications are the project management applications or tools. They are

frequently used to keep track of project progress and return on investment by project managers

4Jenkins is a Hudson fork and as such was compatible with the Hudson plug-ins at the time of its release. Inthe small amount of time since the fork Jenkins has been able to attract a significantly larger amount of plug-indevelopers.


and the like. For the team, such applications are commonly used as a source for documentation

and work items.

Many hosting services provide such functionality out of the box. While open source projects

can benefit from these free possibilities, it is problematic for companies. For instance, company

policy may forbid that information is shared with third parties. For this reason, only appli-

cations that can be deployed in a private network are analysed. For this analysis the Google

search trends are the most useful data source (Figure 3.3).

Jan 20

06

Sep 20

06

May

200

7

Jan 20

08

Sep 20

08

May

200

9

Jan 20

10

Sep 20

10

Apr 201

1

Dec 201

1

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

JIRA Redmine

Bugzilla Team Foundation Server

Figure 3.3: Google search trends for commonly used project management applications. Datafrom [19].

As the figure illustrates, JIRA replaced Bugzilla as the most commonly used application.

It was even surpassed by Redmine, a rather new application which is free and open source

software (FOSS), according to this data. Still, some mature open source projects like the Linux

Kernel or the GNOME desktop environment as well as the Eclipse- and Mozilla Foundation

make use of Bugzilla. This is likely due to the complex transition that would be necessary in

order to use a different application.

The Google search trends provide nice hints and guidelines which applications are used and

how common they are. Unfortunately, this data source has its problems. For one, a fair amount

of users does not use Google’s search engine in the first place. Next, once a project management

3.3 - Existing Applications 17

system is set up, it is less likely that its users are searching for information about it. At last,

the search trends only show overall traffic and make no distinction between commercial and

open source usage. This is especially problematic with respect to the numbers for the Team

Foundation Server (TFS). The job site Indeed.com shows, as opposed to the Google search

trends, that more job offers are mentioning TFS, rather than JIRA [23].

To summarise, even though TFS might not be searched for as often as the other tools, the

number of job offers show that it is, in fact, at least commonly used for commercial purposes.

JIRA shows up commonly in Indeed.com job offers and can record the most Google search

queries among the four applications. Bugzilla and Redmine only seem to be commonly used

among open source projects.

3.2.4 Conclusions

This section showed statistics for three commonly used applications types. Jenkins, as a contin-

uous integration system, seems to surpass its predecessor and other applications. For revision

control and project management, no single application could be identified that surpasses its

competitors with respect to the number of users and distribution among open source and com-

mercial projects. While some applications show a vast distribution among commercial projects,

for instance, TFS, they are seldom used for open source projects. Applications like Git show

that the industry is either slower when it comes to the adoption of new technologies, or that

such applications are simply too complicated or different than the previously used application.

To come to a conclusion, a common subset of the analysed applications should be supported

by an application in order to be widely applicable. When solely taking open source into account,

a combination of Git, Jenkins and JIRA or Redmine seems appropriate. All aforementioned

technologies are either FOSS or free licenses can be requested for open source projects.

Commercial projects on the other hand have different requirements and, as seen in the

previous sections, use different applications. For these projects, Mercurial and Git support

seem to be significant. Jenkins can also be used for commercial projects. As for project

management, JIRA seems to be the best choice even though TFS might be more popular for

the development of Microsoft based systems. This also resembles codecentric AG’s technology

stack (see Section 3.1). An application for bootstrapping of software development environments

should therefore at least support JIRA, Jenkins and either Git or Mercurial.

3.3 Existing Applications

Two applications were found which fulfil at least some of the requirements. Both are presented

in the following subsections. GitHub Enterprise is a self-hosted version of the successful GitHub

hosting service. It is introduced in Section 3.3.1. The second application (Skalli) is a joint

venture project. Nowadays under the umbrella of the Eclipse Foundation’s incubator it is

http://www.indeed.com


FOSS (Section 3.3.2).

3.3.1 GitHub Enterprise

GitHub is an increasingly important platform for open source software development. It pro-

vides free VCSs, issue trackers, website hosting and wikis for FOSS projects. Among others,

influential projects such as the Java Spring Framework, jQuery, the key/value store Riak and

Facebook’s source code transformer HipHop are using GitHub. Companies and individuals

interested in hosting closed source software can choose from either a hosted version of GitHub

or host it themselves using GitHub Enterprise.

For companies with strict compliance rules, GitHub Enterprise is the preferable option as

source code does not need to be stored on third-party servers. Among the GitHub Enterprise

users are large and small organisations. Most notably World of Warcraft publisher Blizzard

Entertainment and managed hosting solutions provider Rackspace [17]. Since GitHub provides

a vast range of services out of the box, it is interesting with respect to the problem of SDE

bootstraps.

GitHub Enterprise almost fulfils the requirements for a minimal viable product (Section 3.1).

Instead of configuring a set of applications, GitHub Enterprise provides its own versions of an

issue tracker and others. This is unfortunately the largest issue - the requirements explicitly

state that Mercurial, Jira and Jenkins should be supported. Since GitHub Enterprise is closed

source software and does not provide any support for those applications, it is not an option for

the codecentric AG.

3.3.2 Eclipse Skalli

Skalli is a provisioned project in the Eclipse Foundation which aims to solve a subset of the

problems identified in Section 1.2. Its main objective resolves around project visibility. In large

organisations many libraries, frameworks and components exist and are often re-engineered

since no central project dictionary or library exists to search for those reusable components.

First efforts in this direction date back to at least October 2007 at which point SAP AG

employee Dirk Riehle gave a presentation about Open Source Research: Analytics, Economics

and Best Practices [11]. The current version of Skalli improves this visibility by applying some

of the features of FOSS project hosting sites to closed source software projects. The most

interesting functionality with respect to this thesis is the ability to automatically setup version

control systems and related tools.

The Skalli project is backed by large organisations. Main contributors come from SAP AG,

Red Hat, Inc. and Deutsche Telekom AG. Unlike GitHub Enterprise, Skalli is open source and

missing functionality can be contributed [6]. Unfortunately a major problem with Skalli is the

the lack of project activity [13].

3.4 - Conclusions 19

3.3.3 Conclusions

GitHub Enterprise and Eclipse Skalli provide solutions to specific use cases. GitHub Enterprise

is a one size fits all solution which only provides limited possibilities for customisation and

therefore requires organisational change. It is not an option for the codecentric AG to suddenly

change their working environments as this would require employee training and changes of

existing scripts or applications.

The Eclipse project Skalli is immature, but could almost be a perfect match for the code-

centric AG. It is FOSS and could thus be extended with not yet provided functionality. Unfor-

tunately the limited time did not permit Skalli contributions.

3.4 Conclusions

A set of applications was identified which seem to dominate in their respective area of appli-

cation types. Luckily, these applications align with codecentric AG’s technology stack. Due to

this, the chance for open source contributions is greatly enhanced.

The analysis also shows that applications can be replaced rather fast. This is emphasised

by an internal codecentric AG document which states that Git is interesting and may replace

Mercurial as the VCS of choice. While this does not match the growth rate as seen in Table

3.1, the interest matches the overall adoption of Git. An ideal application would therefore need

to be able to cope with changing CASE tools.

Unfortunately, neither GitHub Enterprise nor Eclipse Skalli can convince. Both applications

fulfil one or more of the codecentric AG’s requirements, but addition of lacking features is either

not possible due to proprietary source code or complicated as a result of lacking documentation

and activity. This being the case, the development of a new application is the only option.

Chapter 4

Design

Janus does not have strict non-functional requirements which enforce availability or stability.

With the current use cases, Janus will be used for project starts and could, in theory, be

deactivated or shut down till the next time it needs to be used. The design focuses on other non-

functional requirements and forces. For instance, Janus must not misconfigure applications and

it should be able to cope with changes. This chapter documents how some these requirements

were taken into account and fulfilled.

Section 4.1 describes the concept of scaffolds with source code generation and CI configura-

tion. A broad overview of the architecture is given in Section 4.2. This chapter concludes with

Section 4.3.

4.1 Scaffolds

Scaffolds are Janus’ concept of project templates. They provide abstract representations of

commonly needed project types which can be created and maintained by architects, domain

experts and similar. Through scaffolds, knowledge can be captured and made reusable. Instead

of looking through a company’s internal documentation on standard technology stacks for

desktop applications, employees can generate starting points from scaffolds. A scaffold consists

of three parts:

Source code Source code is the central pivot of scaffolds. From an existing project, a project

scaffold may be harvested in order to save time in the beginning of new projects in the

future. Maintained by architects, a scaffold can capture tacit knowledge and help on

the way to homogeneous company technology stacks.1 Section 4.1.1 covers the scaffold

contained source code in more detail.

Continuous integration system configurations Automatic configuration of CIs, specifi-

1A homogeneous technology stack is desirable as employees only need to be trained in a well-known set oftools and applications.

21

22 Chapter 4 - Design

cally Jenkins, is one of the requirements. CI configurations are always specific to a source

code set. As such they are part of the scaffolds. CI configurations are covered in Section

4.1.2.

Meta data Some meta data about scaffolds is required. Particularly each scaffold has a name,

description and a definition of required configuration parameters.

The relationship between the various parts and the domain model shown in Figure 1.1, is

illustrated in Figure 6.1 (Appendix A.1). This section concludes with Section 4.1.3.

4.1.1 Source Code

A few applications exist which implement a mechanism for the generation of source code using

some kind of template. Among the prominent ones is Apache Maven (Maven). Maven has a

concept called archetypes, which can bundle application generic Maven projects for later usage.

This mechanism is effective, but has two strong disadvantages.

Maven archetypes can only bundle Maven projects and projects must follow strict conven-

tions. For instance, a Maven project object model (POM) must be located in the source code

root directory.2 These restrictions do not enable usage by the codecentric AG as it is highly

unlikely that all projects will depend on Maven nor that they will have a POM at their source

code root.

As a result the generation component (see component diagram in Figure 6.2 in Appendix

A.1) was designed. It takes a scaffold in form of a .zip file, extracts the sources and renders

additional information into these files using the Template View pattern [15]. The starting point

is still a scaffold with included sources as shown in Directory tree 4.1.

scaffold.zipsources/

entity/src/main/java/-to package-/entities/

User.javapom.xml

web-service/src/pom.xml

scaffold.groovy

Directory tree 4.1: Structure of a project scaffold. Only the sources/ directory and thescaffold.groovy file are required. The other files and directories merely serve as an example.

In addition to rendering variables and configuration parameters, the generation component

2A POM captures project meta data like name, version, dependencies and compilation steps.

4.1 - Scaffolds 23

can also generate directory structures. A common use case for Java projects are packages.3

Directory tree 4.1 contains the special marker directory -to package-/ which will be expanded

to whatever the user defines as the project’s package. For example, suppose a user defines the

package name com.example and executes the previous scaffold. Then the file User.java will

be located at src/main/java/com/example/entities/User.java.

4.1.2 Continuous Integration Job Configuration

Janus has to be flexible enough to support a wide variety of applications, yet remain easy to

use. The main challenge is the ability to cope with evolution and change. An application like

Janus could lose its value suddenly when an organisation’s toolchain changes.

For example: a naive approach might be to put Jenkins configuration files in a scaffold.

This results in problems once Jenkins is replaced with a different tool or certain teams have a

different preference. In such cases, all scaffolds would need to be updated with configuration

files for the new CI system. Secondly, all scaffolds would need to be updated when the format

of Jenkins configuration files changes.

Janus avoids these issues through an intermediate application generic format. This format,

i.e., actually an object model, can then be used by components destined for the generation of

specific configuration files (see Figure 6.3 in Appendix A.1). This results in a single point of

maintenance as defined by the Institute for Software Quality [25].

The object model is populated by a domain-specific language (DSL). XML and JSON were

rejected as host languages due to the need to maintain configurations manually. Either is

designed for generic machine-to-machine communication and is therefore verbose and lacks

expressiveness. In the context of a DSL, the model is referred to as a semantic model.

In the context of a DSL, a semantic model is a representation, such as an in-memory object

model, of the same subject that the DSL describes. If my DSL describes a state machine,

then my Semantic Model might be an object model with classes for state, event, etc.

. . .

The semantic model is thus the library or framework that the DSL populates.

Martin Fowler [16]

Janus’ core is developed in Groovy. Groovy has various features which enable the develop-

ment of expressive DSLs. For the Janus project an internal DSL was chosen over an external

one in order to save precious time, reduce complexity and improve maintainability.4 Among

3Java packages are similar to other programming languages’ notions of namespaces. Packages are means tologically group classes, interfaces and other artefacts.

4It is likely that the majority of future maintainers is not experienced in the area of scanners and parsers.Internal DSLs leverage programming languages as their hosts and thus do not require custom scanners andparsers.


the useful features are optional operators, closures5, method chaining6 and dynamic reception7.

Through these features, the DSL shown in Listing 4.1 was realised. Section 5.2 elaborates on

implementation details.

Listing 4.1: DSL example for a scaffold configuration file.

name ’RESTful web application ’

description ’JAX -RS web service using RESTeasy ’

buildJob {

name ’deploy ’

no vcs trigger

tasks {

shell ’cp -rf ./ target /srv/www ’

}

}

buildJob {

name ’main ’

trigger ’deploy ’ on success

tasks {

maven targets: ’clean install ’, jvmOptions: ’-ea’

}

}

The sample configuration starts with some meta data. Both, name and description, are

instructions which take strings as parameters. Since the DSL is an internal one, all strings need

to be quoted.

Following the meta data, the first build job titled deploy is defined. The buildJob in-

struction accepts closures as parameters through which build jobs are configured. The no

vcs trigger instruction tells Janus not to add VCS polling configurations to the build job

configuration. This is commonly required when implementing continuous delivery or creating

deployment pipelines [21]. Indicated by the curly braces, the tasks instruction also accepts a

closure. This closure contains one or more build job instructions. In case of the deploy build

job, the command cp -rf ./target /srv/www is executed in a user’s shell. Most CI systems

make a differentiation between Microsoft Windows and Unix systems. For this reason Janus

also supports a batch command instruction, e.g., batch ’del c:\example.txt’.

The second build job, i.e., main, does not have the no vcs trigger instruction. Once a

5A closure is behaviour, e.g., a function, with a referenced scope, i.e., non-local variables. In contrast, pureobject-orientation focuses on the opposite: data which has behaviour, i.e., methods.

6Method chaining is a technique to improve readability and reduce the amount of source code. By return-ing the same object on which a method was invoked, invocations can be chained, e.g., Person tom = newPerson().setName("Tom").setEmail("[email protected]").setActive(true);.

7Dynamic reception is a term coined by Martin Fowler which describes the process of handling unknownmethod invocations, i.e., the method does not actually exist [16].

4.2 - Architecture 25

project is bootstrapped with this scaffold, the respective build job will periodically poll the

repository for changes. Once changes are recognised, the build job will be executed. This build

job further defines a task maven. This translates to an execution of Apache Maven, i.e., a build

automation tool like Make. As for the last instruction trigger ’deploy’ on success, this can

also be used for deployment or build pipelines. It indicates that the build job deploy shall be

executed once the build job main successfully finishes.

4.1.3 Conclusions

Through scaffolds two issues are tackled: project bootstrap time is reduced and knowledge is

maintained in a central, accessible and executable manner. Scaffolds are especially valuable for

companies which have a common internal technology stack. Instead of documenting architecture

and design, a scaffold can be created once which realises the architecture thus making it testable

and executable, a concept which is referred to as executable architecture. It is advisable to store

scaffolds in a VCS. By doing so, architects and otherwise experienced personnel can update

and maintain scaffolds.

To improve usability, tooling needs to be available. Such tools can automate various tasks

like creation of scaffolds from an existing project, generating scaffold configuration files from

CI server configurations and scaffold catalogue maintenance.

4.2 Architecture

Janus was developed as a Java virtual machine (JVM) based application. Instead of focusing

on just the Java programming language, a JVM focus enables the usage of different technologies

and languages. Besides this, the general properties of the JVM like portability are important.

The most important factor though is that the codecentric AG is knowledgeable in the area of

JVM based applications and can therefore maintain and operate Janus.

Groovy was chosen as the programming language for the core of Janus, i.e., all reusable

parts which are not UI related. The core is mostly concerned with I/O, in particular the

extraction of files, template processing engine, parsing of the DSL and web service consumption.

As a dynamically-typed language with closure support, the aforementioned use cases can be

realised in Groovy with a better signal-to-noise ratio, especially when compared to the Java

programming language. This not only improves developer efficiency but will be valuable during

software evolution as the code is more concise and easier to comprehend.

Scala and JRuby were also evaluated as a programming language for the core of Janus.

Either language lends itself to I/O intensive tasks, but unfortunately both lack an important

property. For compatibility reasons, Janus’ core needs to be usable from other JVM languages,

especially Java. While Groovy applications are fully Java bytecode compatible, certain Scala

and JRuby language constructs preclude this.


It was already mentioned that Janus is divided into two components, the core and user

interface (see Figure 6.2 in Appendix A.1). The core is a set of components which do not

implement a complete workflow. Instead, every component provides actions to configure certain

aspects of a system, e.g., authorise users or generates sources. How the components are used to

fulfil codecentric AG’s requirements can be seen in the activity diagram in Figure 6.4 (Appendix

A.1).

The second major component is the UI. First ideas resolved around a command line UI, but

the lack of centralised availability resulted in a rejection of this idea. Throughout the codecentric

AG, the CI server Jenkins is part of the standard technology stack. Since the employees already

have access to the Jenkins instances, it was decided to extend Jenkins through a plug-in which

provides a GUI to the Janus application. By doing so, the employees do not need to maintain

an additional set of authentication credentials and the operation of Janus is simplified as only

a plug-in needs to be installed and configured. Following the Jenkins plug-in naming scheme,

the GUI component is named janus-plugin. Jenkins plug-ins need to be written in Java. Due

to this, the Janus project requires polyglot programming as defined by Neal Ford [32].

More information about the architecture is available in the appendix. The relationships

between the architecture decisions are illustrated in Figure 6.6 (Appendix A.1). Trade-offs and

decision ratings can be seen in Table 6.3 (Appendix A.1) and architecture decision descriptions

are available through Appendix A.3. At last, the deployment diagram in Figure 6.7 (Appendix

A.1) shows how the components are deployed.

4.3 Conclusions

Many design decisions were made to incorporate the non-functional requirements. Wide tool

support and the ability to cope with changing tool chains is achieved through scriptability,

e.g., VCS configuration and repository creation with Jenkins build jobs, and by decoupling

scaffolds from specific CASE tools. The latter is done through a generic representation of CI

configurations in form a DSL.

Janus is a JVM based application and was designed with reuse in mind. In addition to

codecentric AG’s requirements, possible requirements of the Eclipse Skalli project were taken

into account. This was done so that Janus’ core can be reused in various applications. In

an optimal case, Janus’ core will be included in Eclipse Skalli (as a dependency). This would

further improve chances of open source contributions and adoption.

Chapter 5

Realisation

The process of designing and realising was not separated, but interweaved. Prototypes were

developed during the analysis phase and either thrown away or, when they were of high quality,

evolved to match the requirements. For instance, the previous approach to scaffold configuration

files was discarded during the analysis phase.1 First prototypes for web service consumption

on the other hand, specifically Jenkins REST web service usage, were reused and are now part

of Janus’ core.

This chapter starts with a reference to the version control systems which hold Janus’ source

code in Section 5.1. The remainder of this chapter covers some of the interesting and challenging

realisation topics. Specifically, the development of an internal domain-specific language in

Section 5.2, how JIRA and Confluence web services are consumed and combined in order to

create an indirection layer (Section 5.3) and how automatic test suites are leveraged for Janus

(Section 5.4). Section 5.5 concludes this chapter.

5.1 Source Code

Source code and documents are maintained in publicly accessible Git repositories on GitHub.

The project is structured into two repositories:

janus This is the core of the project. It contains the application’s logic for project bootstrap-

ping, e.g., parsing of configuration files and execution of project scaffold. The source code

is available through:

https://github.com/bripkens/janus

janus-plugin The janus-plugin repository is not a plug-in for Janus, but instead a plug-in

for the Jenkins CI server. As Section 4.2 describes, Jenkins is used as a graphical user

interface (GUI) for Janus. The source code is available through:

1A first version made use of JSON as a host language. This proved to be too verbose and complicated tomaintain.

27

https://github.com/bripkens/janus

28 Chapter 5 - Realisation

https://github.com/bripkens/janus-plugin

5.2 Domain-Specific Language

For the implementation of the DSL, the programming language Groovy is used. Groovy has a

few language features which lend themselves to the development of internal DSLs. An internal

DSL, in contrast to an external, is using a programming language as its host language whereas

an external DSL requires a custom scanner and parser [16]. Janus on the other hand utilises

a common approach to Groovy DSLs which resolves around the usage of closures, optional

characters and dynamic reception. By doing this, a well-readable DSL can be created, which,

while still containing a few programming language specific symbols, is easier to maintain as no

specific knowledge is required. Although an internal DSL is executed, this section refers to the

component which executes the DSL as a parser.

Optional symbols and characters are to a large degree responsible for the DSL’s readability.

At the same time this improvement is also the easiest to apply. Since it is a Groovy language

feature, nothing needs to be implemented. Which characters are actually omitted can be seen

in Listing 5.1.

Listing 5.1: DSL example highlighting optional characters in Groovy.

// internal Groovy DSL without optional characters

name ’My Scaffold ’

buildJob {

trigger ’deploy ’ on success

}

// is synonymous to this version with optional characters included

name(’My Scaffold ’);

buildJob ({

trigger(’deploy ’).on(this.success);

});

The previous listing also makes use of closures, as indicated by the curly brackets. Closures

are used to organise instructions into blocks. For instance, all instructions which are part of

the buildJob closure will contain information regarding one build job. One thing to note is

that the closure is merely defined, but not executed. Janus’ DSL parser will run the closures

manually and also modify their scope. By doing this, functions and properties can be added

to the closure’s scope. Going back to the previous example: the property success and the

method trigger are added to the buildJob closure by Janus. If this was not done, a runtime

error would occur because neither trigger nor success are defined.

The last language feature is dynamic reception. Dynamic reception is coined by Martin

Fowler and describes the process of catching calls to functions which are not defined [16]. Such

https://github.com/bripkens/janus-plugin

5.3 - Web Service Consumption 29

a function is commonly called methodMissing or similar and is invoked every time the runtime

environment cannot locate a certain function in the current scope. Janus’ DSL makes use of

this for build job tasks as Listing 5.2 shows.

Listing 5.2: Part of Janus’ DSL which is making use of dynamic reception.

buildJob {

tasks {

maven targets: ’clean install ’

shell ’rm -rf /tmp ’

batch ’del c:\windows ’

}

}

Every build job task, e.g., maven, shell and batch, will result in a call of the methodMissing

function. While functions could be added to handle the limited amount of different tasks, this

would become tedious once more tasks are added. Instead, the methodMissing function is able

to identify valid task names and their argument types. Argument types can differ. The example

shows two possible argument types, namely multiple arguments in form of a map (the maven

task) and a single argument (shell and batch task). With this system in place, adding a new

build job task can be done by registering a new task with name and argument type with no need

for changes of the DSL parser. At last, each build job task can have default arguments. This

can come in handy with tasks like maven and ant which are commonly configured in naming

convention compliant ways (configuration by exception).

5.3 Web Service Consumption

Janus needs to configure JIRA and Confluence instances. Looking closer, it needs to add

configurations for new projects, create users and user groups and authorise project leaders,

developers and stakeholders. Either application exposes two web services through which the

application can be configured. The first and most feature-complete one is based on the simple

object access protocol (SOAP), a remote procedure call mechanism for object-oriented systems.

The second web service is a stateless web service which implements the representational state

transfer paradigm (REST) as described by Roy Fielding in [14].

Both web services need to be used in combination in order to fulfil the requirements as

neither is feature complete. While Janus’ core provides access to the web services, it hides

which one is used and opaquely switches between SOAP and REST in order to decouple the

components’ users from eventual JIRA and Confluence API changes. How this is done is

illustrated in Figure 6.8 (Appendix A.1). The jira component goes even further by unifying

either web services’ response types thus simplifying the component’s usage. The result is a

clean API as Listing 5.3 shows.


Listing 5.3: Example jira component usage.

def url = ’http :// jira.example.com ’,

username = ’admin ’,

password = ’12345’

def session = new JiraSession(url , username , password)

def client = new JiraClient(session)

client.searchUser(’Tom ’).each { println it.fullname }

client.getGroup(’jira -administrators ’).users.each { println it.fullname }

session.close()

The listing shows in the first lines how a session is established and a client is created.

Since SOAP is stateful, a session is necessary in order to maintain the connection and store

the authentication token. The first web service call is done when the searchUser method is

called. While not visible to the components’ users, this will actually result in a call to JIRA’s

REST API [3]. Once the result is retrieved, the example writes the full names of every matched

user to standard out. In the following line the getGroup method will internally use the SOAP

web service. It retrieves information about the group which is identified by the parameter

and returns it [4]. Similar to the previous line, all group members’ full names are printed to

standard out. The last line logs out the user and closes the connection. It is notable that both

calls, i.e., searchUser and getGroup, return the same data structures, even though the REST

web service returns completely different ones compared to the SOAP web service.

The preliminary research has shown that the Eclipse Skalli project seems to be struggling

with JIRA and Confluence configuration, the project’s developers were therefore informed about

the findings and the jira component [5].

5.4 Testing

Among all the non-functional requirements, robustness and fault tolerance are very important.

Therefore, a test-driven development (TDD) approach was followed for Janus’ core. This covers

unit testing using JUnit, but is ignoring the interactions between the various components.

Exactly for this purpose, integration tests are used (see Section 5.4.2).

Acceptance tests can be derived from user stories using a behaviour-driven approach. Through

this and JBehave, a decoupled set of steps can be defined which further improves maintainabil-

ity and builds the integration tests using a top-down approach. Behaviour-driven development

is covered in Section 5.4.1. The testing section concludes with Section 5.4.3.

5.4 - Testing 31

5.4.1 Behaviour-Driven Development

Behaviour-Driven Development (BDD) originated in Dan North’s need to teach Test-Driven

Development (TDD) in the context of agile practices. Encouraged by problems with TDD he

developed the practice and best practice of what is now BDD and an application called JBehave.

By utilising a common form of user stories and acceptance criteria, he defined a framework for

”a ubiquitous language for analysis” [10].

This framework is leveraged for this project in order to create executable acceptance criteria.

Because of the clear structure, they can either be developed by or with stakeholders. The result

is a set of scenarios which can be executed with the help of JBehave. The scenario in Listing

5.4 shows a complex acceptance criteria for the project bootstrap story. It contains information

about input and output but is not concerned with the actual implementation of these tests.

Listing 5.4: An extensive behaviour-driven test for the project bootstrap scenario.

Scenario: Project bootstrap

Given a clean Jenkins installation

And a build creationBuild

...

And the Janus generation is configured

When a project Worblehat with package com.example.worblehat and VCS Training

is bootstrapped

Then the bootstrap success message is shown

And no failure log message is shown

...

And the build Worblehat -build is created

And the build Worblehat -deploy -staging is created

As Listing 5.4 reveals, scenarios are structured in the three steps given, when and then.

The first step (given) is concerned with test setup and configuration. In the shown scenario,

it configures Janus by adding build jobs and defining mandatory VCS and CI options. The

when step is the activity or story which should be tested. The previous example tests the

bootstrap project story. At last, the then step verifies the outcome. Each step, e.g., Then the

bootstrap success message is shown, refers to a method which implements the actual activity

or verification. In case of the aforementioned step, the method verifies that the generated HTML

contains a success message and that this message is visible.

5.4.2 Simulating User Interaction

BDD and JBehave do not provide any means to test user interactions or to implement any kind

of integration tests. JBehave itself is only a test runner, similar to other tools of the xUnit


family. Nevertheless, robustness is an important non-functional requirement which needs to be

addressed. Misconfiguration and data loss are not tolerable.

Integration tests provide means to test the application and its interface in a production

like environment. In case of the Janus project, integration tests are simulating user interaction

in a browser through Selenium WebDriver. This way the complete application stack can be

tested from the users’ browsers to source code and build job generation. To do this Janus is

deployed in a Jenkins instance, the configuration is reset and then the test is executed. Figure

5.1 illustrates the process.

Start Jenkins

Delete Jenkins workspace

Copy default workspace

Restart Jenkins

Execute test

test successful?

has more tests?

[true]

[false]

[true]

[false]

Figure 5.1: Integration test strategy illustrated using a UML activity diagram.

Remaining tests will not be executed when an error occurs. This was done because the

tests take relatively long due to the necessary server restarts. These restarts are required to

put Jenkins in a predefined and stable state.

Especially challenging were the security configuration and plug-in installation. Doing this

in every test run through the WebDriver and therefore using the web interface would be very

time consuming. The Janus integration tests avoid this via a default workspace which is the

starting point for all tests. It includes a test user account and a variety of installed plug-ins

5.5 - Conclusions 33

which need to be installed.2 By doing this, the test execution time was significantly reduced

from two restarts per test to a single restart. With a restart taking something between 40 and

60 seconds, the overall test execution time was reduced by roughly 30%.

Selenium connects to a supported browser, e.g., Microsoft Internet Explorer, Mozilla Firefox,

Google Chrome or Opera, and establishes a link which is similar to RPCs [8]. Through this link,

events can be raised in the target browser. For instance, text can be inserted into input fields,

buttons can be clicked and the generated HTML can be queried. Selenium simplifies integration

tests but, unfortunately, all this increases complexity. The number of involved applications, i.e.,

browsers, Jenkins, JIRA and Confluence, complicate reproducibility and reduce performance.

This is especially visible when seeing the deployment diagram (Figure 6.7 in Appendix A.1).

To alleviate this problem, some integration tests were converted to service tests. These tests

resemble an intermediate level between unit and integration tests. The JIRA and Jenkins

components make use of service tests. Both components tests require a running Jenkins, JIRA

or Confluence instance, but are not prone to Selenium issues or issues which are related to

other components.3 To put it simply, a component is tested in absence of a GUI. The concept

of unit, service and integration tests is commonly visualised in form of a test pyramid [29].

5.4.3 Conclusions

This section showed how behaviour-driven integration tests are used for the development of

Janus. Tests can be developed in cooperation with the stakeholders through JBehave and

Selenium WebDriver. By simulating actual user behaviour and utilising black-box testing, the

stakeholders can define executable acceptance criteria which can be used to verify that user

stories are completed.

Integration testing a Jenkins plug-in was challenging as it has no built-in support for reset-

ting workspaces and configurations. This resulted in some workarounds, i.e., deleting workspace

and restarting the server, that increased the overall test execution time. The result is a long

feedback loop which does not encourage integration test execution. Unfortunately, there is no

possibility to avoid server restarts completely, but at least the number of restarts was reduced.

5.5 Conclusions

Janus is a complex system due to the variety of involved CASE tools. With the DSL, different

web services and three remote systems which need to be configured, Janus presents distinct

challenges.

In order to integration test Janus, a Jenkins, JIRA and Confluence instance needs to be

2Janus generates configurations for the Mercurial VCS. As of the time of writing, Jenkins has no Mercurialsupport in its standard distribution package.

3This is true for components which are not on the classpath during test execution.


running and configured in a specific way. Needless to say that duplicating workstations with all

the applications is not an easy task - especially since the installation of JIRA and Confluence

requires license keys. While a virtual machine with JIRA and Confluence installed can be

created, a disc image cannot be shared among developers due to licensing issues. Albeit, this

issue can be alleviated with organisation internal developer keys, such keys cannot be shared

with fellow open source contributors.

Overall, accidental complexity was avoided. The fact that various CASE tools need to

be running is owned by the functional requirements. Implementation of the DSL was kept

simple by explicitly avoiding advanced concepts like scanners and parsers. For developers,

the web service component’s API was kept simple by masking different types of web services,

incompatible responses and removing ambiguous exceptions.

Chapter 6

Conclusions and Future Work

Acceleration of project starts can be achieved in various ways. The approach presented in this

thesis resolves around the automatic configuration of server-side applications like JIRA, Jenkins

and others through a newly developed application called Janus. As a web application and

specifically a Jenkins plug-in, Janus can be installed on a central server and, for organisations

which already use Jenkins, users can get started right away without requesting a new set of

authentication credentials.

Besides acceleration, the automatic configuration and the centrally available service result

in benefits and possibilities. Through automation, the chances of accidental misconfiguration

of server-side applications is reduced. Instead of having a project start delay of a single day,

misconfiguration of VCSs or PMSs can have serious effects, ranging from degraded productivity

to data loss. Both may exceed the costs of project start delays by a wide margin. For this

reason a reduction of misconfiguration probability is desirable.

Janus also creates possibilities. Unlike manually configured SDEs, automatically configured

ones can be used for other purposes. For instance, since the configuration does no longer require

system administrators and the like, SDEs can be created for prototypes, ideas, pet projects

and training purposes. With manual configuration, since such projects might not result in a

monetary value, the incentive for system administrators to setup SDEs is significantly lower.

The second possibility is scaffolds, i.e., templates on a project level which consist of source

code, directory structures, configuration files, examples and CI configurations. By capturing

software architecture in form of scaffolds, project foundations can be generated through Janus.

These foundations can contain architecture rationale and even tacit knowledge, which would

otherwise need to be looked up in documentation or discussed with architects or experienced

personnel. On top of this, since scaffolds can be executed, it is easier for inexperienced or new

employees to get started with company-internal technology stacks. Scaffolds are zip files which

contain source code and can therefore be revision controlled, compiled, tested and be subject

to continuous integration.

Janus is FOSS, licensed under the Apache License 2.0. It can therefore be used, extended

35

36 Chapter 6 - Conclusions and Future Work

and improved by other organisations. During design and development, Janus’ ability to cope

with changes and changed tool stacks was one of the driving forces. The application is divided

into two parts. The core contains organisation independent logic, like web service consumption

and source code generation. Codecentric AG specific domain-logic is only located in the GUI

component. Since this is the case, organisations can make use of Janus’ core without further

changes and integrate it with their own application stacks. In the future, the GUI compo-

nent can be modified so that codecentric AG specific logic will become configurable bootstrap

options.

In general, Janus can be extended in various ways. A discussion with build managers of

Oce Technologies B.V. has shown that Janus is not only useful for companies which do project

work, but also for companies which develop products or are located in different domains, e.g.,

embedded software. For such companies, project start delays are neglectable as development

extends over a longer period of time. Automatic configuration of CI systems is especially

appealing to them as they are regularly coping with misconfiguration. Oce Technologies B.V.

is further interested in the automatic installation of workstations, e.g., installation of compilers

and IDEs. This is necessary for new employees or in maintenance use cases. The following

extension points represent possible next steps in Janus’ evolution.

Automatic installation of workstations As mentioned in the previous paragraph, work-

stations can be automatically installed. This topic is currently discussed as a possible

bachelor thesis project for the winter semester of 2012.

Browsing through bootstrapped projects To ease project lookups, especially in mainte-

nance cases, it would be worthwhile to have one central system which lists all projects.

For each project, information about the used CASE tools and the workstation configura-

tion can be maintained. Eclipse Skalli implements a similar use case and might therefore

be leveraged.

Support for additional CASE tools Section 3.2 presented various CASE tools of which

one was chosen for each application type. Naturally, Janus can be extended with support

for additional applications. For instance, Git and Redmine support are likely to increase

Janus’ value for open source software projects.

Appendices

A.1 Additional Figures and Tables

Project

SourceCode

ContinuousIntegrationJob

Scaffold

SourceCodeTe

mplate

ContinuousIntegrationJobTe

mplate

1..

*

*

*

1

*

1

1

*

1..

*

1

1

1

*

1

*

1

is v

alid

ati

on

str

ate

gy f

or

ab

stra

ct r

ep

rese

nta

tion o

f

has

pro

vid

es

init

ial st

ruct

ure

for

has

valid

ate

s

has

has

Figure 6.1: An extension of the domain model shown in Figure 1.1. This domain modelillustrates the concepts of a scaffold.

37

38 Appendices

<<component>>janus

<<component>>janus-plugin <<component>>

core<<component>>

generation

<<component>>continuousIntegration

<<component>>projectManagement

<<component>>jenkins

<<component>>jira

Figure 6.2: UML component diagram which shows the component relationships and dependen-cies. The janus component is described as the core of Janus throughout this thesis to create adifferentiation to the UI component. The UI component is called janus-plugin in this diagram.

ScaffoldRequiredContext

BuildJobTask

Trigger

*

1

1..*

1

*

1

*

1

1..*

*triggers

has

consists of

has

defines

Figure 6.3: Semantic model for the scaffold DSL.

Appendices 39

IdD

es

cri

pti

on

Sta

ke

ho

lde

rP

rio

rity

Sp

rin

tD

on

e?

No

tes

19

20

1✓

79

50

1✓

57

20

2✓

97

50

2✓

Sim

ilar

to M

ave

n A

rch

ety

pe

s.

25

30

3✓

10

57

03

✓

33

30

4✓

11

38

04

✓1

31

30

Wra

p u

p

61

40

Wra

p u

p

14

12

0W

rap

up

15

1W

rap

up

Th

ink

ab

ou

t ra

dia

tor

an

d p

ipe

line

vie

w

80

12

0E

PIC

16

0E

PIC

Es

tim

ate

s (s

tory

-po

ints

)A

sys

tem

ad

min

istr

ato

r ca

n ad

d a

Me

rcu

rial c

on

figu

ratio

n s

o

tha

t th

e c

on

figu

ratio

n ca

n la

ter

be

use

d b

y co

nfig

ura

tion

m

ana

ge

rs t

o a

dd n

ew

re

posi

torie

s.

An

drea

s E

bb

ert

-Kar

rou

mS

yste

m a

dmin

istr

ato

rs

A c

on

figur

atio

n m

ana

ge

r ca

n cr

ea

te a

Me

rcu

rial r

ep

osi

tory

fo

r a

pro

ject

.A

ndr

eas

Eb

be

rt-K

arro

um

Co

nfig

ura

tion

Man

ag

ers

A c

on

figur

atio

n m

ana

ge

r ca

n lo

ok

thro

ugh

a c

ata

log

of

tem

pla

tes

to fi

nd

an

ap

pro

pria

te o

ne

for

his

typ

e o

f pr

oje

ct.

An

drea

s E

bb

ert

-Kar

rou

mC

onf

igu

ratio

n M

ana

ger

s

A c

on

figur

atio

n m

ana

ge

r ca

n g

ene

rate

pro

ject

so

urc

es

fro

m

a t

em

pla

te s

o th

at

pro

ject

boo

tstr

ap t

ime

is r

edu

ced

.A

ndr

eas

Eb

be

rt-K

arro

um

Co

nfig

ura

tion

Man

ag

ers

A s

yste

m a

dm

inis

tra

tor

can

add

a J

enk

ins

con

figu

ratio

n s

o th

at

the

co

nfig

ura

tion

can

late

r b

e u

sed

by

con

figu

ratio

n

man

ag

ers

to

add

ne

w b

uild

job

s.

An

drea

s E

bb

ert

-Kar

rou

mS

yste

m a

dmin

istr

ato

rs

A c

on

figur

atio

n m

ana

ge

r ca

n a

dd J

en

kin

s b

uild

job

s ba

sed

o

n a

pro

ject

's t

em

pla

te s

o t

hat

an

ap

pro

pria

te c

on

tinu

ou

s in

teg

ratio

n e

nviro

nm

en

t is

pro

vid

ed

.

An

drea

s E

bb

ert

-Kar

rou

mC

onf

igu

ratio

n M

ana

ger

Allo

w m

ultip

le jo

bs

pe

r p

roje

ct.

Fo

r n

ow

on

ly m

ake

use

of J

en

kins

.

A s

yste

m a

dm

inis

tra

tor

can

add

a J

IRA

co

nfig

ura

tion

so

tha

t th

e c

onfig

ura

tion

ca

n la

ter

be

use

d b

y co

nfig

ura

tion

m

ana

ge

rs t

o c

on

figu

re n

ew p

roje

ct w

ork

spa

ces.

An

drea

s E

bb

ert

-Kar

rou

mS

yste

m a

dmin

istr

ato

rs

A c

on

figur

atio

n m

ana

ge

r ca

n cr

ea

te

a n

ew

JIR

A /

C

onf

lue

nce

/ G

ree

nh

opp

er

wo

rksp

ace

fo

r a

giv

en

pro

ject

.A

ndr

eas

Eb

be

rt-K

arro

um

Co

nfig

ura

tion

Man

ag

ers

A u

ser

can

cre

ate

a p

roje

ct t

em

pla

te f

rom

an

exi

stin

g p

roje

ct.

An

drea

s E

bb

ert

-Kar

rou

m

A s

yste

m a

dm

inis

tra

tor

can

add

an

d r

em

ove

tem

pla

tes

fro

m

the

cat

alo

g.

An

drea

s E

bb

ert

-Kar

rou

mS

yste

m a

dmin

istr

ato

rsA

use

r ca

n c

rea

te a

te

mp

late

cat

alo

g f

rom

a d

irect

ory

wh

ich

con

tain

s p

roje

ct te

mpl

ate

s.A

ndr

eas

Eb

be

rt-K

arro

um

A c

on

figur

atio

n m

ana

ge

r ca

n, w

hen

cre

atin

g a

new

pro

ject

, d

irect

ly c

rea

te n

ew v

iew

s in

Jen

kin

s.A

ndr

eas

Eb

be

rt-K

arro

um

A c

on

figur

atio

n m

ana

ge

r ca

n cr

ea

te a

Git

repo

sito

ry f

or

a p

roje

ct.

An

drea

s E

bb

ert

-Kar

rou

mC

onf

igu

ratio

n M

ana

ger

sA

com

bin

atio

n w

ith G

itHub

se

ems

to b

e in

tere

stin

g f

or

the

co

mp

an

y.A

use

r ca

n lo

ok

thro

ug

h a

list

ing

of a

ll cr

ea

ted

pro

ject

s a

nd

lo

ok u

p w

ha

t sy

ste

ms

the

y a

re u

sin

g a

nd,

in g

ene

ral,

how

to

ge

t st

art

ed w

ith t

he

pro

ject

.

De

velo

per

s/cu

sto

mer

s (e

nd

-u

sers

)

A u

ser

can

bo

ots

tra

p cl

ien

t-si

de

so

ftw

are

de

velo

pme

nt

env

iron

me

nts

Oce

Table 6.1: Product backlog.

40 Appendices

IDCate

gory

Descrip

tion

1P

orta

bility

Th

e a

pp

licatio

n n

ee

ds to

be

wo

rking

un

de

r Un

ix (serve

r) an

d W

ind

ow

(de

sktop

) en

viron

me

nts.

2P

orta

bility

Th

e a

pp

licatio

n sh

ou

ld n

ot d

ep

en

d o

n o

pe

ratin

g syste

m sp

ecific fu

nctio

na

lity.3

Inte

rop

era

bility, E

xten

sibility

4R

ob

ustn

ess

5O

pe

n so

urce

Th

e a

pp

licatio

n n

ee

ds to

be

com

pa

tible

with

Ap

ach

e L

icen

se ve

rsion

2.

6P

riceN

o b

ud

ge

t is ava

ilab

le.

7S

ecu

rity

8S

ecu

rity

9U

sab

ility, rep

ortin

g

10

Inte

rop

era

bility

Th

e g

en

era

tion

of p

roje

ct sou

rces sh

ou

ld n

ot b

e b

ou

nd

to a

spe

cific dire

ctory stru

cture

no

r too

l.1

1S

ecu

rityO

nly a

uth

orize

d u

sers m

ay cre

ate

a n

ew

pro

ject o

r use

an

y oth

er p

art o

f the

fun

ction

ality.

Th

e app

licatio

n sh

ou

ld p

rovide

me

an

s for a

dd

ition

of co

mp

one

nts w

hich

sup

port n

ew

or d

iffere

nt

too

ls, e.g., G

it or B

uildbo

t. Re

packa

gin

g th

e app

licatio

n is a

ccep

tab

le in

such

case

s.T

ool co

nfig

ura

tion sh

ould

ne

ver result in a

n in

consiste

nt o

r broke

n a

pp

licatio

n sta

te (w

here

ap

plication

state

refers to

the

state

of th

e co

nfig

ured to

ol, for in

stan

ce, the

contin

uo

us inte

gration

syste

m.

Wh

en

po

ssible, the

config

ura

tion

sho

uld a

lwa

ys be

do

ne

ove

r secu

re cha

nn

els or thro

ugh

e

ncryp

ted

messa

ge

s.T

ool co

nfig

ura

tions, e

.g., A

PI ke

ys or use

r nam

e / passw

ord

com

bin

atio

ns, sh

ould

ne

ver be

p

ublishe

d to

en

d u

sers of th

e system

.T

he a

pplica

tion

ne

eds to

ha

ve a

con

figu

rab

le ve

rbosity le

vel a

nd sho

uld p

rovid

e in

form

ation

abo

ut

all actio

ns to

the

ap

plica

tions' u

sers.

Table 6.2: Non-functional requirements.

Appendices 41

Use

rVers

ion

con

trol sy

stem

com

pon

en

tg

en

era

tion

com

pon

ent

jenki

ns

com

pon

en

tja

nu

s-p

lug

in c

om

pon

ent

Pro

ject

con

fig

ura

tion

JIR

A c

om

pon

en

t

Sele

ct v

ers

ion

con

trol sy

stem

Sele

ct p

roje

ct s

caff

old

Sele

ct c

on

tin

uou

s in

teg

rati

on

syst

em

Sele

ct JIR

A in

stan

ce

Cre

ate

rep

osi

tory

Make

tem

pora

ry c

heck

ou

t

Ru

n p

roje

ct s

caff

old

th

rou

gh

tem

pla

te e

ng

ine

Coord

inate

task

s

Com

mit

an

d p

ush

th

e c

han

ges

Wri

te fi

les

to t

em

pora

rych

eck

ou

t d

irect

ory

Coord

inate

task

s

Coord

inate

task

s

Cre

ate

bu

ild job

s

Cre

ate

& c

on

fig

ure

pro

ject

Dis

pla

y r

esu

lts

Figure 6.4: UML activity diagram illustrating the project bootstrap process.

42 Appendices

Appendices 43

User story Task Priority DescriptionWork left at day end (task-points)

Done?Working daysBefore sprint 19.03 20.03 21.03 22.03 23.03 26.03 27.03 28.03 29.03 30.03 2.04 3.04 4.04 5.04 6.04

8.00 8.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Meeting with Mr Jacobs (23.03 at 14:00) 5.00 5.00 5.00 5.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Competence file 0.00 0.00 0.00 3.00 6.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Preparation intermediate presentation 21.00 21.00 21.00 21.00 21.00 21.00 21.00 21.00 21.00 21.00 15.00 0.00 0.00 0.00 0.00 0.00Giving intermediate presentation (03.04 at 15:00) 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.005 1 7 Configuration Dialog => Where is the catalog located? 2.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.005 2 6 3.00 3.00 3.00 3.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.005 3 5 Browse through the catalog and show all available information. 5.00 5.00 5.00 5.00 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.005 4 8 Integration tests 13.00 13.00 12.00 12.00 12.00 12.00 9.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.009 1 3 Responding to form submission of task 5:4 5.00 5.00 5.00 5.00 5.00 3.00 3.00 3.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.009 2 1 Actual execution of project bootstrap into checkout directory 5.00 5.00 5.00 5.00 5.00 5.00 5.00 5.00 3.00 0.00 0.00 0.00 0.00 0.00 0.00 0.009 3 4 Integration tests 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 13.00 8.00 5.00 0.009 4 2 Checking out the repository locally 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 0.009 5 1 8.00 8.00 8.00 8.00 8.00 8.00 8.00 8.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.007 10 Bug: Creating repository when no valid configuration exists 5.00 5.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.009 Setting up an integration test environment 21.00 3.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.002.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 2.00 0.00 0.00 0.00

0 19.03 20.03 21.03 22.03 23.03 26.03 27.03 28.03 29.03 30.03 2.04 3.04 4.04 5.04 6.04Total task-points left 132.00 114.00 103.00 95.00 93.00 86.00 77.00 68.00 57.00 44.00 38.00 23.00 15.00 8.00 5.00 0.00

132.00 123.20 114.40 105.60 96.80 88.00 79.20 70.40 61.60 52.80 44.00 35.20 26.40 17.60 8.80 0.008.80 8.14 7.92 7.92 8.45 8.60 8.56 8.50 8.14 7.33 7.60 5.75 5.00 4.00 5.00 0.00

Velocity 0 18 11 8 2 7 9 9 11 13 6 15 8 7 3 5

Estimate (task-points)

Fontys Presentation and intermediate report hand-in (21.03)

New RootAction which “extends” the “create repository” action.

Commiting and pushing the changes

Changelog in readme files.

Ideal burndownRequired daily burndown

0 19.03 20.03 21.03 22.03 23.03 26.03 27.03 28.03 29.03 30.03 2.04 3.04 4.04 5.04 6.040.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

Sprint 2 Burndown

Total task-points left Ideal burndown

Required daily burndown Velocity

task

-po

ints

Before start Sprint 1 Sprint 2 Sprint 3 Sprint 40

50

100

150

200

250

300

350

400

450

500

Project Overview

story-points left accumulated value velocity

sto

ry-p

oin

ts

Figure 6.5: Sample sprint backlog (from sprint two) with burndown and project overview chart.

44 Appendices

Programming language

<<discarded>>Maven for build automation

<<approved>>Gradle for build

automation

<<approved>>Groovy HTTP Builder to communicate

with REST web services

<<approved>>Simple Logging Facade for Java for logging

Scaffolds

<<discarded>>Maven archetype for project bootstrap

<<approved>>Custom application for project bootstrap

<<discarded>>java.util.logging for logging

User interface

Testing

<<approved>>Maintain compatibility with Java

<<discarded>>Scala as prog. lang.

<<discarded>>JRuby as prog. lang.

<<approved>>Groovy as prog. lang

<<discarded>>Java as prog. lang

<<approved>>Groovy Simple Template Engine

for source code templates

<<idea>>Apache Velocity for source code templates

<<idea>>StringTemplate for source code templates

<<rejected>>JSON for configuration files

<<approved>>Groovy DSL for configuration files

<<rejected>>Jackson for JSON Object Mapping

<<discarded>>GSON for JSON object mapping

<<approved>>Template view Pattern

<<approved>>Continuous integration system

agnostic configuration files

<<approved>>Builder Pattern

<<discarded>>Desktop application based interface

<<approved>>Web based interface

<<discarded>>Command-line interface

<<discarded>>Custom web application

<<approved>>Jenkins plug-in

<<discarded>>Extend Skalli

<<approved>>JVM based prog. lang.

<<approved>>JBehave as test runner

<<discarded>>Robot Framework

as test runner

<<approved>>Selenium WebDriverfor integration tests

<<discarded>>External DSL

<<discarded>>XML for configuration files

<<rejected>>Store Jenkins configuration files in

the scaffold

<<excluded by>>

<<alternative for>>

<<caused by>>

<<alternative for>>

<<depends on>>

<<caused by>>

<<depends on>> <<alternative for>>

<<depends on>>

<<alternative for>>

<<caused by>>

<<alternative for>>

<<replaces>>

<<caused by>>

<<depends on>>

<<alternative for>>

<<depends on>>

<<depends on>>

<<alternative for>>

<<depends on>>

<<alternative for>>

<<depends on>>

<<depends on>>

<<alternative for>>

<<alternative for>>

<<excluded by>>

<<depends on>>

Figure 6.6: Architecture decisions and relationships visualised using the notation outlined in [38].

Appendices 45

A A A DI DI DI A DI DI A A A DI A A R R DI A A ID ID A DI DI A DI DI A R DI A A

Architecturally Significant RequirementsNFR 2) Operating system agnostic ++ + NFR 2) Operating system agnostic

+ - ++ + + + - NFR 3) Addition of support for other tools, e.g., CINFR 4) No inconsistencies + NFR 4) No inconsistenciesNFR 5) Apache License 2 compatibility o o NFR 5) Apache License 2 compatibilityNFR 9) Provide information to user (logging)... ++ + NFR 9) Provide information to user (logging)...NFR 10) Generation not bound to any tool / structure X NFR 10) Generation not bound to any tool / structure US 9) Generate project source from template... + ++ US 9) Generate project source from template...

US 10) Generate build jobs... + + + ++ US 10) Generate build jobs...

US 1,2,3,6) Centralized administration + - - US 1,2,3,6) Centralized administration

US 12) Look through a list of all projects ++ US 12) Look through a list of all projects

ForcesDeveloper interested in new JVM based languages + + + + + Developer interested in new JVM based languages

+ Developer interested in Gradle++ + + + Skalli compatibility+ + + + + + + Codecentric employees' technology familiarity

+ - - Codecentric employees already have Jenkins accountsX X if (java compatible)

Generic quality attributesPerformance + - + + - - PerformanceExtensibility + ++ + + + + + + -- ExtensibilitySecurity - - + + + + SecurityUsability + ++ ++ - + Usability

++ ++ + + + ReusabilityAvailability AvailabilityReliability + ReliabilityMaintainability + + + - - + + ++ + + ++ MaintainabilityPrice - PriceRobustness + RobustnessInteroperability + + + + ++ + -- + + + InteroperabilityPortability + + + PortabilityCompany / organizational backing + - - + + + + + Company / organizational backingCommunity size + - + ++ + + -- - + Community sizeDeveloper efficiency + - - ++ + + + -- + -- - + - - + + o - - ++ ++ Developer efficiency

Results Results (count(+) - count(-))7 7 7 X X 9 5 2 4 5 2 0 X 5 2 2 2 0 4 1 1 1 6 -1 -2 6 -3 3 4 1 4 5 2A A A DI DI DI A DI DI A A A DI A A R R DI A A ID ID A DI DI A DI DI A R DI A A

LegendA Approved by stakeholder R Rejected after usageDI Discarded before usage ID Idea

Concerns

NFR 3) Addition of support for other tools, e.g., CI

Developer interested in GradleSkalli compatibilityCodecentric employees' technology familiarityCodecentric employees already have Jenkins accountsif (java compatible)

Reusability

Decisions Concerns

JVM based prog. language

Maintain compatibility with Java

Groovy as prog. lang

Scala as prog. lang.

JRuby as prog. lang.

Java as prog. lang

Simple Logging Facade for Java for logging

java.util.logging for logging

Maven for build automation

Gradle for build automation

Groovy HTTP Builder to communicate with REST web services

Custom application for project bootstrap

Maven archetype for project bootstrap

Continuous integration system agnostic configuration files

Groovy DSL for configuration files

JSON for configuration files

Jackson for JSON Object Mapping

GSON for JSON object mapping

Template view Pattern

Groovy Simple Template Engine for source code templates

Apache Velocity for source code templates

StringTemplate for source code templates

Web based interface

Desktop application based interface

Command-line interface

Jenkins plug-in

Custom web application

Extend Skalli

Continuous Integration System agnostic configuration files

Store Jenkins configuration files in the scaffold

Robot Framework as test runner

Jbehave as test runner

Selenium WebDriver for integration tests

Table 6.3: Architecture forces view which shows how each architecture decision is ranked in context of its alternatives. Results of this comparison were used to support the decision making process. The forcesview is based on [38].

46 Appendices

Appendices 47

<<

devic

e>

>W

eb

Serv

er

<<

devic

e>

>V

CS

Serv

er

<<

devic

e>

>P

ers

on

al C

om

pu

ter

<<

devic

e>

>C

on

tin

uou

s I

nte

gra

tion

Syste

m S

erv

er

<<

devic

e>

>P

roje

ct

Man

ag

em

en

t S

yste

m S

erv

er

<<

exe

cuti

on

En

vir

on

men

t>>

:Jen

kin

s C

I

<<

web

bro

wse

r>>

<<

art

ifact

>>

Gre

en

hop

per

<<

art

ifact

>>

Con

flu

en

ce

<<

art

ifact

>>

JIR

A

<<

art

ifact

>>

Hu

dson

CI

<<

art

ifact

>>

Jen

kin

s C

I

<<

art

ifact

>>

jan

us.j

ar

<<

art

ifact

>>

Git

<<

art

ifact

>>

Merc

uri

al

<<

art

ifact

>>

jan

us-p

lug

in.h

pi

<<

pro

toco

l>>

HTTP

<<

pro

toco

l>>

HTTP

<<

pro

toco

l>>

HTTP

<<

pro

toco

l>>

TCP/IP

Figure 6.7: UML deployment diagram depicting interactions between the various systems andhow the Janus application is deployed.

48 Appendices

de.codecentric.janus.atlassian.jira

JiraSoapSession JiraSession

<<Interface>>JiraSoapClient

<<Interface>>JiraRestClient

JiraRestClientImpl

JiraClient

JiraSoapClientImpl

1

*

1

1

1

1

1

*

1 1

1

Figure 6.8: A UML class diagram showing how the web service client hides the differencesbetween the two available web services, i.e., REST and SOAP.

Appendices 49

A.2 Excerpts from the Project Plan

Project Stakeholders

This section gives an overview about the identified stakeholders and their priority with respect

to the requirements and project success. This means that requirements of a high priority

stakeholder have a more critical effect on the project’s success than low priority stakeholders’

concerns. This prioritisation scheme was adapted from [18].

High Priority

Andreas Ebbert-Karroum Andreas Ebbert-Karroum had the initial idea to automate the

configuration and setup process. Not only is he this project’s company supervisor, but

also head of the Agile Software Factory division of the codecentric AG. As such he and

fellow configuration managers need to setup development environments on a regular basis

and therefore would benefit greatly from an automated process.

Configuration Managers As mentioned before, development environments need to be setup

frequently by configuration managers. An application which automates the process is

therefore beneficial.

Medium Priority

System Administrators The project’s goals indicate that a fair amount of critical systems

need to be configured automatically. Since this is sensitive data, system administrators

need detailed information about proper system configuration, operation and backup to

avoid data loss. Furthermore, the system should preferably integrate itself within the

existing technology stack to minimise costs.

Developers (End Users) Employees want to setup repositories or configure further CASE

tools in order to use them for personal education as part of their 4+1 working model.

They might also be interested to use the system to look up information about a project’s

version control system, mailing list or other information.

codecentric AG Development of the product is sponsored by the codecentric AG. Other than

this, the company has mostly constrictive concerns, e.g., no money available for tools or

third-party libraries.

Developers (of the system) The system will be developed as part of a bachelor thesis and

as such must be rateable. This means that certain parts of the application must be

available to assessors. Also, developers have various other concerns, e.g., experience or

interest using or learning a technology or technique.

50 Appendices

Low Priority

Skalli Project The Skalli project is interested in open source contributions to their system,

especially with respect to a Sonar integration. It would therefore be good to share knowl-

edge, components or prototypes with them or to continue development of the Skalli project

should Skalli match the identified requirements.

Oce Technologies B.V. Oce Technologies B.V. has shown interest in Janus. Specifically, the

CI system configuration is of interest to them.

Project Risk Analysis

Risk Effect Level

Name Description

Catastrophic May result in project failure or impediments which can not easily be overcome.Serious Has a strong effect on the project and may result in unmet deadlines.Tolerable Little to no effect on the project.

Table 6.4: Risk effect level definition.

Risk Probability Level

Name Probability

Very High >75%High 50 - 75%Moderate 25 - 50%Low <25%

Table 6.5: Risk probability level definition.

Risk Descriptions

The project’s risks are explained in the following subsections. The subsections are ordered by

risk effect and risk probability thus the most serious risk comes first. Risks with risk level

tolerable are not included.

Personnel Shortfalls

Effect: catastrophic; probability: low

As this project is done by a single person, illness and other impediments which hinder the

Appendices 51

engineer’s ability to work on the project have a catastrophic impact. Unfortunately, other than

eating healthy and taking regular breaks, there is not much which can be done to reduce the

risk’s effect or probability.

Failure to Manage End-user Expectations

Effect: catastrophic; probability: low

A lot of tasks can be automated and it is likely that the stakeholders will come up with

additional requirements. While it may be possible to include some of those requirements, it

will probably not be possible to include all of them. Progress and plans are communicated

with the stakeholders to alleviate this risk. Furthermore, the stakeholders get regular feedback

through the sprint review and progress reports.

Lack of Jenkins Plug-in API Support

Effect: serious; probability: high

Jenkins is utilised as a platform for Janus’ UI. As a CI system, Jenkins’ plug-in API does not

necessarily provide all the features which are required for Janus, e.g., the creation of a new

view which is unrelated to Jenkins’ core functionality. While feasibility of a Jenkins plug-in

was evaluated early on, it became obvious that some things are simply not supported at all.

Luckily, JavaScript can be used on the client side to transform Jenkins’ output and to

transform HTML forms in such a way, that Jenkins can retrieve and deserialise form data. By

doing this, no workarounds need to be found on the server-side (which is likely to break in the

future).

Lack of API Support for Stakeholders’ Requirements

Effect: serious; probability: moderate

Many requirements are highly dependent on third-party applications’ APIs. For instance, in

order to support automatic project creation in JIRA and Confluence while maintaining applica-

tion robustness, JIRA’s API must support all the features necessary to fulfil the requirements.

If this should not be the case, alternative approaches must be pursuit. A different approach

would be to configure JIRA et al. through the graphical user interface. As most systems

are web applications, this could be done with Selenium WebDriver. Unfortunately this is not

robust as unforeseen errors are not easy to track. In addition, this would strongly degrade

maintainability, because simple configuration steps might require several activities like login

through HTML forms or navigation through HTML POST requests.

The stakeholders were made aware of this risk. To further research feasibility, a spike was

planned and executed in sprint three.

52 Appendices

Lack of Application Robustness

Effect: serious; probability: low

The application should never break the system configurations of other applications, e.g., JIRA,

Jenkins or Mercurial. Even occasional misconfiguration is not tolerable as this would have a

serious impact on the company.

To cope with this risk, it is made sure that only the APIs provided by the applications

are used. Automation tools like Selenium WebDriver may only be used in agreement with

stakeholders.

Appendices 53

A.3 Textual Architecture Decision Documentation

JVM based Programming Language

The Java Virtual Machine (JVM) is a platform for various languages that were developed in

the recent years. As Java compiles to bytecode, all languages can make use of the existing

infrastructure and libraries, i.e., the software which was originally developed using and for the

Java programming language.

As far as the codecentric AG is concerned, JVM based programming languages are their

preferred choice.

Maintain Compatibility with Java

While all JVM based programming languages can make use of existing Java libraries and

frameworks, not all of them can be compiled and used from Java.

For example, some programming languages like Scala or Clojure have features for which no

counterpart exists in Java. As a result, interoperability between is reduced.

Maintaining compatibility with Java increases the chance, that this application will later

be used and enables the Eclipse Skalli project to make use of some parts of this application.

Groovy as Programming Language

Groovy code looks almost like Java code and as such only requires a small amount of studying.

Depart from the developer’s interest in this language, the language is further commercially

supported by SpringSource and one of the preferred languages of the codecentric AG.

When compared to Java, Groovy can be considered as an extension of the Java syntax which

improves expressiveness and developer efficiency.

Scala as Programming Language

With a mix of imperative and functional programming, Scala seems very interesting. It provides

various ways for operator loading (which is commonly considered a bad feature, similar to the

misuse of C++ operator overloading).

What is more important in the context of this project though is the vast amount of syntactic

rules that would need to be learned and the time which is necessary to become efficient with

Scala.

JRuby as Programming Language

Learning JRuby would yield useful skills for the developer, but it would be a bad choice for

the codecentric AG. Throughout the codecentric AG, JRuby does not seem to be used. This

54 Appendices

would complicate ongoing maintenance.

On top of this, like Scala, JRuby is not appropriate for library implementations.

Java as Programming Language

Java clearly dominates the forces view when it comes to programming languages. With the

developer’s and company’s experience being in favour of Java, it gained more points than any

other programming language.

Still, it is not used. The developer can be properly motivated through new technology and

skills which is why Groovy is chosen in favour of Java.

Simple Logging Facade for Java for Logging

Various information needs to be logged throughout the application’s execution. Such logs need

to include information about errors, user activity and the like.

While Java already has a logging framework as part of the development kit (JDK), using this

logging facility would mean the users of the library are also bound to it. Using an indirection

layer like the Simple Logging Facade for Java (SLF4J) enables the libraries’ users to configure

the logging facility according to their needs.

java.util.logging for Logging

This logging facility comes bundled with Java, but is a bad choice for libraries that are to be

used by other developers due a lack of configuration and duplicated amount of logging libraries

on the classpath.

Maven for Build Automation

A lot of plug-ins are available for Maven. In general, it is a nice tool and fits its purpose. It

was not chosen because of the developer’s curiosity and Gradle’s similar (though less verbose)

functionality.

Gradle for Build Automation

Gradle is a mix between Ant and Maven and tries to combine the best of both worlds. If it

was not for the developer’s curiosity, it would not have been chosen as Maven provides similar

functionality and does not require a training period.

Appendices 55

Groovy HTTP Builder to Communicate with Jenkins REST Web

Services

The HTTP Builder is basically a simple wrapper around Apache HTTP Client which utilises

Groovy’s capability for domain specific languages. Through it, readability is improved and

code duplication is avoided.

Maven Archetype for Project Bootstrap

Source code needs to be generated so that new projects can have direct access to an appropriate

scaffold that uses the companies’ technology stack.

Maven archetypes provide a nice solution for the generation of an initial project structure.

On top of this, a huge amount of archetypes is already available.

The downside, only Maven projects are supported. Since the codecentric AG also makes

use of other build automation tools and because directory structure are not always the same,

Maven is not an option.

Custom Application for Project Bootstrap

Needs to be developed to add necessary functionality, e.g., continuous integration job creation

and tool / structure independent project templates.

Continuous Integration System Agnostic Configuration Files

In order to allow interoperability with a wide range of applications and to stay relevant in a

steadily changing environment, the continuous integration system configuration will be appli-

cation / system agnostic.

An alternative would be store system specific configuration files, e.g., Jenkins’ or Hudson’s

config.xml.

Store Jenkins Configuration Files in the Scaffold

By doing this Janus would become less extensible and scaffolds would be harder to maintain.

An update of the general structure of Jenkins configuration files would require changes of all

scaffolds.

Groovy DSL for Configuration Files

With a domain specific language, expressive configuration files can be realised. General project

template configuration as well as build job configuration can benefit from a DSL as this improves

56 Appendices

readability and reuse. Since it is an internal DSL, all Groovy features can be used which is also

the largest week point as security needs to be taken care of.

JSON for Configuration Files

JSON was used initially throughout the analysis phase. It was rejected in favour of the Groovy

DSL because it produces less readable and maintainable configuration files.

Jackson for JSON Object Mapping

Jackson was used to parse the JSON files and was chosen over GSON for its widespread use

and performance benefits.

GSON for JSON Object Mapping

As already mentioned, Jackson was used instead of GSON. Except for community size and

performance, both libraries actually fulfil the same task.

Template View Pattern

To generate configuration files for the continuous integration system, large amounts of text

need to be combined. Even though possible with a programming language, doing this directly

in the code is not maintainable.

With the help of the template view pattern, configuration file templates can be used that

contain simple processing instructions. With the help of these instructions and content place-

holders, documents can be generated in an elegant way.

Groovy Simple Template Engine for Source Code Templates

A simple, yet powerful implementation of the template view pattern. Is part of the Groovy

development kit and is also used for this reason.

Holds some security issues as templates are executed.

Apache Velocity for Source Code Templates

Possible replacement for Groovy Simple Template Engine. Interesting as Velocity is commonly

used.

Appendices 57

StringTemplate for Source Code Templates

Possible replacement for Groovy Simple Template Engine. Interesting as StringTemplate en-

forces logic-less templates.

Web Based Interface

A web based user interface is a common choice and is also in this case a good idea. Managing

a set of project templates on every machine would be a hassle. With a web interface hosted

on a single machine, administration would be simplified. System administrators can maintain

the scaffolds and change user access rights. At last, clients do not need to install anything and

software updates can be rolled out in a simpler way.

Desktop Application Based Interface

Harder to maintain than a web based interface and does not provide any benefits over web

based interfaces.

Command-line Interface

Like desktop application, but in this case the user interface is even less accessible.

Jenkins Plug-in

Jenkins is already used throughout the codecentric AG as the continuous integration system

of choice. The employees are accustomed to this system and have user accounts. For these

accounts, access privileges can be defined as necessary. On top of this, Jenkins provides means

for storing user data and configuration menus.

The Jenkins environment can be leveraged for this project by writing a plug-in which will

act as the user interface. Jenkins is therefore used as the GUI platform for Janus.

Custom Web Application

A new web application could be developed to implement a user interface for the Janus appli-

cations. Due to time constraints though, it is likely that the overall final-product would be of

lower quality when compared to a Jenkins plug-in.

On top of this, employees would have to remember an additional set of user credentials.

Extend Skalli

Skalli provides a complete platform that already covers a small subset of this project’s require-

ments. By extending Skalli, this platform could be leveraged.

58 Appendices

The major obstacle is that Skalli is a large project which would require a lot of time dedicated

to studying and learning the system. The lack of documentation and mailing list activity

furthermore does not make this task any simpler.

Robot Framework as Test Runner

The Robot Framework is commonly used as a test runner in combination with other tools

and plug-ins to realise acceptance or integration tests. It is therefore similar to JBehave, but

extending it with new functionality is complex. Since Janus integration tests require control

over various servers, the Robot Framework was not chosen as the developer has no experience

with it and could not evaluate how much additional time this would have required.

JBehave as Test Runner

JBehave is a test runner and similar to JUnit. It takes tests which are defined through stories

or acceptance criteria and maps the statements to execution logic. Extending it with new

functionality is therefore easy and server control can easily be realised.

Selenium WebDriver for Integration Tests

Selenium WebDriver is the de facto standard for browser testing. It supports a variety of

browsers and can even control them remotely. It is valuable to test user interaction as the

codecentric AG has strong robustness requirements.

References

[1] Apache Software Foundation. Procedures for Creating a Project. http://www.apache.

org/dev/project-creation.html as of 2012-04-18.

[2] Atlassian Pty Ltd. Bamboo Plugins - Atlassian Plugin Exchange. https://plugins.

atlassian.com/search/by/bamboo as of 2012-02-21.

[3] Atlassian Pty Ltd. JIRA 5.0 REST API documentation). https://developer.atlassian.

com/static/rest/jira/5.0.html as of 2012-05-11.

[4] Atlassian Pty Ltd. JiraSoapService (JIRA RPC - Plugin 4.4 API). http:

//docs.atlassian.com/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/

JiraSoapService.html as of 2012-05-11.

[5] Ben Ripkens. Re: [skalli-dev] Assessing Skalli for the requirements of the codecentric AG).

http://dev.eclipse.org/mhonarc/lists/skalli-dev/msg00150.html as of 2012-05-11.

[6] Ben Ripkens and Simon Kaufmann. Assessing Skalli for the requirements of the codecentric

AG. http://dev.eclipse.org/mhonarc/lists/skalli-dev/msg00108.html as of 2012-

04-19.

[7] Black Duck Software, Inc. Compare Repositories - Ohloh. http://www.ohloh.net/

repositories/compare as of 2012-02-19.

[8] A. Brown and G. Wilson. The Architecture of Open Source Applications, volume 1. Amazon

Digital Services, 2011.

[9] CruiseControl contributors. CruiseControl Plugins. http://cruisecontrol.sourceforge.

net/main/plugins.html as of 2012-02-21.

[10] Dan North. Introducing BDD. http://dannorth.net/introducing-bdd/ as of 2012-04-16.

[11] Dirk Riehle. Open Source Study: Analytics, Economics & Best Practices. http://www.

youtube.com/watch?v=IJPqHiW1duo as of 2012-04-18.

[12] Paul M. Duvall, Steve Matyas, and Andrew Glover. Continuous Integration: Improving

Software Quality and Reducing Risk. Addison-Wesley Professional, 1 edition, July 2007.

59

http://www.apache.org/dev/project-creation.html

http://www.apache.org/dev/project-creation.html

https://plugins.atlassian.com/search/by/bamboo

https://plugins.atlassian.com/search/by/bamboo

https://developer.atlassian.com/static/rest/jira/5.0.html

https://developer.atlassian.com/static/rest/jira/5.0.html

http://docs.atlassian.com/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/JiraSoapService.html



http://dev.eclipse.org/mhonarc/lists/skalli-dev/msg00150.html

http://dev.eclipse.org/mhonarc/lists/skalli-dev/msg00108.html

http://www.ohloh.net/repositories/compare

http://www.ohloh.net/repositories/compare

http://cruisecontrol.sourceforge.net/main/plugins.html

http://cruisecontrol.sourceforge.net/main/plugins.html

http://dannorth.net/introducing-bdd/

http://www.youtube.com/watch?v=IJPqHiW1duo

http://www.youtube.com/watch?v=IJPqHiW1duo

60 References

[13] Eclipse Foundation. List archive of Skalli-dev. http://dev.eclipse.org/mhonarc/lists/

skalli-dev/ as of 2012-04-18.

[14] Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architec-

tures. PhD thesis, University of California, Irvine, 2000.

[15] Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Profes-

sional, November 2002.

[16] Martin Fowler. Domain-Specific Languages. Addison-Wesley Professional, 2010.

[17] GitHub, Inc. GitHub Enterprise - Install GitHub on Your Servers. https://enterprise.

github.com/ as of 2012-04-19.

[18] Martin Glinz and Roel J. Wieringa. Stakeholders in requirements engineering. IEEE

Software, 28(1):18–20, March 2007.

[19] Google Inc. Google Trends: jira,redmine,bugzilla,Team Foundation Server.

http://www.google.com/trends/?q=jira,redmine,bugzilla,Team+Foundation+

Server&date=all&geo=all&ctab=0&sort=0&sa=N as of 2012-05-15.

[20] Hudson contributors. Plugins - hudson - Hudson Wiki. http://wiki.hudson-ci.org/

display/HUDSON/Plugins as of 2012-02-21.

[21] J. Humble and D. Farley. Continuous Delivery: Reliable Software Releases Through Build,

Test, and Deployment Automation. The Addison-Wesley Signature Series. Addison-Wesley,

2010.

[22] Indeed. continuous integration, software development Job Trends — Indeed.com.

http://www.indeed.com/jobtrends?q=continuous+integration%2C+software+

development&l=&relative=1 as of 2012-02-21.

[23] Indeed. jira,redmine,bugzilla,”Team Foundation Server” Job Trends — Indeed.com.

http://www.indeed.com/jobtrends?q=jira%2Credmine%2Cbugzilla%2C%22Team+

Foundation+Server%22&l= as of 2012-02-25.

[24] Indeed. subversion,git,mercurial,cvs version control Job Trends — Indeed.com.

http://www.indeed.com/jobtrends?q=subversion%2Cgit%2Cmercurial%2Ccvs+

version+control&l=&relative=1 as of 2012-02-19.

[25] Institute for Software Quality. SPM: Single Point of Maintenance. http://www.ifsq.nl/

single-point-of-maintenance.html as of 2012-04-24.

[26] Jenkins contributors. Plugins - Jenkins - Jenkins Wiki. https://wiki.jenkins-ci.org/

display/JENKINS/Plugins as of 2012-02-21.

http://dev.eclipse.org/mhonarc/lists/skalli-dev/

http://dev.eclipse.org/mhonarc/lists/skalli-dev/

https://enterprise.github.com/

https://enterprise.github.com/

http://www.google.com/trends/?q=jira,redmine,bugzilla,Team+Foundation+Server&date=all&geo=all&ctab=0&sort=0&sa=N

http://www.google.com/trends/?q=jira,redmine,bugzilla,Team+Foundation+Server&date=all&geo=all&ctab=0&sort=0&sa=N

http://wiki.hudson-ci.org/display/HUDSON/Plugins

http://wiki.hudson-ci.org/display/HUDSON/Plugins

http://www.indeed.com/jobtrends?q=continuous+integration%2C+software+development&l=&relative=1

http://www.indeed.com/jobtrends?q=continuous+integration%2C+software+development&l=&relative=1

http://www.indeed.com/jobtrends?q=jira%2Credmine%2Cbugzilla%2C%22Team+Foundation+Server%22&l=

http://www.indeed.com/jobtrends?q=jira%2Credmine%2Cbugzilla%2C%22Team+Foundation+Server%22&l=

http://www.indeed.com/jobtrends?q=subversion%2Cgit%2Cmercurial%2Ccvs+version+control&l=&relative=1

http://www.indeed.com/jobtrends?q=subversion%2Cgit%2Cmercurial%2Ccvs+version+control&l=&relative=1

http://www.ifsq.nl/single-point-of-maintenance.html

http://www.ifsq.nl/single-point-of-maintenance.html

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

https://wiki.jenkins-ci.org/display/JENKINS/Plugins

References 61

[27] Kohsuke Kawaguchi. Jenkins 1.396 released. http://jenkins.361315.n4.nabble.com/

Jenkins-1-396-released-td3257106.html as of 2012-02-21.

[28] Martin Fowler. Continuous Integration. http://www.martinfowler.com/articles/

continuousIntegration.html as of 2012-02-19.

[29] Martin Fowler. TestPyramid. http://martinfowler.com/bliki/TestPyramid.html as of

2012-05-17.

[30] Martin Fowler. VcsSurvey. http://martinfowler.com/bliki/VcsSurvey.html as of 2012-

02-19.

[31] Martin Fowler. VersionControlTools. http://martinfowler.com/bliki/

VersionControlTools.html as of 2012-02-19.

[32] Neal Ford. Polyglot Programming. http://memeagora.blogspot.de/2006/12/

polyglot-programming.html as of 2012-05-06.

[33] Bryan O’Sullivan. Making sense of revision-control systems. Commun. ACM, 52:56–62,

September 2009.

[34] Roman Pichler. Scrum: Agiles Projektmanagement erfolgreich einsetzen. dpunkt, Heidel-

berg, 2007.

[35] PMSG PersonalMarkt Services GmbH. Fuhrungskrafte und Spezialisten in IT-Funktionen

2011/2012, October 2011.

[36] Steve D. Suh and Iulian Neamtiu. Studying software evolution for taming software com-

plexity. In Proceedings of the 2010 21st Australian Software Engineering Conference,

ASWEC ’10, pages 3–12, Washington, DC, USA, 2010. IEEE Computer Society.

[37] Travis CI GmbH. Travis CI - Distributed build platform for the open source community.

https://travis-ci.org/stats as of 2012-05-15.

[38] U. van Heesch, P. Avgeriou, and R. Hilliard. A documentation framework for architecture

decisions. Journal of Systems and Software, 85(4):795–820, April 2012.

[39] Wikipedia. Janus. http://en.wikipedia.org/wiki/Janus. Revision as of 11:15, 9 Febru-

ary 2012.

http://jenkins.361315.n4.nabble.com/Jenkins-1-396-released-td3257106.html

http://jenkins.361315.n4.nabble.com/Jenkins-1-396-released-td3257106.html

http://www.martinfowler.com/articles/continuousIntegration.html

http://www.martinfowler.com/articles/continuousIntegration.html

http://martinfowler.com/bliki/TestPyramid.html

http://martinfowler.com/bliki/VcsSurvey.html

http://martinfowler.com/bliki/VersionControlTools.html

http://martinfowler.com/bliki/VersionControlTools.html

http://memeagora.blogspot.de/2006/12/polyglot-programming.html

http://memeagora.blogspot.de/2006/12/polyglot-programming.html

https://travis-ci.org/stats

http://en.wikipedia.org/wiki/Janus

automatic configuration of server side software development environments

Documents