Pipeline status definition
In a DevOps team, the actions of compilation, integration, testing and deployment are materialized by a release pipeline with some steps that may remain manual for some time. Beyond the technical points related to automation, a pipeline often raises the question of deployment automation when it is set up. Indeed, if the mission of Developers is to create added value and ideally innovation, Operations must provide a stable environment for Customers. This difference in viewpoint is called the "wall of confusion" [Kawaguchi 2020] and a DevOps culture must be established in the team to resolve this conflict. To do this, the pipeline must have separate assembly, release, and execution stages to maximize deployability and reassure even the most wary teams [Wiggins 2017].
The separation of stages gives both the transparency needed for acceptance of each stage, but also a good modularity of delivery activities to streamline these activities and better orchestrate deliveries. Moreover, when the pipeline state is represented in terms of each stage with the one that would be blocked, it is an excellent Andon to mobilize teams around the health of the deployment process [Larman 2010] [Humble 2011].
Visualizing the pipeline and its history improves the transparency of the delivery process. The more visible the process, the more stakeholders can collaborate around the delivery, the smoother the delivery flow can be [Kotter 2014] and with increased confidence in what is sent to production. This trust then supports the automation of deployment operations. It is from this collaborative perspective that the concept of ChatOps was created. The term is said to be due to Jesse Newland, but its origin is said to date back to 2008 at GitHub [Moustier 2020]. ChatOps makes visible the collective work and discussions around the actions launched to the bots [Kim 2016] [Moustier 2020].
Influence on the testing maturity
The sharing component in DevOps is essential, which is why it is found in some definitions of DevOps [Buchanan 2021]. In terms of practice, this sharing can start simply with X-Team oriented Developers, but what is intended by creating DevOps teams is the merging of the Dev ecocycle with the Ops ecocycle; the bridge built by an X-Team orientation is a first step in this merging of activities.
The implementation of this pipeline is done around a pilot project with a minimalist definition of the pipeline. Developers often start automating the delivery process and gradually integrate elements from the Ops culture that are gradually automated by the Developers. The more Devs become familiar with Ops' concerns, the more they pay attention and participate to them. A complementary way to grow the pipeline is to use the Value Stream Mapping (VSM) technique [Rother 1999]. This mapping consists of taking measurements on each step of the pipeline and using these values to identify where to optimize the delivery process. SAFe proposes three values [Martin 2014]:
- Process Time (PT): this is the time spent to implement the solution
- Lead Time (LT): this is the time spent processing and waiting between processes
- Percent Complete and Accurate (%C&A)
It is then possible to identify the steps to be improved where it seems necessary, knowing that the actions can be classified according to several categories [Monden 1994]:
- those that must be eliminated, because they do not add any value ("Non-Value Adding operations" - NVA)
- those that consume energy but are necessary ("Necessary but Non-Value Adding operations" - NNVA)
- those that convert raw material into added value for the customer ("Value-Adding operations" - VA)
According to this classification, the aim is to eliminate actions that do not add value and are not necessary, but also to identify possible bottlenecks according to the theory of constraints.
Agilitest’s standpoint on this practice
It is to note that system testing from Graphical User Interfaces (GUI) is subject to low response time; therefore, it is recommended to dissociate code commits-based delivery pipeline launches from GUI scripted tests, especially when a certain amount of scripts are made available.
Having a multiple pipeline policy is made to avoid Developers experiencing long lasting commits [Rady 2011] [Larman 2010] [Ambler 2012] [Humble 2011]. Indeed, when commits last more than 10 minutes, Devs do less commits which increases the integration time and flow issues. This policy becomes much more critical when the pipeline embeds multiple kinds of tests, since some of them may last several hours or even days...
To discover the whole set of practices, click here.
To go further
- [Ambler 2012] : Scott W. Ambler et Mark Lines - « Disciplined Agile Delivery - a Practitioner’s guide to Agile Software Delivery in the Enterprise » - IBM Press - 2012 - ISBN: 978-0-13-281013-5
- [Buchanan 2021] : Ian Buchanan - accessed in SEP 2021 - “CALMS Framework” - https://www.atlassian.com/devops/frameworks/calms-framework
- [Humble 2011] : Jez Humble et David Farley - « Continuous Delivery » - Addison Wesley - 2011 - ISBN-13: 978-0-321-60191-9
- [Kawaguchi 2020] : Stephen Kawaguchi - FEB 2020 - “The Wall of Confusion”- https://levelup.gitconnected.com/the-wall-of-confusion-623057a4dd26
- [Kim 2016] : Gene Kim, Jez Humble, Patrick Debois et John Willis - « The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations » - IT Revolution Press - 2016 - ISBN: 978-1942788003
- [Kotter 2014] : John P. Kotter - « Accelerate: Building Strategic Agility for a Faster Moving World » - Harvard Business Review - 2014 - ISBN-13: 978-1625271747 - voir https://www.academia.edu/29979777/XLR8_-_Book_Report ou https://www.leadersleague.com/en/news/accelerate-building-strategic-agility-for-a-fastermoving-world
- [Larman 2010] : Craig Larman, Bas Vodde - « Practices for Scaling Lean & Agile Development - Large, Multisite, and Offshore Product Development with Large-Scale Scrum » - Addison-Wesley - 2010 - ISBN-13: 978-0-321-63640-9
- [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7
- [Wiggins 2017] : Adam Wiggins - « The Twelve Factor App » - 2017 - https://12factor.net/fr/