Bài viết này sẽ tổng hợp và phân loại trigger pipeline cũng như giới thiệu về tính ứng dụng của chúng theo cách dễ dàng tiếp cận nhất với người bắt đầu làm quen với Azure Pipelines để làm nền tảng cho quá trình tự nghiên cứu và đọc document của bạn sau này.
Tại sao cần phải tổng hợp lại?
Trong quá trình làm việc với Azure DevOps, mình nhận thấy rằng documentation của microsoft về mục triggers khá đầy đủ và cụ thể khi dùng làm tài liệu tra cứu. Tuy nhiên nó chưa đủ tổng quát, và cách phân loại có lẽ vẫn chưa được rõ ràng, gây nhiều khó khăn cho người mới tiếp cận.
1. Trigger là gì?
2. Filter trong trigger:
Filter là cách giới hạn trigger dựa trên tiêu chí nào đó. Tùy vào loại trigger mà có thể sẽ có những filter này mà không có những filter khác:
- Branch filter: Trigger trên những branch nào?
- Tag filter: Chỉ trigger build pipeline khi commit có git tag nhất định hoặc chỉ trigger release khi có build tag nhất định?
- Stage filter: Trigger một pipeline mới nếu những stages trong một pipeline khác chạy thành công (complete).
- Path filter: Chỉ trigger khi những file nào thay đổi (include/exclude).
- Artifacts filter: Trigger khi những artifact nào được thay đổi.
resources:
pipelines:
- pipeline: string
source: string
trigger:
branches:
include: [ string ]
exclude: [ string ]
stages: [ string ]
tags: [ string ]Cấu trúc khi viết filter trong YAML.
Related Post
Đối với CLassic UI Mode, filter sẽ rất dễ dàng xác định khi đã biết được tên gọi và ý nghĩa của từng loại filter ở trên.
3. Phân loại triggers:
Mình sẽ phân loại trigger dựa trên loại pipeline:
3.1 Trigger của Build Pipeline:
1. Continuous Integration Trigger (CI trigger):
Trigger này được kích hoạt khi có bất kì thay đổi được áp dụng trên branch đã chọn.
Khai báo bằng YAML:
trigger: - master - releases/*
Setup bằng Classic UI:
Chọn Build Pipeline → tab Triggers → Continuous integration → Enable continuous Integration.
Ta có thể thấy CI trigger có thể áp dụng Branch filter và Path filter
2. Pull Request Validation trigger (PR trigger):
Trigger này sẽ kích hoạt trên branch muốn được merge vào branch chỉ định. Ví dụ ta config PR trigger cho develop và một branch feature là feature/new-feature đang muốn merge vào develop. Khi đó, build pipeline sẽ chạy trên branch feature để xem build có thành công hay không trước khi được merge.
Khai báo bằng YAML (Source là GitHub):
pr:
branches:
include:
- master
- developSetup bằng Classic UI:
Chọn Build Pipeline → tab Triggers → Pull request validation -> Enable
3. Scheduled trigger:
Như tên gọi, scheduled trigger dùng để hẹn giờ cho việc build:
YAML:
schedules:
- cron: string # Dùng cron syntax để hẹn giờ
displayName: string # Tên của trigger
branches:
include: [ string ]
exclude: [ string ]
always: boolean # Mặc định là false: không trigger nếu không có commit mới.Classic UI:
Chọn Build Pipeline → tab Triggers → Scheduled
4. Build Completion Trigger (Pipeline Completion Trigger đối với YAML)
Trigger một pipeline khác khi pipeline ban đầu đã hoàn thành.
YAML:
resources:
pipelines:
- pipeline: string # đặt tên cho resource pipeline hiện tại
source: string # tên pipeline, trigger dựa trên pipeline này
trigger:
stages: # stage
- PreProduction # Tên stage ví dụ
- Production # (Stage filter bao gồm 2 stages, tức là sau khi 2 stage này complete thì
# pipeline này sẽ được trigger, bất kể pipeline kia còn stage nào khác)
Để ý rằng ở trigger này, ta có thể dùng Stage Filter
Classic UI:
Chọn Build Pipeline → tab Triggers → Build Completion:
3.2 Trigger của Release Pipeline (Classic Mode)
1. Continuous Deployement Trigger (CD trigger)
Trigger deploy mỗi khi một bản build thành công và tạo ra artifacts mới:
2. Pull Request Trigger (PR trigger)
Giống với PR trigger ở Build Pipelines, trigger này sẽ run khi có một pull request merge vào và tạo ra artifacts mới.
Để ý có một dùng thông báo màu vàng ở dưới cùng của ảnh, bởi vì trigger này phải được dùng chung với option PR deployment của Stage trigger
3. Scheduled Trigger:
Trigger deploy tự động vào một thời gian xác định.
Ta có một option Only Schedule… : không trigger nếu không có artifact mới. Tick chọn nếu muốn always re-deploy.
4. Stage trigger
Đây là trigger cụ thể cho từng Stage của Release Pipeline và có bao gồm rất nhiều options:
- Select trigger: Trong trường hợp tạo release và chọn Automate Deploy thì option này quyết định khi nào thì stage này được deploy.
- Artifact filter
- Schedule: hẹn giờ để auto deploy cho stage này
- PR Deployment: Dùng kết hợp với Pull Request trigger để auto deploy khi merge PR.
- Pre-deployment approval: Khi stage này được deploy, cần phải xin Approve thì mới được tiếp tục.
- Deployment Queue settings: Tương tự với batch changes của CI trigger. Ta có thể chọn chỉ deploy commit mới nhất.
3. Lời kết
Hi vọng bài viết đã mang lại cái nhìn tổng quát về triggers trong Azure DevOps. CHEER
