[Music] Welcome to Automated Build and Deployment
(Delivery Pipeline). After watching this video, you will be able to: Describe the Delivery Pipeline build and deploy processes. By default, Continuous Delivery automatically runs the build and deploy tasks when you commit changes to the Git repository (repo). The pipeline also features a "run" icon that runs a stage of the pipeline but only runs on committed code or builds, depending on the stage. You can access the Continuous Delivery toolchain by clicking View toolchain from the Application Details page. To navigate to the pipeline, click its tool card in the toolchain overview page. Jobs are Build, Deploy, and Test. They are grouped into stages. You can change the order of the stages by dragging and dropping. You can also configure a stage to include more than one job of the same type. For example, you can have a stage that features one Build job, one Deploy job, and two Test jobs. In fact, the pipeline is completely customizable. You can explicitly state what branch should trigger a build, you can run various tests when a pipeline is triggered, and you can tell the pipeline to create output in each stage and pass it to the next stage in the pipeline. The default build script is simple: It takes the files that are pushed to the remote Git repo and triggers IBM Cloud to build your code in the server runtime. You can customize the settings for the server runtime through the manifest.yml file. After the Build stage completes successfully, the Deploy stage runs. Delivery Pipeline deploys the built files to your IBM Cloud space. By default, Delivery Pipeline runs the Build stage when a client pushes any change to the master branch in the remote Git repo. If you do not want to automatically push your changes to your IBM Cloud account, change the State trigger setting to Run jobs only when this stage is run manually. You can extend the features of the Build stage by adding jobs. Although by default Delivery Pipeline names this stage configuration the Build stage, you can also add Test or Deploy jobs. Builder Type supports types like: Simple, Ant, Container Registry, Gradle, Grunt, IBM Globalization Pipeline, Maven, npm : For Node.js projects, NPM Build, and Shell Script. The simple build type runs the appropriate build scripts for your runtime environment. For example, the IBM SDK for Node.js runtime resolves modules that your application requires. In this example, you create a deploy task that pushes the application to a specific space on IBM Cloud. Two Deployment types are available: Cloud Foundry deploys applications to Cloud Foundry servers. This is the default type for the Deploy job. Kubernetes provides a set of default deployment patterns for containers on Kubernetes Cluster. Containers are typically built by using the Docker Builder. Your application is pushed to the development space in your organization. You can also publish your application to your staging and production spaces. You can customize the Cloud Foundry command-line interface commands (cf CLI) in the deploy process in the Deploy Script section. The default deploy action is equivalent to running the cf push command from the CLI. You can add custom shell script commands. Here ${CF_APP refers to the application name. Tests are usually run in the Build stage as shown here. The first job fetches the code. The second job runs the test. If all the tests pass, the Deploy stage is run. The following Tester types are available: Simple, Advanced Tester, DevOps Insights Gate, IBM AppScan Dynamic Analyzer, IBM Security Static Analyzer, Sauce Labs, And Vulnerability Adviser. The default settings for the pipeline are two stages. For Build stage: Input that triggers this stage is whenever a change is pushed to Git. Jobs are Simple Builder Type. For Deploy stage: The input that triggers this stage is as the Build stage is completing successfully: it takes as input the build artifacts that were produced from the Build stage and jobs are deploying the application to IBM Cloud. In this example, all jobs in both the Build and Deploy stages were completed successfully. The LAST EXECUTION RESULT pane shows that the application was successfully deployed to your IBM Cloud account and that the application is running on IBM Cloud. You can also check the build logs in the JOBS pane in the Build Stage column, the deploy logs in the JOBS pane in the Deploy Stage column, and the runtime logs from the LAST EXECUTION RESULT pane also in the Deploy Stage column. You can clone the Deploy stage and deploy the application to any number of spaces in your IBM Cloud account by clicking the settings wheel icon on top of Deploy Stage and selecting Clone Stage. In this video, you learned: Continuous Delivery automatically runs the build and deploy tasks when you commit changes to the Git repo. Jobs, which are Build, Deploy, and Test, are grouped into stages and you can customize Delivery Pipeline in many ways.
