Skip to main content

Application CICD Pipeline Settings

The CICD pipeline of an application is an essential procedure to actualize a developing application. By leveraging the pipeline code template set in the profile, applications can configure and execute the build and deployment pipeline with just a few selection actions, without writing separate pipeline code. Additionally, automated build and deployment pipelines can be configured using scheduling or webhook features.

Application CICD Pipeline Overview​

Application CICD Pipeline

To configure the CICD pipeline of an application, access to the application tab in the profile detail page:

Pipeline status: Provides execution status of the application's pipeline. The currently deployed version is provided.

Click on pipeline status to lead to the application's pipeline detailed/settings page as mentioned in the next section.

Pipeline running time: Displays the elapsed time since the last execution of the pipeline and information on the user who executed it.

note

Pipeline execution is initiated by a user, webhook, or schedule.

Application CICD Pipeline Execution and Settings

The pipeline's settings and execution can be performed on the pipeline detail page as below:

Execution tab: frequently used for pipeline execution of the application.

Setting tab: for setting the pipeline code regarding pipeline usage registration.

Application CICD Pipeline Settings​

Project Settings, Registry, and Webhook​

Profile setting

Display basic information necessary for deploying microservices. It indicates which namespace of the Kubernetes cluster is used and where the profile's configuration is stored.

  • Cluster: Endpoint address of the cluster targeted for deployment specified in the profile.
  • Namespace: The namespace targeted for deployment specified in the profile.
  • Project Development Source Location: The git repository where the deployment configuration specified in the profile is stored.
  • Microservice Configuration Path: The path within the Git repository where the microservice's configuration is stored.
  • Pipeline Code File Path: The path where the code for deployment is stored. (Currently, only Jenkins files are stored)
Image and webhook settings

Define the registry and naming, tagging rules for storing the container image of the microservice. The image registry must be predefined under Project Configuration Management. Modifiable items become savable when edited, and changes are applied only upon saving.

  • URL (Registry URL): The address of the container image registry for storing container images.
  • User ID (Registry User ID): Account name with the authority to store container images.
  • Image Project: Defines the project name to use in the container image registry. By default, it is created to match the project name. The project must be pre-created in the registry; otherwise, stored images will not be properly saved.
  • Image Name: Created by default following the rule ProfileName/MicroserviceName .
  • Image Tag: The 0.1 version is created by default.
  • Automatic Patch Version Creation
    • If “Automatically create patch version” is set, the patch version increases by 1 in the format of Semantic Versioning (e.g., 0.1.1, 0.1.2).
    • If “User inputs patch version during build” is selected, the patch version must be manually specified each time the pipeline is executed, and automated features like schedule/webhook cannot be used.
  • Image Tag auto-generated Suffix: If an additional suffix is required other than the image tag version, input a text string like the 'dev' in 0.1.0- dev, excluding the hyphen.
  • Webhook Handling Policy during Build: AMDP can execute build and deployment upon receiving webhooks from the git repo where the application source is store
    • Sequential execution after build completion: Executes all webhook requests sequentially.
    • Execution of only the last request after build completion: In cases where development occurs frequently, building every git push delays the deployment of the final version. To avoid this, you can skip intermediate version builds and build only the latest version pushed to git.
    • The webhook feature cannot be used if the automatic patch version creation is not set
Pipeline Usage Registration

The code templates defined in the CICD tab of the profile are displayed here. The pipeline code compatible with the specified framework of the application is shown: â‘  Additional Settings: Additional parameters applicable only to this microservice can be defined. If different values are needed for each microservice using the common pipeline code, this feature can be utilized for customization

  • Pipeline Code: Displays the name and role of the pipeline code.

  • Additional Parameters: Appears for Tekton or Jenkins pipelines. Specifies the values to be replaced by parameters in the code. In the case of Tekton, using undefined pipeline parameters will cause an error.

  • Additional Workspaces: Appears for Tekton pipelines. Specifies Tekton workspaces dynamically injected if needed.

  • Executable Script: For pipeline codes with a script role, an area for adding and editing scripts is displayed. The script from the template is shown by default, and it can be customized for this microservice.

    • To write a script exclusively for this microservice, not in the template, click Add New Script and enter the script name and code.
    • To load a script code from the template, click Add Script from Template.

② The view button provides access to the web address offered by the pipeline tool. For correct usage, the Addon service must be properly configured. Refer to Template Management and Cloud Native Service Management to appropriately set up Jenkins,Tekton, and ArgoCD Addon services.

③ Register the actual pipeline code to be used. Only one pipeline code can be registered for use during the build. To deactivate, click the checkbox again.