Display pipeline status

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

Agilitest can be easily integrated notably to Jenkins, GitLab or Azure pipeline as a pipeline orchestrator. All those orchestrators provide some visual feedback on the delivery process.

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.

‍