2. In the values.yaml file, under the ‘service’ part in the file, along the default ports, a port for  ‘switch1’ is defined, which will be  picked up by service.yaml file. 3. Finally, in order to see the fields in the helm charts WebUI for the newly added port the  values-metadata.yaml file should also define ‘switch1’ port as a parameter. service: type: NodePort webuiPort: 7600 serverlistenerPort: 7800 serverlistenerTLSPort: 7843 switch1: 9010 service switch-1: __metadata: label: "switch-1 port" description: "This is port number example" type: "number" immutable: true required: false 7.5 Continuous Integration and Continuous Delivery Pipeline  using IBM App Connect V11 architecture This section looks at IBM App Connect in the context of CI/CD pipelines. The theory of CI/CD  pipelines is explored, building upon 4.2.10, “C ontinuous Integration and Continuous Delivery  and Deployment” on page 97, leading into an example pipeline that displays a practical  implementation.  When we talk about modernization of your Integrations, an important topic for discussion is  "pipelines". Many IT organizations already have an existing Pipeline implementation in one  form or another. These pipelines can be triggered either manually or automatically and as an  input it could serve a source or a whole BAR file. When discussing Pipelines, the key terminology we use, is defined below:  We see three main stages in running your Pipeline when you use IBM App Connect V11  architecture. As the Pipeline structure usually involves multiple products, this stage is expected to cover  your development work towards building the components required. For example, as shown in  the figure below, the development work might include creation of MQ resources, BAR files  and packaging. Further, Secrets and Docker files are being developed, and finally Helm Chart  development and storing. Figure 7-28 on page 466. Development Chapter 7. Field notes on modernization for application integration  465 GLYPH<SM590000> Continuous Integration (CI) – this refers to bu ild and test, whenever new code is available.  This type of testing will show if the new code has had any impact or broken anything.  GLYPH<SM590000> Continuous Delivery (CD) – this phase refers to when we are pushing to production from a  continuous stream. After the code is decided to be ready, it is pushed to production.  GLYPH<SM590000> Continuous Deployment – similar to the continuous delivery, this outlines an automated  push to production, without human intervention, where the code is stopped going live only  by failed tests.