Rethinking Release

Transcription

Rethinking Release

Master of IT – Software Engineering
Final Project
Rethinking Release – a case study
16th March 2015
Student: Kenn A. Thisted ([email protected])
Supervisor: Dr. Yvonne Dittrich, Associate Professor
Contents
Abstract.................................................................................................................................................2
1. Introduction......................................................................................................................................3
2. Case background..............................................................................................................................3
2.1 Overview of IT at Topdanmark..................................................................................................4
2.2 Existing tools landscape.............................................................................................................4
2.3 Existing release process.............................................................................................................5
2.4 Recent initiatives........................................................................................................................7
2.4.1 Partial Branches.................................................................................................................7
2.4.2 Branch Automation Server.................................................................................................8
2.4.3 Build automation................................................................................................................9
3. Related work.....................................................................................................................................9
3.1 Continuous software engineering..............................................................................................9
3.1.1 Continuous Integration.....................................................................................................10
3.1.2 Continuous Delivery and Continuous Deployment.........................................................10
3.1.3 Maturity models...............................................................................................................11
3.2 Deployment pipeline................................................................................................................13
3.3 DevOps....................................................................................................................................14
3.4 Summary of related work........................................................................................................15
4. Method............................................................................................................................................16
4.1 Research approach...................................................................................................................16
4.2 Fieldwork and analysis methods..............................................................................................17
4.3 Reflection on the research process and fieldwork...................................................................18
4.4 Trustworthiness........................................................................................................................19
5. Case description..............................................................................................................................19
5.1 Case selection..........................................................................................................................20
5.2 Course of events.......................................................................................................................21
6. Analysis..........................................................................................................................................23
6.1 Tool design...............................................................................................................................24
6.1.1 Extension to user interface...............................................................................................25
6.1.2 Limitations.......................................................................................................................25
6.1.3 The extent of the change..................................................................................................26
6.2 Application impact...................................................................................................................28
6.3 Process impact.........................................................................................................................29
6.4 Learnings for the organisation.................................................................................................29
7. Discussion.......................................................................................................................................30
8. Conclusion......................................................................................................................................32
References..........................................................................................................................................34
Abstract
Context: For a number of years software in Topdanmark has been released on a monthly basis, and a demand
for more frequent releases is becoming a key issue. The existing process, tools and recent initiatives to renew
the infrastructure serve as stepping stones for rethinking the release process and tools. The subject of the
study is a targeted collaborative effort between an infrastructure tools team and a development team to
design and implement a concept and solution to this problem within certain time and scope constraints.
Thus a continuous delivery proof-of-concept was conducted over a period of 3 months between October 2014
and January 2015.
Objective: Answering the problem if and how a higher frequency of software releases could be achieved.
Method: A qualitative case study was designed and conducted to observe and reflect on the course of events
and result of the proof-of-concept effort.
Result: Fieldwork examples are included in the case description, and supported by design sketches and
implementation examples the analysis shows the result as effects on tool design, application impact, process
impact, and learnings. The main focus is on the small scale of the resulting design and implementation, but
also important are the effects on the application architecture and the immediate improvement on the process
of the development team. Discussion topics include the value of the collaborative effort, the small design and
automation effort needed compared to initial expectations, the dilemma of having to leave some software
behind, and requirements to application architecture in order to take advantage of the concept as
implemented in the proof-of-concept.
Conclusion: The study concludes by confirming how we were actually able to design and implement a
continuous delivery solution, and even though it supports only a narrow subset of applications, it provides a
starting point for the organization to gain experiences with releasing software more frequently.
Master i Software Engineering (Professional Master of IT)
Final Project: Rethinking Release – a case study
16th March 2015
Student:
Kenn A. Thisted ([email protected])
Supervisor:
Dr. Yvonne Dittrich, Associate Professor
Kenn A. Thisted, 2015
2
1. Introduction
For a number of years software in Topdanmark*) has been released on a monthly basis. Excluding a release
every summer and winter this allows for about 10 planned ordinary releases a year. Each release involves a
comprehensive process of testing, build, release management, and deployment.
A demand for more frequent releases is materialising both from developers and from product owners
representing business needs. This is becoming a key issue in the near future which lead me to want to
investigate:
•
Can we achieve a significantly higher frequency of software releases at Topdanmark without compromising quality?
In order to support this main problem the study should also investigate the efforts towards achieving this
goal.
In the autumn of 2014, responding to the recognized business needs of increased frequency and flexibility in
releasing software, Topdanmark IT decided to conduct a continuous delivery proof-of-concept (PoC) in a
collaborate effort between a tools team and a development team. The effort was titled "HypR PoC"
abbreviating the Danish term for increased release frequency: Hyppigere Releases.
This report is a design case study documenting and analysing this collaborative effort and the resulting
product and impact. In the report I will strive for referring to the subject of the study as the proof-of-concept
(PoC) while the study itself is referred to as the project.
2. Case background
This chapter establishes background information about the current organisation, processes and tools relevant
to the following analysis of this case.
*) Topdanmark is the second-largest insurance company in Denmark.
3
2.1 Overview of IT at Topdanmark
Topdanmark is an insurance company operating in Denmark. Spanning both property & casualty as well as
life insurance the company has approximately 2,700 employees. Topdanmark has it's own IT department
covering both development and operations. The IT department consists of about 400 employees of which
roughly 200 work in development.
Software development in Topdanmark IT is mainly organised in five departments each supporting separate
lines of business (see figure 2.1). Bridging these are IT Operations which is responsible for executing,
monitoring, and supporting running IT systems. In addition Architecture & Methods (A&M) provides
common architectural and infrastructure components shared across other departments.
Figure 2.1: IT departments supporting lines of business
In A&M the Agile Development & Testing team is responsible for the processes, tools, and infrastructure
supporting software development in Topdanmark.
2.2 Existing tools landscape
This section briefly introduces the primary tools and technologies used at Topdanmark relevant to this case
study.
The effort in this PoC focuses on applications written in Java and running on Microsoft Windows. Java is
coded using primarily Eclipse IDE, but others are allowed, and run on IBM WebSphere Application Servers
(WAS). The shared database is IBM DB2 on the mainframe. Database schemas are created and maintained
using CA ERwin Data Modelling.
4
The main code repository is Serena Dimensions CM, and support for build and release processes are built
with and around this tool. Deployment and environment provisioning is a proprietary solution (written
mostly in PowerShell) based on BMC BladeLogic Server Automation.
Dimensions is a Centralized Version Control System (CVCS) in which all source code artefacts are stored.
The existing build and deployment pipeline triggered from this is a custom built workflow with a web client
user interface. The example below (figure 2.2) shows how build targets can be selected and subsequently
deployed to the desired environment. Other custom tools include a build & dependency fetcher plugin for
Eclipse.
Figure 2.2: Custom 'Build and Deploy' web interface
Additional tools and technologies are used for mainframe applications, building the public web site, as well
as a variety of supporting functions, but these are excluded from the current study.
2.3 Existing release process
The current release process in Topdanmark has been in operation for a number of years. Inspired by Unified
Process [Jacobsen et al. 1999] the TopUP (Topdanmark Unified Process) process was introduced to coordinate releases from several systems in and across departments, streamlining them into unified release trains
running approximately once a month (see figure 2.3).
5
Figure 2.3: The monthly TopUP process release train
The internal introduction material to TopUP states these as primary objectives for the process: documenting
development initiatives, audit requirements for code in production, and at any given moment knowing who
did what to which code, and why. The process aims to be quite open and delegate responsibility to the
developer in stating two rules only: You may not deliver code that breaks other peoples code, and in order to
submit code you must state the reason why.
Figure 2.4: The existing branching model
In the current process code is produced at the developer's workstation and checked into a branch in
Dimensions. During development and testing code is built from a branch and deployed on one of an array of
Distributed Source Control Management (DSCM) environments/servers. Following successful testing
(automated and/or manual) code is pushed to Main branch. From there it is subsequently being built again
and tested in collaboration with code from other branches in what are called Integration and Release tests,
and upon verification allowed onto the Production environments (see figure 2.4). For the scope of this report
6
it is not necessary to understand the branching strategy that the model represents in detail. It is sufficient to
recognize that there is some degree of complexity involved in handling multiple branches and understand
the flow of code that the direction of the arrows indicate.
DSCM environments are virtual servers, whereas Release, and Production are "physical" environments in
that they have dedicated servers. The physical environments are duplicated, and for every release code is
deployed on a non-production set. Pending verification production is simply switched to the new set.
2.4 Recent initiatives
Like most places the set of tools and technologies evolves over time – sometimes defensively to not run out
of support, but more interesting in this case also offensively to benefit from new features. The general level
of tools is kept reasonably updated, but of special interest to the release process a couple of recent initiatives
are significant.
2.4.1 Partial Branches
When TopUp was introduced all branches were fully populated (see branching model in figure 2.4 above) i.e.
they each contained the full set of items. In order to reduce time spent working with each branch (e.g. rebase
and deliver in figure 2.3), as well as reducing storage space needed, the concept of partial branches was
introduced and implemented in March 2013. This allows and encourages development teams to only keep
the necessary items – items that are actually being worked on – in their own branch.
Initially the concept was introduced for the server platform (Java and PHP code) where it maps well with
project directory structures. Starting October 2014 the concept was expanded to include the mainframe
platform (COBOL and PL/I code) based on a custom filtering by member (file) type and name.
The prevalence of the partial branches concept is communicated by publishing “Dimensions Partial
Population Statistics” comprised of a graph showing the average branch population for the latest 3 months
(see figure 2.5) supplemented by a list of population percentages for each branch. The list is omitted here
since I trust that the graph itself is sufficient to illustrate the concept.
7
Figure 2.5: Branch population average (3 months)
The black line indicates the average population percentage across all branches (number of branches stated
for each date). The green line indicates the target potential based on items actually having been touched
within the latest year.
2.4.2 Branch Automation Server
A couple of years ago the concept of a Branch Automation Server (BAS) was introduced. This is a
Continuous Integration (CI) platform (see related work section 3.1.1), based on a set of common tools like
Jenkins (as the CI server) and SonarQube (for static code analysis), which allows the tools team to offer this
as standardized server instances to development teams. Using this common BAS concept development
teams can take advantage of a shared effort and avoid having to set up this infrastructure themselves. As the
name implies a BAS can be issued to each branch serving as an engine automatically running the team's unit
tests (e.g. in JUnit), acceptance tests (e.g. Robot Framework), or other kinds of automatable testing
technologies. In addition the BAS offers static code analysis initially supporting Java code, while support for
PHP code is planned for early 2015.
The purpose of this concept is to improve software quality by running tests and static analysis every time
code is checked into the branch. One important aim of CI is to prevent integration problems occurring when
merging developer copies of code. Performing this integration frequently using automation keeps the effort
and scope of problems small compared to more infrequent manual integrations that was commonplace
before.
8
2.4.3 Build automation
The existing build process in TopUp consists of custom built tools around and integrating to Dimensions.
Since October 2014 this proprietary build infrastructure is supplemented by a parallel build process based on
Apache Maven (build automation server). Reasons for this include tool modernization and standardization.
By adopting a widely used modern build tool it is possible to take advantage of industry or community
support and mitigate the risk of critical knowledge being held by only a few key persons. The goal is to have
all builds transferred to Maven before end of June 2015 allowing the existing proprietary build tool to be
decommissioned.
3. Related work
This chapter will present selected research articles, books and book chapters, as well as other sources
relevant to continuous software engineering. Although terms and definitions presented have evolved from
earlier software engineering disciplines not much research exists on these contemporary conceptions.
Because of this most work presented is state of the art as in it represents the latest developments on the
subject.
3.1 Continuous software engineering
In software engineering the term "continuous" is used in various contexts. One example of its use in process
related contexts like lean and agile is continuous improvement which deals with the iterative effort of
incrementally improving practices. For the purpose of this report it is relevant however to introduce the
more technical practices of continuous integration, continuous delivery, and continuous deployment.
A common property for these concepts is automation. They all aim to automate steps of the software
development process in order to speed up these steps and consequently be able to get a quicker response of
success or failure of each step. This originates from a recognition that manually performing tasks like build,
test, and deployment is simply too slow and error prone to effectively achieve sufficiently fast feedback.
Hence automating these tasks is essential in supporting the overlying lean an agile processes' goal of being
able to efficiently adapt to changes.
9
Another important effect of automation is quality. Automating tasks like build, test, and deployment allows
for a consistent quality of the processes in that potential manual errors performing the tasks are avoided.
This way automation helps produce more dependable results. Although automation in itself does not affect
the quality of the code, a general perception is that the increased frequency of dependable feedback
encourages smaller and more manageable changes which in turn leads to better software. A common rule of
these practices is that if anything breaks during these tasks, regaining a stable build immediately becomes
first priority. By not allowing an error state to exist for very long this also contributes to the overall software
quality.
The following sections will elaborate on continuous software engineering by presenting terms that provide
different perspectives on the subject including industry best practice and case studies.
3.1.1 Continuous Integration
Originating from eXtreme Programming (XP) [Beck 1999] Continuous Integration is a practice in software
development where developers in a team integrate their code frequently – usually at least once a day. This
process of build, test, and possibly static code analysis is automated yielding the above mentioned benefits
of fast feedback allowing for quick response by the team. Continuous integration is widely used supporting
agile methods in software engineering. Even though the concept can quite easily be explained like in the
often quoted article by Martin Fowler [Fowler 2006] and several aspects were covered in more detail in the
basic textbook on the subject [Duvall et al. 2007], it is still very loosely defined, and often both descriptions
and implementations vary as elaborated upon in Continuous Integration Flows [Ståhl and Bosch 2014]. For
the purpose of this report it is sufficient to recognize that continuous integration is a predecessor to
continuous delivery in two ways: the former concept was introduced a few years prior to the latter, and it is
also generally perceived as a prerequisite in automated implementations.
3.1.2 Continuous Delivery and Continuous Deployment
The concept of Continuous Delivery is inspired by the first of the twelve principles [Beck et al. 2001] behind
the Agile Manifesto:
"Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software."
10
The subtitle of the basic textbook [Humble and Farley 2011] summarizes the purpose of continuous delivery:
Reliable software releases through build, test, and deployment automation. As stated earlier quality, implicitly in
reliable, is a key objective, and automation represents the means to achieve this.
Like with with continuous integration various interpretations of continuous delivery exist. One important
distinction to make is about the extent of automation. When researching or discussing the subject one
sometimes encounters some ambiguity in perceptions of Continuous Delivery and the much related term
Continuous Deployment. This project and report mirrors the definition that seems to be consistent with key
influencers like ThoughtWorks and PuppetLabs and reflected in the recent book Lean Enterprise [Humble et
al. 2014]:
"Despite the name, continuous delivery is not about deploying to production
multiple times a day. The goal of continuous delivery is to make it safe and
economic to work in small batches. This in turn leads to shorter lead times,
higher quality, and lower costs."
The important distinction in this context is that with Continuous Delivery deployment to production is a
manual step in the process, while in Continuous Deployment this step is automated. In both cases all other
steps are automated. The purpose of both is of course to provide frameworks for speeding up software
development, but this difference represents a key distinction in whether changes (assuming passed tests and
possible other metrics) are pushed into production automatically or, as preferred in this case, they can be
pulled into production upon request.
3.1.3 Maturity models
Continuous delivery maturity models visualise actions in progress towards successful implementation as
well as allowing organizations and teams to assess their current state, the gap towards their desired target
state, and next steps in that direction.
The research based "Stairway to Heaven" conceptual model [Olsson et al. 2012; Olsson and Bosch 2014]
defines five consecutive ascending steps in the transition of moving from traditional software development
towards continuous deployment. From four case studies the model shows evolutionary steps through agile
and continuous integration. Especially relevant for this report step four states that " Continuous deployment
11
implies that you continuously push out changes to the code instead of doing large builds and having planned releases of
large chunks of functionality", followed by emphasizing the importance of fast feedback. Although the article
talks about highly prioritized frequent delivery of software this is mentioned as an implicit part of step three:
continuous integration.
Figure 3.1: Olsson & Bosch's "Stairway to Heaven" evolution model
An observation to make regarding the book presenting this model [Bosch (Ed.) 2014] is that it contains
specific parts addressing steps two, three, and five. Regarding step four, however, it states: "The fourth step in
the stairway to heaven, continuous deployment, is not present explicitly in this book as it often evolves automatically as
a natural extension of continuous integration". Even though further investigation into this claim in relation to
others distinguishing between continuous integration, delivery, and deployment could prove interesting in
itself, it is out of scope for this report. For the purpose of this project and report the general steps and
evolutionary nature of the model are sufficient, as well as noting that even though not emphasized in this
model there is no immediate contradiction between the perceptions of delivery in this model and the
definition of continuous delivery in the section above.
A more elaborate maturity model was presented a couple of years earlier in the paper “The Agile Maturity
Model” [Humble and Russel 2009]. This model specifies important attributes towards continuous delivery,
presenting them in a matrix of themed groups (horizontal) and five ascending levels of maturity (vertical).
The same model, now with a “Configuration Management” theme appended, was presented a couple of years
later as “A Maturity Model for Configuration and Release Management” in the Continuous Delivery text book
[Humble and Farley 2011] (see figure 3.2).
12
Figure 3.2: Maturity model [Humble and Farley 2011, p.419]
This matrix concept has been adopted in industry context and similar models have been published as
Continuous Delivery Maturity Models in the last few years. Examples of these include an article from InfoQ
[Rehn et al. 2013] – a well known knowledge base in software development, and a paper from Praqma
consultants [Praqma unknown]. Both models have emerged from the agile community and are vendor
independent. The most recent example is a Tech Tip article from IBM urban{code} [Minick 2014] showing
that the concept is entering the space of major vendors.
These industry spin-offs share the same common properties as the original model. The models are not
identical but themed groups shared across all models include important disciplines like building, deploying,
testing, and visibility. In addition the InfoQ model includes “Culture & Organization” as a separate theme,
which makes very much sense in that these are essential factors in successful implementation of a change
towards continuous delivery. IBM's model introduces indicators of the current industry norm level for each
theme as well as the desired target level. Both are interesting contributions adding to the original model.
3.2 Deployment pipeline
In continuous delivery the deployment pipeline is an automated process that software being developed must
pass through on its way from the developer to Release. The pipeline chains processing elements together so
that the successful output of one flows into the next. Process elements that fail immediately returns control
to the developer, which is key to the early response/fast feedback aspect of continuous delivery. The concept
of the deployment pipeline is well described in the Continuous Delivery text book [Humble and Farley 2011]
13
in which the sequence diagram below (figure 3.3) visualizes how changes move through the pipeline.
Figure 3.3: Changes moving through the deployment pipeline [Humble and Farley 2011, p.109]
The deployment pipeline is also sometimes referred to as the software delivery pipeline or the build pipeline. In principle the pipeline could serve software changes at irregular intervals or even rare occasions, but
in the continual nature resulting from frequent changes it must be seen as an iterative process.
In a continuous delivery context it may be obvious to most that this pipeline refers to software development
in general. In model-driven development, however, a pipeline usually refers to a series of model transformations set up to efficiently support conformity between multiple uniform software deliveries. To briefly
address this ambiguity it should be pointed out that this latter definition is not what is referred to when
mentioning the pipeline in this project.
3.3 DevOps
DevOps and Continuous Delivery are not the same thing. More often than not one comes across resources
(texts, webcasts etc.) or discussions about software engineering in which these terms are used inter changeably. Since these are still emerging concepts, perhaps this is understandable, but in order to clarify the
perception of DevOps in this project, I will show some examples from a very recent, as in not yet published,
book on the subject [Bass et al. 2014]. The book has five parts: after introducing the subject, part two
specifically addresses the Deployment Pipeline (term known from Continuous Delivery above), and then
14
moves on to elaborate on cross cutting concerns, presents three case studies, and speculates on the future of
DevOps.
DevOps is a hybrid of process, relation, and a (new) practice. DevOps brings software developers and other
IT professionals, in particular in IT operations, closer together. At its most basic DevOps is about seeing
operations personnel as first class stakeholders, working in close collaboration on what is involved in
releasing software rather than just throwing software “over the wall”. At its most extreme, DevOps practices
make developers responsible for running their own applications that is monitoring them, handling errors
during deployment and execution, and perhaps even act as first line support. In between are practices that
cover team interactions as well as build, testing, and deployment processes. The DevOps lifecycle processes
diagram (figure 3.4) shows how development gradually advances towards encompassing processes
traditionally handled by other IT professionals including tools specialists and operations.
Figure 3.4: DevOps lifecycle processes [Bass et al. 2014, ch.1 p.4]
Regarding the deployment pipeline DevOps achieves its goals partially by replacing explicit coordination
with implicit coordination e.g. minimizing manual interactions and removing surplus artefacts. The
deployment pipeline concept is described much like in the previous section, although emphasizing
production as the last step (as with continuous deployment).
3.4 Summary of related work
The literature presented in this chapter has helped defining concepts relevant to this case. It explained the
key term of continuous delivery both in itself by referencing important definitions and models, and by
supporting it with related terms like continuous integration and the delivery pipeline, as well as comparing
15
it to DevOps which addresses many of the same elements from a different perspective. Presenting this also
supported the relevance and understanding of the existing tools and release process including the recent
initiatives presented as case background in the previous chapter.
4. Method
The research for this project was conducted as a case study. The research approach and fieldwork method is
explained in this chapter while the following chapters describe the actual case in more detail and present the
findings and result of the project in the analysis.
This chapter describes how information was gathered and processed as fieldwork for the case study as well
as reflects on the research artefacts produced and the how the process was appropriate for the purpose.
4.1 Research approach
The research presented in this report took place as part of a collaborative infrastructure effort involving a
tools team and a development team at Topdanmark. The subject of the research was designing and possibly
implementing a proof-of-concept for an improved release process. I investigated which design and scope
decisions the team made and how they worked towards this target.
The fieldwork included audio recordings of team meetings from which observations were noted, and
subsequent reflections made. Where relevant, recordings were supplemented with photos of whiteboard
notes and drawings from the meetings. My contribution to the project included defining the exterior
constraints of the project (like timebox and goal of the effort) in the role of Product Owner, and exploring
possible designs together with the team.
In my primary role as observer in this study I facilitated the audio recordings, collected them along with
other fieldwork items, e.g. design sketches, and subsequently processed these for the study. My intervention
in the project focussed on keeping progress towards the goal while mitigating threats to progress and
completion. In addition to that I assisted by clarifying questions along the way, especially regarding
constraints and whether some design ideas would be acceptable.
The research presented is based on qualitative observation only. Qualitative research targets understanding
16
how people work things out and arrive at solutions rather than measuring their effort based on certain
criteria.
The research method put to use in this project can be described as Participatory Action Design Research. The
action research element [Robson 2002] focuses on exploring the influence of introducing continuous delivery
as a change to the existing development process. The design element refers to the main task of devising how
the tool should be built to support this, and the participatory aspect refers to the fact that the design arose
from a collaborative effort between two teams undertaking the principal roles of users and designers
[Simonsen and Robertson 2013].
The typical action research process addresses an experimental approach of a cyclic nature. The aim is to
repeatedly understand a situation, deliberating change, implementing selected change, and then observing
and reflecting upon the effect as a basis for a subsequent cycle. As a qualitative research method it
investigates the how and why of decision making rather than meticulous quantitative measures. Focus is on
information produced only in the particular case studied. More general conclusions would merely be
informed assertions or propositions.
4.2 Fieldwork and analysis methods
The bi-weekly meeting of the planned PoC (see figure 4.1) were audio-recorded from which observations
were logged (see template in table 4.1 below). Subsequently reflections were noted by the observer only in a
separate session.
Figure 4.1: Observations timeline template
Prior to recording participants had been informed about this study and assured anonymity in the report.
Any material significant to the meetings has been captured and stored. This includes photos of whiteboard
notes and drawings, as well as any literature presented.
17
Time
hh:mm
Min.
Observationer (da)
mm:ss Transcription highlights
- in Danish, not anonymized
Reflections (en)
Post-observation reflections
- in English
Table 4.1 Template for collecting data
Following meetings, patterns in observations and reflections emerged by experimenting with grouping them
into categories (see table 4.2).
Pattern / Categories
Obs.
#
Relevant observations and reflections
First observation
Second observation
Third observation
Fourth observation
…
Cat. A
Cat. B
Cat. C
Cat. D
•
•
•
•
Table 4.2 Template for exploring observation patterns
Instantiation examples illustrating the use of these templates in the fieldwork are given in the case description below (chapter 5).
4.3 Reflection on the research process and fieldwork
When evaluating the implementation of the research process what comes to mind is the difference between
expectations at the outset and the actual course of the project. As it turned out observations along the
expected timeline nicely accommodated the expansion in time as well as the supplemental meetings. As such
the form and observations in the field work did not suffer from having to adapt to the reality of the HypR
PoC..
During the course of the project it was observable that key elements of the technical design were established
quite early and refined rather than redefined when revisited. On a couple of occasions what took focus was
challenges with progressing the project itself due to either problems with the subject application in relation
to the PoC scope or with resources being prioritized to other tasks than the PoC. Delays as a result of the
18
latter also meant that the PoC scope and design had to be recalled a couple of times during the project, which
did of course not create much additional value to observations.
4.4 Trustworthiness
In assessing the trustworthiness of how this case study was conducted and the results it yielded I must of
course consider the impact of my own involvement. In a strict study context my presence as an observer,
especially due to meetings being recorded, was noticed by the team a few times, appx. once every meeting.
This was noted, however, merely in context of participants restricting language expressions or refraining
from explicitly naming a certain person. Also my research perspective while participating will have affected
my observations. I was more observant to details than I would be under normal circumstances, and at two or
three occasions during the study I specifically asked the team to elaborate on an element of the discussion in
order to clarify it for study purposes.
There can be no doubt that having the role of Product Owner in an agile context, and even a manager in
Topdanmark context, my presence in the collaborative effort cannot be completely neutral. It is my belief,
however, that besides explicitly having mitigated challenges with the subject application, and by
perseverance kept on encouraging the team when they doubted the value of continuing, my impact on the
actual rethinking, defining and implementing the new release process itself did not significantly influence
the result besides having formally accepted the solution as valid. Throughout the observations I find
evidence that the ideas and decisions that went into the solution were coined and made by the collaborative
team itself.
5. Case description
This chapter describes the collaborative effort of rethinking release, and designing and implementing a
solution. A brief overview of the HypR PoC course of events is be presented supported by example artefacts
from the fieldwork.
Referring to the text book maturity model (figure 3.2) the PoC addresses two main areas. Regarding build
and integration it targets bringing the level of practice from Level 0 – Repeatable through Level 1 – Consistent to
Level 2 – Managed in which builds are kept stable and gathered metrics visible. The current target level for
19
testing would be Level 1 – Consistent in which (sufficient) automated tests are part of the development
process. By far most of the work to achieve this level lies within development itself to produce the actual
volume and quality of tests to be automated.
5.1 Case selection
In A&M the Agile Development & Testing team is responsible for the processes, tools, and infrastructure
supporting software development in Topdanmark. As illustrated below (figure 5.1), the HypR PoC was
conducted as a collaborative effort between this team from A&M and a development team in IT Claims. In
order to increase the probability of a success collaboration the development team was selected based on
interest, skills and having a good candidate application for continuous delivery. For simplicity the Agile
Development & Testing team from A&M will be referred to as the tools team in this report.
Figure 5.1 HypR PoC collaboration between A&M and IT Claims
The research project targeted the process and tools supporting the process of committing source code to
version control, building application artefacts, performing tests, and releasing applications into production.
This process is essential in bringing applications from all business areas from development to production.
The project involved both members of the Agile Development & Testing team (shortened to Tools team in
this report) and the development team responsible for the application used as a sample in the project.
Members of the Tools team included specialists in development and testing tools as well as software
engineering infrastructure such as the CI platform. The development team was headed by the architect
responsible for the application and included two developers working with all steps of coding, testing, and
supporting the application.
The specific application and team in question were selected due to the fact that they were frontrunners in
pushing for a more efficient development and release process, and the application was relevant to the case in
being relatively small and decoupled. PoC participants are listed in table 5.1.
20
Alias
Team
Role
Tim
Tools
CI and build infrastructure
Ulrik
Tools
CI and testing tools
Lasse
Tools
Development and testing tools
Dan
Development
Application responsible
Erik
Development
Developer
Viktor
Development
Developer
Anders
Architecture
Build infrastructure
Rasmus
Architecture
Development tools
Table 5.1 – PoC participants (anonymized), their teams and roles
All of these participants had been involved in pre-study discussions on various challenges and shortcomings
of the current process and tools, and suggestions of improvements pointing towards continuous delivery.
During the project, the build infrastructure specialist from the Tools team and the application responsible
from the development team were recurring characters while the other participants attended when possible
and relevant for their area of expertise.
5.2 Course of events
The timeline below (figure 5.2) illustrates the actual design meetings conducted during the PoC and
observed for the study in this project. Regular meetings were held throughout the course of events from
October through January, but as can be seen the last couple of meetings were at more irregular intervals. This
was due to delays resulting from prioritizing other work, but did not in itself impact the result of the PoC. In
order to evaluate the effort and result a review was held including a retrospective. Shortly after the
redesigned tool was released for the involved development team and potentially others to use.
At one point during the study (HypR #1½) the team brought in support from the Architecture team to
discuss and verify the proposed solution at that time. One of the architects had a unique knowledge of the
current build process and infrastructure since he and the infrastructure specialist from the tools team were
the primary designers and implementers of the existing TopUp build and release process about 10 years ago.
21
Figure 5.2: Project timeline
All meetings were recorded and observations noted (in Danish) using the template mentioned in the
methods chapter. Subsequently reflections relevant to the case were made (in English). Tables 5.2 shows an
(anonymized) fieldwork example from one of the observation sheets.
Time Min.
14:30
Observationer (da)
Reflections (en)
1:27 Tim [anonymized] præsenterer design idé
Temporary solution based on current setup
Initiated in Git repository (code projects)
Current setup: Git & Dimensions, TopUp
Jenkins points to Git and works on the code process
(CI)
Is PoC interesting: Yes, we have learned/are
CD:
learning a lot.
Dimensions: Main – Release – Prod
Baseline code from Git / RM ownership
5:17 Export (like today) onto Feature – Deliver to
main.
5:30 14:39 Høvlet ind på en feature
(integrationsbranch) deliveret (af PRM) til
Main -> Trigger automatisk Delivery
14:40 Udvider Feature med et CD-flag
alt. Opfinde en ny type request: "CD"
7:22 14:41 Kører pipelinen igennem [Jenkins]
14:41 Integration Git-Dimensions er ikke
særlig god – gør vi ikke noget ved her.
8:22 14:42 Vi bygger source, vi versionerer ikke
artefakter
8:58 14:42 CD og TopUp fungerer ikke godt
sammen. Det er TopUp, der er problemet
ift. at implementere CD effektivt
09:34 14:43 Realistisk inden jul: Whitelist over
moduler/projekter, som er CD-godkendt
9:50 14:44 Fx TopDoc eller PHP
10:49 14:44 Er der nogle filer udenfor whitelist
Feature ["CD"] Delivered to Main automatically
triggers Continuous Delivery.
- Equivalent to sign-off (Ready for production)
Main === Release (Automatic)
- pending manual Deploy
Versioning: Source vs. Artefacts
=> CD vs. TopUp will not work together
Problem: TopUp process, not Dimensions tool
- Dimensions as a tool (also) caused problems
Whitelist: CD approved applications
- Tree of depencencies...
Example: No COBOL
Table 5.2: Observations and Reflections example
22
Following meetings observations and reflections relevant to the case were then grouped with other obser vations on the same subject. From grouping a pattern of four distinct groups emerged, and were identified by
their main subjects: software engineering tools, target application architecture and considerations, development team process, and additional learnings for possible future consideration. An excerpt of this grouping
and patten exploration is shown in table 5.3.
Pattern / Categories
Obs.
#1
Relevant observations and reflections
Tools
Term: Continuous Delivery (CD)
Application candidates: TopDoc + Letters integ.
Collaboration impact at development team
Term: Release Pipeline
Add tools to existing setup (time constraint)
As far as we can with as little as possible
Release when we want, independent of others
Building release candidates rather than in prod.
Identification of "Main" as basis for CD
Regulation: Separation of concerns
Release control from RM to PO
Team control and responsibility
Importance of "continuous" principle
Value stream of pipeline
Use existing DSCM environments
Different infrastructure for future development
Base PoC on Dimensions (Git or eq. later)
Requires available release environment
Team: code, Maven scripts, func.+unit tests
App.
•
Process
Learnings
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Table 5.3: Pattern exploration example
6. Analysis
When analysing the observations, as described above, four main themes became visible (see table 5.3):
a) Considerations and decisions regarding tool design i.e. redesign to add functionality to the existing
tools in order to accommodate the purpose (=> Tools).
b) Impact on the application being developed in order to be able to take advantage of the redesigned
tool (=> Application).
23
c)
Realizations and predictions regarding the impact on the development process including the
opportunity for improved agile collaboration between the development team and their product
owner (=> Process).
d) Learnings for the organization both in general and regarding a potential future continuous delivery
solution (=> Learnings).
This chapter presents the tool design and implementation that manifests this PoC's very strict, limited by
circumstances, solution to rethinking release. It will show what it takes, or how little you can “get away
with” and still create a valuable contribution towards continuous delivery.
6.1 Tool design
Due to the time constraint of the PoC the team realized and decided that the design and implementation of a
continuous delivery approach in this context should be based on expanding existing infrastructure rather
than introducing new technology to add to or replace current components. For example they explicitly
decided that introducing Git to replace Dimensions would be out of scope. Figure 6.1 shows the original
design sketch.
Figure 6.1: HypR PoC design sketch
24
The team discussed different options and decided to concentrate the effort on when developed and tested
code is promoted to Main, automating the way through integration and release. From various perceptions of
"continuous delivery", guided by introductory sources on the subject [Phillips et al. 2014; Wooton et al. 2013],
the process would end at potentially shippable software in a Release state ready to be pulled into production
by release management upon request from the product owner.
6.1.1 Extension to user interface
The design of the solution was based on introducing a continuous delivery “check mark” to the existing
Feature in Dimensions. For the development team this means that they will identify the application as CDready (once) and then have the option of supplying the name of a dedicated Jenkins Job in a field, added as
an attribute to the Feature Request in this PoC (see figure 6.2), in order to take advantage of continuous
delivery.
Figure 6.2: "CD Jenkins Job" attribute added to Feature Request
6.1.2 Limitations
The PoC only supports a narrow subset of possible changes to the code base. Changes supported have to be
code only (no database changes) and atomic to the application as in dependencies are not allowed (fig. 6.3).
A detailed description of the solution, including a diagram providing an architecture perspective, was
published on the Topdanmark intranet. The translation of this detailed description (originally in Danish)
explains the solution at a technical level that targets existing and new users of the tool now supporting this
new continuous delivery option of the software development process (see figure 6.3 below).
25
Continuous Delivery in Dimensions - detailed description
A field 'CD Jenkins Job' has been added to the Feature Request in Dimensions. On the
Main BAS a specific CD job is created. Entering the name of this job into the field triggers
the CD process. The job name cannot be one previously linked to automatic creation based
on POM files being delivered to Main. Also this job cannot have upstream nor downstream dependencies.
When a Feature containing the right job name is delivered to Main in Dimensions, this
triggers the Jenkins job to be run on Main. This specially designed job must have the
notification plugin enabled with a post build notification via REST to the CD Dimensions
Bridge. The Bridge will then evaluate the result of the job, and if it is successful deliver the
original Feature directly to the Release branch in Dimensions. On the Release branch the
'ususal' Jenkins jobs will run and build code of the Feature once more. When this build is
completed successfully, a release candidate is ready.
Limitations:
•
Only the Tools team can configure jobs on the Main BAS Server (Creating the
special job must only be done the first time)
•
Only one CD job at a time can run on Main
•
Application changes using this CD concept:
- must be built and delivered using Maven via BAS servers
- cannot contain database changes
- cannot have build dependencies to other applications
(service dependencies are allowed)
- other applications cannot have build dependencies to this application
Figure 6.3: HypR PoC architecture and detailed description
6.1.3 The extent of the change
The existing Dimensions tools code base consists of about 10,000 lines of code. Implementing this solution
changed only about 70 lines of code. In addition to that the added CD Bridge (figure 6.3) consists of about
200 lines of code.
26
// Then deliver items
deliverItems(items , fromBranch , toBranch , deliverReport) ;
//Launch any Continuous Integration jobs
handleContinuousDelivery(toBranch , requests) ;
// Finally deliver request(s)
if ( mode .equals(DeliverModeEnum. DELIVER_MODE ))
{
for (RequestWrapper request : requests)
{
DLog. info ( "Completing " + request.getName()) ;
doDeliverMode(request , fromBranch , toBranch , deliverReport) ;
}
}
/**
* This method handles any Continuous Delivery requests
*
* @param toBranch the branch to be delivered to
* @param requests the delivered requests
*/
private void handleContinuousDelivery (Branch toBranch , List<RequestWrapper> requests)
{
if ( toBranch.isMain() )
{
String jobName = getJobName(requests) ;
if ( jobName != null && ! "" .equals(jobName.trim()) )
{
String url = "http://" + objectFactory. getBaseDatabase().toLowerCase() + "main/jenkins/job/" + jobName + "/build" ;
HttpClient httpClient = new DefaultHttpClient() ;
HttpPost httpPost = new HttpPost(url) ;
try
{
HttpResponse response = httpClient.execute(httpPost) ;
if (response.getStatusLine().getStatusCode() == 200 ||
response.getStatusLine().getStatusCode() == 201 )
{
DLog. info ( "Jenkins Continuous Delivery job started. StatusCode="
+response.getStatusLine().getStatusCode()) ;
}
else
{
DLog. info ( "Jenkins Continuous Delivery job could NOT be started.
StatusCode=" +response.getStatusLine().getStatusCode()+ " - Feature is now part of the
normal release..." ) ;
removeJobName(requests) ;
}
}
catch (IOException e)
{
DLog. error ( "Jenkins Continuous Delivery job could not be started. IO
Message: " +e.getMessage()) ;
removeJobName(requests) ;
}
}
}
}
Figure 6.4: Code example with added handleContinuousDelivery method.
27
The above example (figure 6.4) shows (in bold) the small extent of the code change needed to implement the
continuous delivery design. Basically one handleContinuousDelivery method is added handling the
request for continuous delivery by verifying that this happens on the Main branch, and that a valid jobName
is supplied. Basically this along with the CD Bridge forms the implementation.
6.2 Application impact
The application presented by the development team in this PoC had to undergo a couple of changes during
the project.
Quite early in the PoC the team faced a requirement involving a database schema update, and since this is
not supported by this continuous delivery solution, that requirement was threatening the completion of the
project within the time frame. Given priority, however, a clever workaround was devised, that allowed the
project to continue without much interruption. The database schema update was split in two, such that
additions to the schema were implemented separately in an ordinary release before the continuous delivery
changes, while deletions from the schema were held back until the PoC was completed. This way we were
able to accommodate both real world requirements and the continuous delivery PoC at the same time.
Also during the time of the PoC the application under work was split into two separate parts: one front-end
part and one back-end part. From an architecture perspective this separates functionality in and near the
user interface from handling database persistence. This split would allow the front-end to be released
separately from, and at a higher frequency using continuous delivery, than the back-end, which would still
have to follow the ordinary release cycles.
In addition to these direct application impacts the PoC also change the teams perception of tests. They
realised that test coverage for a successful run to be trusted sufficiently to release the application based on
that will present a new challenge. This means that the team will have to build and maintain a sufficient set of
unit tests, and balancing unit tests with higher level tests e.g. functional tests.
Finally during the PoC the team realised that in order to be automated, which is a requirement in continuous
delivery, database schema changes will eventually have to be versioned and handled just like code. Also
handling test data is expected to be a challenge, which we did not look further into during this project.
28
6.3 Process impact
The impact of the way the development team will work with the new release process also includes changes
in their interactions with their product owner and end users.
Continuous delivery will allow fro proper agile slicing of small vertical user stories. Due to the monthly
releases in TopUp, slicing and prioritizing user stories used to be more targeted towards composing a batch
of user stories that would fit the monthly capacity. The team explicitly mentioned the impact that the
opportunity of continuous delivery will have on the dialogue with their product owner in being able to
prioritize and release smaller, more targeted user stories.
This also means that the team will be able to take advantage of getting user feedback much earlier than
before and thus being able to respond to change more efficiently. This is true both after releasing but also as
early as when presenting potentially shippable increments in Release.
6.4 Learnings for the organisation
Throughout this project learnings were part of observations and reflections made as fieldwork. In addition a
final retrospective was held to facilitate a shared team reflection and evaluation continuing the participatory
aspect. Significant learnings for the combined team and the IT departments in general are listed here.
•
Despite the restriction in time and technology we were actually able to design and implement a very
narrow continuous delivery solution confirming that we could in fact achieve the goal of a
significantly higher frequency for software releases in Topdanmark. For now it is restricted to a very
small subset of applications, but is expected to serve as a basis for further development and
initiating experiences with working this way.
•
To expand this effort and create a consistent solution including other applications, we must involve
IT operations in order to ensure sufficient capabilities from Release into Production.
•
The technologies used to implement this PoC will not be sufficient to implement continuous delivery
for general use in Topdanmark. Since moving all existing applications to continuous delivery is not
realistic this implies the need to build a new process separate from TopUP implementing more
29
appropriate tools like distributed version control (e.g. Git) and versioning of binary artefacts to
support application dependencies across multiple versions “at the same time”.
•
There was general agreement that in implementing this as a collaborate effort together with one
primary target team brings essential focus to the task at hand. We were simply able to better scope
the effort, and descope unnecessary features, and customize the design and implementation
according to the needs required to support the specific application supplied by the team. Taking the
next and possible future applications into consideration was easy to avoid working like this.
•
As stated by one of the developers even the solution implemented in this PoC is already impacting
the way the development team works with development and user stories in collaboration with the
product owner representing their line of business.
In summary the final design and implementation proved to be significantly simpler than expected at the
outset. Realizing that the technological implementation needed to achieve this within the short time span
would not be able to support a future general solution, motivation was challenged, but in the end the
common perception is that we gained important learnings for our next step, while already being able to take
advantage of and gain experience with more frequent releases with select applications.
In addition we gained experience in how to address implementing continuous delivery. We learned that
close collaboration is a key aspect and helps target a successful effort. Another important element was that
the development team from the outset had substantial understanding and knowledge about the concepts
involved in continuous integration and delivery (see related work above). This is recognized as being a
prerequisite for an efficient and even successful adoption of the concept.
7. Discussion
Regarding software engineering a sound understanding of the aspects of continuous integration and
continuous delivery is key to introducing these subjects into an organization let alone implement solutions
based on them. One will have to navigate ambiguous definitions across different sources of information but
should anyway be able to extract the essence of the intentions behind the concepts.
Basic sources of information are important for basic information, but once one begins digging deeper into
30
the landscape of continuous engineering, great value of understanding various aspects, assessing the
organizational level, and identifying valuable activities are to be found using maturity models.
Collaboration is valuable
When reading about and discussing continuous software engineering often focus is on the technical aspects
and implementations of software development and release processes. This is perhaps understandable since
these support the extent of automation that is essential for the success building and maintaining infrastructure supporting these processes. Another important issue to consider, however, is the value of
collaboration. During this project we learned that joining forces in a collaborative team helped us focus the
scope of the effort and establish the right level of ambition for the solution. In retrospect though, we could
have been more efficient. Due to other priorities with both teams we did not manage to obtain quite the close
level of collaboration that had been envisioned at the outset. We have no doubt in the value of collaboration,
and I believe that having been able to “enforce” this even more, perhaps even by co-locating the teams,
would have increased efficiency in implementing and verifying the solution.
It takes less than you think
In the beginning of the HypR PoC most participants saw a considerable challenge in implementing what was
then perceived as sufficient infrastructure technology to support continuous delivery. Based on initial
perceptions of the range of technologies often discussed when addressing the subject, at least a few of the
team members did not find it realistic to produce a solution within the time frame given. In innovation,
however, restrictions often promote creative ideas, and thus the team managed to focus design and
implementation of the solution on a simple idea involving only the addition of one small component (the CD
Bridge) and very small changes to the existing infrastructure (additions to the code). This way the solution is
somehow in contrast with the general perception of continuous delivery infrastructure.
Small and smart automation
The landscape of tools supporting continuous software engineering consists of both piecing together
industry standard open source components and emerging large commercial frameworks from new and
existing vendors. One advice to take away from this PoC, however, is that based on your existing
infrastructure it is definitely worth considering to start introducing continuous integration and delivery as
concepts by expanding your existing process support with small and smart automation supplements rather
31
than thinking that a complete solution must initially be built from scratch.
Prepare to leave behind
That said if you are not a greenfield operation, but rather have a considerable amount of legacy software,
you must realise that not all software fits easily into the concepts of continuous software engineering. In
order to take advantage of continuous software engineering where it makes immediate sense and supports
business needs for frequent releases and fast feedback one should not hesitate implementing solutions
supporting these needs. For mature organizations this would generally mean that much software would still
need to be developed and released as usual and as such be left behind. Subsequently one could consider if
and how to move or evolve this software to fit into the continuous concepts.
Architecture impact
Software architecture must be considered in relation to continuous software engineering. A loosely coupled
component-based architecture fits better into continuous delivery than a monolithic architecture where the
whole application must be released as one. The target application in this PoC represents two examples of
how to create a fit for continuous delivery. For one the application is actually an extension of a large existing
system, but it is developed as a separate component. And the split between user interface and persistence
layer that was mentioned earlier further supports being able to take advantage of continuous delivery.
8. Conclusion
Rather than letting us be overwhelmed by the broad spectrum of continuous software engineering efforts
described in literature and maturity models, a targeted effort that makes a difference goes far and can
provide great value on its own. One thing is the technical solution of automating continuous delivery, but
also important is the organizational learnings and acknowledgement that arise from beginning to embrace
this improved way of working. Combining the tools and process aspects of continuous delivery is what truly
supports agile software development.
As show in this case study it is possible with small means to achieve a significantly higher release frequency,
and I can only encourage anyone to explore the options. Already having experiences with agile
development, continuous integration, and deployment pipelines are important shortcuts along with a strong
32
mindset of striving to automate the processes involved.
Quality is an attribute inherent in choosing continuous delivery as an approach building on the foundations
of agile development methods and continuous integration. All things equal this neither improves nor
decreases the quality of software produced this way but rather maintains the same level of quality as before.
The importance of a desired sufficient level of quality as a prerequisite for releasing software more often is
significant though. If not one will just repeat bad practices more frequently and produce bad software faster.
But all things are not equal, and I believe that the active decisions having to be made regarding software
when considering continuous delivery will in itself create attention to improving software quality.
The case study also demonstrated how a continuous delivery solution could be designed and implemented.
The solution builds on existing infrastructure and initiatives and emphasizes starting with experimenting
with small and smart additions to the existing tools rather than from the outset expecting to implement a
full-fledged framework from scratch. Conducting this tightly scoped PoC required creative thinking and we
managed to design and implement a solution that was significantly different from our initial perceptions of
what would be needed.
Future Research
This case study has inspired a small series of interesting candidates for future research:
•
Employing the experience of small-scale implementations of continuous delivery in additional case
studies in order to confirm or compare the results.
•
Studying the effect (process, architecture) of introducing continuous delivery in development teams.
•
Further digging into the different perceptions and definitions of, as well as relations between, the
various continuous * concepts and technologies in continuous software engineering.
•
Elaborating on the evolution of different continuous delivery maturity models, the relation between
them, or their effect when systematically applied to industry contexts.
•
Relating the experiences of this study to the need of supporting multiple development and release
cycles or rythms in the field of software ecosystems [Dittrich 2014] and/or the recent concept of
bimodal IT [Colella et al. 2014; Gartner 2014].
33
References
[Bass et al. 2014]
Len Bass, Ingo Weber, Liming Zhu. 2015. DevOps - A Software Architect's Perspective.
Draft chapters retrieved from SlideShare.net July-September 2014 via Australia's
Information Communications Technology Research Centre of Excellence (NICTA).
http://www.ssrg.nicta.com.au/projects/devops_book/
[Beck 1999]
Kent Beck. 1999. Embracing change with extreme programming. Computer 32, 10
(October 1999), 70-77
[Beck et al. 2001]
Beck et al. 2001. Principles behind the Agile Manifesto. Retrieved 2nd March 2015
from http://agilemanifesto.org/principles.html
[Bosch (Ed.) 2014]
Jan Bosch (Ed.). 2014. Continuous Software Engineering. Springer International
Publishing Switzerland.
[Bratteteig et al. 2013]
Bratteteig et al. 2013. Methods: organising principles and general guidelines for
Participatory Design projects. In Rutledge International Handbook of Participatory
Design. Ruthledge, New York, NY.
[Colella et al. 2014]
Heather Colella, Tina Nunno, Andy Rowsell-Jones, Mary Mesaglio. 2014. Three Steps
to Successfully Implementing Bimodal-Aware IT Governance. Gartner, Inc.
Retrieved 2nd March 2015 from http://www.gartner.com/document/2901217
[Dittrich 2014]
Yvonne Dittrich. 2014. Software engineering beyond the project – Sustaining
software ecosystems. Information and Software Technology 56, 11 (November 2014),
1436-1456.
[Fowler 2006]
Martin Fowler. 2006. Continuous Integration. Retrieved 2nd March 2015 from
http://www.martinfowler.com/articles/continuousIntegration.html
[Fowler 2013]
Martin Fowler. 2013. Continuous Delivery. Retrieved 2nd March 2015 from
http://martinfowler.com/bliki/ContinuousDelivery.html
34
[Gartner 2014]
Gartner Symposium. 2014. Evaluate Rate of Change, Required Governance and
Acceptable Risk. Presented at the Gartner Symposium, 9-13 November 2014,
Barcelona, Spain
[Humble and Farley
Jez Humble and David Farley. 2011. Continuous Delivery: reliable software releases
2011]
through build, test, and deployment automation. Addison-Wesley/Pearson Education,
Boston, MA.
[Humble and Russel
Jez Humble and Rolf Russel. 2009. The Agile Maturity Model – Applied to Building and
2009]
Releasing Software. ThoughtWorks Inc., San Francisco, CA.
[Humble et al. 2014]
Jez Humble, Joanne Molesky, and Barry O'Reilly. 2014. Adopt Lean Engineering
Practices. In Lean Enterprise – How High Performance Organizations Innovate at Scale.
O'Reilly Media, Sebastopol, CA.
[Jacobsen et al. 1999]
Ivar Jacobsen, Grady Booch, and James Rumbaugh. 1999. The Unified Software
Development Process. Addison-Wesley, Reading, MA.
[Minick 2014]
Eric Minick. 2014. Continuous Delivery Maturity Model. IBM urban{code}.
Retrieved 2nd March 2015 from
https://developer.ibm.com/urbancode/docs/continuous-delivery-maturity-model/
[Olsson et al. 2012]
Helena Holmström Olsson, Hiva Alahyari, and Jan Bosch. 2012. Climbing the
"Stairway to Heaven" – A Multiple-Case Study Exploring Barriers in the Transition
from Agile Development towards Continuous Deployment of Software.
38Th Euromicro Conference on Software Engineering and Advanced Applications (SEAA).
Cesme, Izmir, Turkey.
[Olsson and Bosch
Helena Holmström Olsson and Jan Bosch. 2014. Climbing the "Stairway to heaven":
2014]
Evolving From Agile Development to Continuous Deployment of Software. In
Continuous Software Engineering. Springer International Publishing Switzerland.
35
[Phillips et al. 2014]
Andrew Phillips, Michiel Sens, Adriaan de Jonge, and Mark van Holsteijn. 2014. An
IT Manager's Guide to Continuous Delivery. XebiaLabs, Boston, MA.
[Praqma unknown]
Unknown. Continuous Delivery Maturity Model. Praqma.
Retrieved 2nd March 2015 from
http://www.praqma.com/sites/default/files/img/cdmaturity_paper_5_0.pdf
[Rehn et al. 2013]
Andreas Rehn, Tobias Palmborg, and Patrik Boström. 2013. The Continuous Delivery
Maturity Model. InfoQ. Retrieved 2nd March 2015 from
http://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
[Robson 2002]
Colin Robson. 2002. Designs for Particular Purposes: Evaluation, Action and
Change. In Real World Research, 2nd Edition. Blackwell Publishing. Oxford, UK.
[Simonsen and
Jesper Simonsen and Toni Robertson. 2013. Participatory Design: An Introduction. In
Robertson 2013]
Rutledge International Handbook of Participatory Design. Ruthledge, New York, NY.
[Ståhl and Bosch 2014] Daniel Ståhl and Jan Bosch. 2014. Continuous Integration Flows. In Continuous
Software Engineering. Springer International Publishing Switzerland.
[Wootton et al. 2013]
Benjamin Wootton, Mark Prichard, and Andrew Phillips. 2013. Preparing for Continuous Delivery. DZone, Inc., Cary, NC
…
36

Rethinking Release

Transcription

Similar documents

Alessandro Biamonti

Innovation Management Study at Havaiannas.pptx

Installing And Configuring Windows Deployment

The Bermuda Atlantic Time

Press Futures - Full Automation, Part I

IT Governance for Agility

Schedule and Brochure

1D AND 3D SYSTEMS IN MACHINE AUTOMATION

2002 - POEA

Automated Staging for Built-to

Understanding the UK Low Carbon Energy Innovation System

Mobile App Testing