Piping for Continuous Delivery
(2015) In LU-CS-EX 2016-02 EDA920 20161Department of Computer Science
- Abstract
- Many companies today are transforming their development process by leaving an old-fashioned
one, like the waterfall model, behind and instead aiming for a modern process like Scrum that can
keep up with today’s rapid market changes and reduce time to market lag. These companies are
often aiming to become more agile and with this comes a need for short release cycles in order to get
fast feedback and fulfill the first principle of the agile manifesto; ”Our highest priority is to satisfy
the customer through early and continuous delivery of valuable software.” [1]. The name Continuous
Delivery has emerged from the agile community and it defines the principle of frequent deliveries in
a highly automated manner. However, the delivery... (More) - Many companies today are transforming their development process by leaving an old-fashioned
one, like the waterfall model, behind and instead aiming for a modern process like Scrum that can
keep up with today’s rapid market changes and reduce time to market lag. These companies are
often aiming to become more agile and with this comes a need for short release cycles in order to get
fast feedback and fulfill the first principle of the agile manifesto; ”Our highest priority is to satisfy
the customer through early and continuous delivery of valuable software.” [1]. The name Continuous
Delivery has emerged from the agile community and it defines the principle of frequent deliveries in
a highly automated manner. However, the delivery process can probably not be automated as it is,
architectural design decisions needs to be made so that the release management process is sustainable
and reliable before it is automated. This case-study is based on a company whose delivery process
fails to keep up with the clients’ need for rapid upgrades. By localizing the main barriers in today’s
process and discussing possible improvements we will end up in an alternative release management
process which is more rapid and further also lives up to the clients’ needs. By creating a prototype of
a possible new delivery pipeline where some of the suggested improvements are implemented, this can
be used as a proof of concept before implemented at scale. The biggest challenge with the new release
management comes with a new branching strategy which requires major re-structuring for all nodes
in the deployment pipeline. This requires quite some work but it is however important to emphasize
how important these changes are for the sustainability of the future. Applying modern practices such
as Continuous Integration and Infrastructure as Code found in the Continuous Delivery communities,
will facilitate the automation of the release management process and further lead to more frequent
deliveries. (Less)
Please use this url to cite or link to this publication:
http://lup.lub.lu.se/student-papers/record/8567728
- author
- Klingberg, Jonathan LU
- supervisor
-
- Lars Bendix LU
- organization
- course
- EDA920 20161
- year
- 2015
- type
- H3 - Professional qualifications (4 Years - )
- subject
- keywords
- Continuous Delivery (CD), delivery pipeline, agile development, Infrastructure as code, DevOps
- publication/series
- LU-CS-EX 2016-02
- report number
- LU-CS-EX 2016-02
- ISSN
- 1650-2884
- language
- English
- id
- 8567728
- date added to LUP
- 2016-01-29 12:06:23
- date last changed
- 2016-01-29 12:06:23
@misc{8567728, abstract = {{Many companies today are transforming their development process by leaving an old-fashioned one, like the waterfall model, behind and instead aiming for a modern process like Scrum that can keep up with today’s rapid market changes and reduce time to market lag. These companies are often aiming to become more agile and with this comes a need for short release cycles in order to get fast feedback and fulfill the first principle of the agile manifesto; ”Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” [1]. The name Continuous Delivery has emerged from the agile community and it defines the principle of frequent deliveries in a highly automated manner. However, the delivery process can probably not be automated as it is, architectural design decisions needs to be made so that the release management process is sustainable and reliable before it is automated. This case-study is based on a company whose delivery process fails to keep up with the clients’ need for rapid upgrades. By localizing the main barriers in today’s process and discussing possible improvements we will end up in an alternative release management process which is more rapid and further also lives up to the clients’ needs. By creating a prototype of a possible new delivery pipeline where some of the suggested improvements are implemented, this can be used as a proof of concept before implemented at scale. The biggest challenge with the new release management comes with a new branching strategy which requires major re-structuring for all nodes in the deployment pipeline. This requires quite some work but it is however important to emphasize how important these changes are for the sustainability of the future. Applying modern practices such as Continuous Integration and Infrastructure as Code found in the Continuous Delivery communities, will facilitate the automation of the release management process and further lead to more frequent deliveries.}}, author = {{Klingberg, Jonathan}}, issn = {{1650-2884}}, language = {{eng}}, note = {{Student Paper}}, series = {{LU-CS-EX 2016-02}}, title = {{Piping for Continuous Delivery}}, year = {{2015}}, }