Sau bài viết giới thiệu về các thành phần của Azure Pipeline, chắc hẳn mọi người đã có đủ ý tưởng về cách các thành phần này hoạt động và kết hợp với nhau thế nào để tạo nên một giải pháp CI/CD.

Trong bài viết, mình sẽ trình bày về luồng hoạt động cũng như những key concepts mà chúng ta sẽ gặp phải trong quá trình build CI/CD. Bất kể là dùng YAML file hay UI mode, những khái niệm này cũng giúp chúng ta tiếp cận dễ dàng hơn với các tool CI/CD khác.

Vì sau tất cả, công cụ chỉ là hỗ trợ, kiến thức mới là thứ tạo nên DevOps.

1. Luồng của CI/CD nói chung:

Chúng ta đã biết, cơ bản thì CI/CD là một quá trình gồm những công việc như Build app → chạy test → Deploy app lên production. Những công việc này lại được thực hiện bằng những bước cụ thể và có tuần tự.

Lấy ví dụ như CI/CD của một dự án .NET: chúng ta phải checkout source code, chạy restore dependencies, build và publish dll lên server vân vân… Có thể thấy rằng, chúng ta đang gộp những bước nhỏ đó lại với nhau và gọi vắn tắt là BUILD, TEST, DEPLOY.

Nhưng thực chất, mỗi bước bên trong tùy vào loại project, tùy vào ngôn ngữ mà nó sẽ khác biệt, ví dụ một bước “echo” ra một câu log, chúng ta cũng gọi chung nó là build, gửi email thông báo đã deploy thành công, chúng ta vẫn đặt nó trong bước gọi là deploy.

2. Luồng của Azure Pipeline thì như thế nào?

Luồng của Azure Pipeline bắt đầu bằng một Trigger: Có thể là một commit lên nhánh nào đó của git, có thể là một ngày giờ cụ thể đã được cài đặt hoặc cũng có thể là ai đó trigger thủ công bằng tay.

Để phản ứng lại trigger đó, một pipeline được setup sẵn sẽ bắt đầu chạy. Pipeline sẽ chạy một bộ các công việc (Build, Test, Deploy) được group lại với nhau thành những Stage.

Thường ta sẽ dùng Stage để phân chia việc deploy lên nhiều môi trường khác nhau, ví dụ ta có thể quy định rằng chỉ khi deploy lên môi trường Blue thành công thì mới được deploy lên môi trường Green.

Một pipelines sẽ chứa nhiều stage khác nhau, ta có thể khiến chúng chạy tuần tự hoặc cùng lúc.

Stage chạy đồng thời

Stage chạy tuần tự

Trong mỗi stage sẽ chứa một hoặc nhiều Job. Trong mỗi job sẽ chứa những Task để làm những công việc cụ thể như restore dependencies, build app, echo log,….

Tại sao cần phải có Job để group nhiều Task lại với nhau mà không phải là mỗi Stage sẽ chứa các Task??

Để giải thích cho vấn đề này ta cần phân biệt 3 loại Job: Agent Job, Deployment Group Job, Agentless Job.

1. Agent Job:

Agent là 1 Resource (máy tính, hoặc docker container dùng để build / deploy app) được cài phần mềm (cài Agent) của Azure DevOps lên đó.

Agent Job nghĩa là một tập hợp các Task chạy trên agent. Giống như cách mà chúng ta remote SSH vào một con server và thao tác trực tiếp, thay vì vậy chung ta sẽ định nghĩa những bộ task (ví dụ như những câu lệnh) và agent sẽ thực hiện một cách tự động.

Agent Job chứa nhiều Task.

2. Deployment Group Job:

Trong bài viết giới thiệu về thành phần của Azure Pipeline. Mình có nhắc đến deployment group là tập hợp các Resource mà ta có thể dùng để deploy app.

Ta có thể chạy cùng một Job cho toàn bộ Resource bên trong Agent, hoặc gắn tag cho các Resource để phân loại và chỉ chạy Job trên những Tag cụ thể.

Ví dụ ta có QA deployment Group, UAT deployment group. Bên trong mỗi deployment group ta sẽ gắn tag cho những Resource nào dùng để deploy Web App và những Resource nào để deploy DB.

Gắn tags trên Deployment Group

3. Agentless Job:

Như cái tên cho thấy, agentless job là job mà không chạy trên agent nào cả ?. Ví dụ như Delay bao nhiêu phút để người deploy có thể check config, hoặc gọi API tới nơi nào đó.

Những agentless task

Stage chỉ tồn tại trên Release pipeline nếu dùng classic editor mode.

Vì Build nên được xem là một stage duy nhất do mục đích của nó là tạo ra đầy đủ artifacts để luôn sẵn sàng cho việc deploy.

3. Kết luận:

• Một trigger sẽ kêu gọi pipeline chạy
• Một pipelines gồm nhiều stage, mỗi stage sẽ chứa nhiều job
• Job sẽ chạy trên agent nào đó, hoặc có thể là agentless
• Deployemnt group Job dùng để deploy trên nhiều môi trường khác nhau.
• Job chứa nhiều Task, là những câu lệnh được tạo sẵn dùng để hoàn thành công việc nào đó.

Tới đây hi vọng mình đã cung cấp được một bức tranh toàn cảnh cho luồng đi của Azure Pipeline. Bài viết dùng hình ảnh minh họa của Classic Editor mode vì nó trực quan và dễ dàng hơn cho việc hiểu. Nhưng tất cả những khái niệm này có thể dễ dàng áp dụng cho YAML file.