kiến thức Continous Integration - P1 - What is it?

CI là gì?

Nói tới CI, thứ đầu tiên mọi người thường nghĩ đến là cái pipeline: jenkin, travis, circle...
Và khi dự án dùng một trong các toolchain đó, các bạn liền viết vào CV là có kinh nghiệm với CI/CD.

Điều đó cũng khó mà trách được khi amazon còn để ngay cái nút "Try AWS CodePipeline" ngay trên phần định nghĩa mà.



Mình không nói định nghĩa đó sai, nhưng nó thường sẽ khiến người ta hiểu nhầm mức độ quan trọng của cái pipeline trong CI.
Mình đoán cũng bởi họ cần marketing cho cái AWS Codepipeline.

Mình thấy một định nghĩa khác cho bạn một cái nhìn đúng đắn hơn đến từ wikipedia:
"In software engineering, continuous integration is the practice of merging all developers' working copies to a shared mainline several times a day."

Ok, định nghĩa trên nói rằng mình cần merge code vào main branch nhiều lần mỗi ngày, và nó chả có gì liên quan đến toolchain cả.

Tại sao cần CI?

Có một khái niệm trong phát triển phần mềm tên: "blackout period".
Khái niệm này nói đến khoảng thời gian khi hai developer làm việc trên 2 branch tách biệt nhau,công việc kéo dài dẫn đến hai developer không biết người kia làm gì trong khoảng thời gian đó.
Nếu blackout period càng dài thì khả năng merge vào bị conflict càng cao. Còn tệ hơn nữa nếu như chính requirement cũng bị conflict dẫn đến phải kéo BA vào để giải quyết.
CI sinh ra để rút ngắn blackout period xuống còn vài giờ.

Nhưng, bạn biết main branch là gì chứ? Nó là branch mà thường chỉ có lead được merge vào, vậy thế quái nào CI lại muốn mọi người merge vào branch đó nhiều lần mỗi ngày?
Ai sẽ đứng ra review các PR?

Hiện thực hóa CI

Mới nghe thì hơi khó khăn, nhưng đến lúc thử làm thì đúng là khó khăn thật, khó vãi nồi.
Hiện thực hóa CI là một quá trình gian khổ và chịu chơi của dự án.
Trước hết, ta phải tưởng tượng ra thế giới khi dùng CI và cố để đạt được nó nhé:
- Không có PR
- Main branch mở cho cả làng, ai cũng có thể commit trực tiếp vào
- Có một release branch cho mỗi lần release

Tất nhiên sẽ có nhiều team vẫn cần PR, nhưng với mình flow này là hợp lý nhất. Mình sẽ nói về PR trong CI sau.

Có lẽ ai đọc xong các gạch đầu dòng trên thì cũng hoang mang và muốn chửi mình:

• Ko có PR thì sao review code?
• Ko có PR lỡ một ông nào đó code bậy rồi sao?
• Rồi muốn release nhưng code có bug thì sao mà rollback để release các feature khác?

Đừng lo, bởi vậy CI mới khó, và mình sẽ hướng dẫn các bạn cách giải quyết.
Để làm được các gạch đầu dòng trên thì trước hết phải có test: khi code của bạn có các test xịn, nó giúp mình tin tưởng bạn hơn một phần nào đó.
Khi mình tin bạn thì mình mới cho bạn commit lên main chứ.

Nhưng thế nào mới được gọi là test xịn? Không có PR thì ai sẽ kiểm chứng các test đó có xịn hay không?
Mình sẽ trình bày cái này trong bài tiếp theo: TDD

Hôm nay chỉ mới viết được nhiêu đây thôi, các bạn chờ bài tiếp theo nhé. Khi ra bài mới mình sẽ comment và update link trong bài này.
Trong thời gian chờ, các bạn cứ tiếp tục tìm hiểu theo các gạch đầu dòng đó và từ khóa TDD nhé.
Mới lúc nãy vừa phỏng vấn một bạn Technical lead và bạn ý bảo là CI là cái toolchain, nên mình quyết định sẽ viết bài này cho đàng hoàng.
Mục đích của mình là giúp dev Việt Nam có một cái nhìn đúng đắn về CI, qua đó có được những mục tiêu tiếp theo để tìm hiểu, trở thành world-class developer đồ ... Yeah.

Phần 2: https://voz.vn/t/continous-integration-p2-tdd.500547/

hoctrokha said:

CI là gì?

Nói tới CI, thứ đầu tiên mọi người thường nghĩ đến là cái pipeline: jenkin, travis, circle...
Và khi dự án dùng một trong các toolchain đó, các bạn liền viết vào CV là có kinh nghiệm với CI/CD.

Điều đó cũng khó mà trách được khi amazon còn để ngay cái nút "Try AWS CodePipeline" ngay trên phần định nghĩa mà.

View attachment 1025949

Mình không nói định nghĩa đó sai, nhưng nó thường sẽ khiến người ta hiểu nhầm mức độ quan trọng của cái pipeline trong CI.
Mình đoán cũng bởi họ cần marketing cho cái AWS Codepipeline.

Mình thấy một định nghĩa khác cho bạn một cái nhìn đúng đắn hơn đến từ wikipedia:
"In software engineering, continuous integration is the practice of merging all developers' working copies to a shared mainline several times a day."

Ok, định nghĩa trên nói rằng mình cần merge code vào main branch nhiều lần mỗi ngày, và nó chả có gì liên quan đến toolchain cả.

Tại sao cần CI?

Có một khái niệm trong phát triển phần mềm tên: "blackout period".
Khái niệm này nói đến khoảng thời gian khi hai developer làm việc trên 2 branch tách biệt nhau,công việc kéo dài dẫn đến hai developer không biết người kia làm gì trong khoảng thời gian đó.
Nếu blackout period càng dài thì khả năng merge vào bị conflict càng cao. Còn tệ hơn nữa nếu như chính requirement cũng bị conflict dẫn đến phải kéo BA vào để giải quyết.
CI sinh ra để rút ngắn blackout period xuống còn vài giờ.

Nhưng, bạn biết main branch là gì chứ? Nó là branch mà thường chỉ có lead được merge vào, vậy thế quái nào CI lại muốn mọi người merge vào branch đó nhiều lần mỗi ngày?
Ai sẽ đứng ra review các PR?

Hiện thực hóa CI

Mới nghe thì hơi khó khăn, nhưng đến lúc thử làm thì đúng là khó khăn thật, khó vãi nồi.
Hiện thực hóa CI là một quá trình gian khổ và chịu chơi của dự án.
Trước hết, ta phải tưởng tượng ra thế giới khi dùng CI và cố để đạt được nó nhé:
- Không có PR
- Main branch mở cho cả làng, ai cũng có thể commit trực tiếp vào
- Có một release branch cho mỗi lần release

Tất nhiên sẽ có nhiều team vẫn cần PR, nhưng với mình flow này là hợp lý nhất. Mình sẽ nói về PR trong CI sau.

Có lẽ ai đọc xong các gạch đầu dòng trên thì cũng hoang mang và muốn chửi mình:

• Ko có PR thì sao review code?
• Ko có PR lỡ một ông nào đó code bậy rồi sao?
• Rồi muốn release nhưng code có bug thì sao mà rollback để release các feature khác?

Đừng lo, bởi vậy CI mới khó, và mình sẽ hướng dẫn các bạn cách giải quyết.
Để làm được các gạch đầu dòng trên thì trước hết phải có test: khi code của bạn có các test xịn, nó giúp mình tin tưởng bạn hơn một phần nào đó.
Khi mình tin bạn thì mình mới cho bạn commit lên main chứ.

Nhưng thế nào mới được gọi là test xịn? Không có PR thì ai sẽ kiểm chứng các test đó có xịn hay không?
Mình sẽ trình bày cái này trong bài tiếp theo: TDD

Hôm nay chỉ mới viết được nhiêu đây thôi, các bạn chờ bài tiếp theo nhé. Khi ra bài mới mình sẽ comment và update link trong bài này.
Trong thời gian chờ, các bạn cứ tiếp tục tìm hiểu theo các gạch đầu dòng đó và từ khóa TDD nhé.
Mới lúc nãy vừa phỏng vấn một bạn Technical lead và bạn ý bảo là CI là cái toolchain, nên mình quyết định sẽ viết bài này cho đàng hoàng.
Mục đích của mình là giúp dev Việt Nam có một cái nhìn đúng đắn về CI, qua đó có được những mục tiêu tiếp theo để tìm hiểu, trở thành world-class developer đồ ... Yeah.

Click to expand...

2 cái ý bôi đậm kia là công ty nào đấy thớt? Thấy lạ quá vậy?

Dev comit code vào branch khác, tạo PR rồi CI chạy test trên PR đó trước khi merge vào vẫn được mà?

Sent from Samsung SM-G973F using vozFApp

tdat00 said:

2 cái ý bôi đậm kia là công ty nào đấy thớt? Thấy lạ quá vậy?

Dev comit code vào branch khác, tạo PR rồi CI chạy test trên PR đó trước khi merge vào vẫn được mà?

Sent from Samsung SM-G973F using vozFApp

Click to expand...

Mình ko tiết lộ tên C.ty/dự án đc. Mình chỉ có thể nói mình đã làm 2 dự án kiểu đó rồi.
Dev commit vào các branch khác rồi chạy test trên CI hay là chạy test trên local cũng được, nhưng quan trọng là dev phải có quyền tự merge vào main chứ k đợi review từ lead.
Và khi merge vào main thì cũng đã có CI chạy trên main rồi mà.
Đồng thời việc merge vào main phải diễn ra nhiều lần trong ngày.

Hóng bài tiếp

hoctrokha said:

Mình ko tiết lộ tên C.ty/dự án đc. Mình chỉ có thể nói mình đã làm 2 dự án kiểu đó rồi.
Dev commit vào các branch khác rồi chạy test trên CI hay là chạy test trên local cũng được, nhưng quan trọng là dev phải có quyền tự merge vào main chứ k đợi review từ lead.
Và khi merge vào main thì cũng đã có CI chạy trên main rồi mà.
Đồng thời việc merge vào main phải diễn ra nhiều lần trong ngày.

Click to expand...

Oh, các công ty tôi làm không cần lead review, nhưng phải có peer review (1 người tron team) thì mới merge được vào main branch. Còn các test branch (để deploy lên test server) thì khỏi cần review.

Sent from Samsung SM-G973F using vozFApp

đặt gạch hóng bác viết tiếp, như nghe đoạn CI lý tưởng là ko cần PR để review code, ai cũng merge được hơi hoang mang thật

tdat00 said:

2 cái ý bôi đậm kia là công ty nào đấy thớt? Thấy lạ quá vậy?

Dev comit code vào branch khác, tạo PR rồi CI chạy test trên PR đó trước khi merge vào vẫn được mà?

Sent from Samsung SM-G973F using vozFApp

Click to expand...

Thím có thể mô tả rõ hơn khúc này được ko?
Ví dụ: Tôi làm chưc năng A:
Tôi tách ra 1 nhánh A từ nhánh Develop. Tôi code xong rồi, test ngon lành ở máy Dev rồi -> tạo PR vào nhánh Develop thì có phải CI nó chạy ở nhánh Develop sau khi merge vào ko?
Vì đọc như Thím viết thì tôi đang nghĩ là CI sẽ chạy trên nhánh A tôi tách ra khi tôi tạo PR. Nhờ Thím giải thích chi tiết giùm chỗ này

TomorrowNeverDie said:

Thím có thể mô tả rõ hơn khúc này được ko?
Ví dụ: Tôi làm chưc năng A:
Tôi tách ra 1 nhánh A từ nhánh Develop. Tôi code xong rồi, test ngon lành ở máy Dev rồi -> tạo PR vào nhánh Develop thì có phải CI nó chạy ở nhánh Develop sau khi merge vào ko?
Vì đọc như Thím viết thì tôi đang nghĩ là CI sẽ chạy trên nhánh A tôi tách ra khi tôi tạo PR. Nhờ Thím giải thích chi tiết giùm chỗ này

Click to expand...

Chính xác là nó sẽ chạy trên latest code ở nhánh A của thím đấy.

Ví dụ như cái PR này nhé https://github.com/microsoft/vscode/pull/143498

Thím sẽ thấy CI nó chạy 7 cái jobs trước khi merge từ branch của developer (weartist:main) vào branch chính (microsoft:main)

tdat00 said:

Chính xác là nó sẽ chạy trên latest code ở nhánh A của thím đấy.

Ví dụ như cái PR này nhé https://github.com/microsoft/vscode/pull/143498

Thím sẽ thấy CI nó chạy 7 cái jobs trước khi merge từ branch của developer (weartist:main) vào branch chính (microsoft:main)

View attachment 1026211

Click to expand...

Cảm ơn Thím đã chia sẻ, cty tôi chạy Jenkin mà ko biết cấu hình khúc này thế nào Tôi toàn cho anh em Dev Lead review PR rồi cho vào develop -> merge vào nhánh test để Jenkin nó chạy nhánh test kia. Thím có từ khóa nào để hướng dẫn cấu hìnfh với Jenkin để tự động test nhánh A như trường hợp trên kia ko? Hoặc hệ thống nào tương tự, cảm ơn Thím

nghe thớt nói làm mình nghĩ tới trunk-based development, không biết có phải ko . Có hẳn 1 web viết về nó https://trunkbaseddevelopment.com/, mình cũng chưa gặp ngoài đời bao giờ, hóng thớt chia sẻ

TomorrowNeverDie said:

Cảm ơn Thím đã chia sẻ, cty tôi chạy Jenkin mà ko biết cấu hình khúc này thế nào Tôi toàn cho anh em Dev Lead review PR rồi cho vào develop -> merge vào nhánh test để Jenkin nó chạy nhánh test kia. Thím có từ khóa nào để hướng dẫn cấu hìnfh với Jenkin để tự động test nhánh A như trường hợp trên kia ko? Hoặc hệ thống nào tương tự, cảm ơn Thím

Click to expand...

Lâu lắm rồi em không xài Jenkins, nhưng thím có thể tìm hiểu 2 cơ chế này nhé:

* Filter trước khi chạy CI: chỉ trigger CI job ở 1 số action nhất định, với Github Actions thì nó hỗ trợ rất nhiều actions: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request Nếu jenkins không hỗ trợ thì thím có thể đặt branch theo convention như pr/abcdef... hay run_ci/abcdef...

* Các branch kia phải được tạo từ HEAD của nhánh main để đảm bảo nó luôn có latest code của nhánh main. Trong quá trình review lâu ngày thì bảo anh em thường xuyên pull code về cho nó cập nhật. Còn trong job CI thì cứ lấy HEAD của nhánh dev thôi.

tdat00 said:

Lâu lắm rồi em không xài Jenkins, nhưng thím có thể tìm hiểu 2 cơ chế này nhé:

* Filter trước khi chạy CI: chỉ trigger CI job ở 1 số action nhất định, với Github Actions thì nó hỗ trợ rất nhiều actions: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request Nếu jenkins không hỗ trợ thì thím có thể đặt branch theo convention như pr/abcdef... hay run_ci/abcdef...

* Các branch kia phải được tạo từ HEAD của nhánh main để đảm bảo nó luôn có latest code của nhánh main. Trong quá trình review lâu ngày thì bảo anh em thường xuyên pull code về cho nó cập nhật. Còn trong job CI thì cứ lấy HEAD của nhánh dev thôi.

Click to expand...

Tks Thím, để tôi nghiêm cứu thêm

NoOneKnowMe said:

nghe thớt nói làm mình nghĩ tới trunk-based development, không biết có phải ko . Có hẳn 1 web viết về nó https://trunkbaseddevelopment.com/, mình cũng chưa gặp ngoài đời bao giờ, hóng thớt chia sẻ

Click to expand...

Về cơ bản chính là nó, khi ta thêm test + pipeline vào thì nó là CI.
Trunkbased development là tiền đề để hiện thực CI.
Nói theo định nghĩa thì là vậy, nhưng thực ra khi đã hiện thực được trunkbased thì cơ bản là ta cũng đã có CI rồi.
Thành thử mình nghĩ tách biệt hay ko tách biệt 2 thằng này ra cũng k quan trọng lắm.
Quan trọng là phải làm cho rõ khái niệm về CI đã.

TomorrowNeverDie said:

Cảm ơn Thím đã chia sẻ, cty tôi chạy Jenkin mà ko biết cấu hình khúc này thế nào Tôi toàn cho anh em Dev Lead review PR rồi cho vào develop -> merge vào nhánh test để Jenkin nó chạy nhánh test kia. Thím có từ khóa nào để hướng dẫn cấu hìnfh với Jenkin để tự động test nhánh A như trường hợp trên kia ko? Hoặc hệ thống nào tương tự, cảm ơn Thím

Click to expand...

Bên mình xài jenkins, cũng có case nhánh nào build nhánh đó và xử lý bằng cách sử dụng generic webhook của jenkins
Trong json gitlab post sang jenkins có branch name, thím có thể móc ra tên branch để đưa vào kịch bản build hoặc parse cái json notify của gitlab làm gì tùy thích, bên mình phải làm trò này do cần thông tin trong git commit message cho quá trình deploy

schaffer513655 said:

Bên mình xài jenkins, cũng có case nhánh nào build nhánh đó và xử lý bằng cách sử dụng generic webhook của jenkins
Trong json gitlab post sang jenkins có branch name, thím có thể móc ra tên branch để đưa vào kịch bản build hoặc parse cái json notify của gitlab làm gì tùy thích, bên mình phải làm trò này do cần thông tin trong git commit message cho quá trình deploy

Click to expand...

Cảm ơn Thím đã chia sẻ. Cho mình hỏi thêm, bên Thím có dùng Gitflow ko?

TomorrowNeverDie said:

Cảm ơn Thím đã chia sẻ. Cho mình hỏi thêm, bên Thím có dùng Gitflow ko?

Click to expand...

Ko bác ạ

Để tăng phần thú vị, 1 thằng lười, đụt và dốt như tôi muốn nêu thêm vài vấn đề sau để xem chủ thớt từng giải quyết thế nào hoặc trả lời tại sao (dựa trên #1)

• Code Review có cần thiết hay ko? Đọc theo #1 thì ko hiểu ý này. “Ko có PR thì sao review code” thì ko rõ nghĩa là ko xài PR để review code hay ko review code hoàn toàn.
• Định nghĩa test xịn? Ai đóng vai trò trong việc đảm bảo test nào xịn test nào ko?
• Quản lý chất lượng test như thế nào? Ví dụ: test có thể bất ngờ chuyển trạng thái từ ổn định sang flaky (nhất là integration/end-to-end) thì làm sao - ko phải broken test nhé?
• Thêm 1 bài toán là khi code base to, lượng test nhiều, đặc biệt khi số lượng code được dàn trải ra nhiều services khác nhau thì làm sao quyết định test nào được chạy trên CI?
• Số lượng commits nhiều nhưng CI chạy lâu, giải quyết thế nào? Tức nếu CI chạy test quá lâu thì dần dần nó sẽ trở thành bottleneck.
• Làm sao duy trì được tính ổn định ở trunk/mainline/master? Tức bad commit có thể block trunk/mainline/master mà mọi người vẫn cắm đầu cắm cổ push. Làm sao để developer viết code trên stable base commit (sau khi rebase) mà ko bị ảnh hưởng bởi bad commit? Làm sao deal với bad commit?
• Bad test thì sao? Làm cách nào để tránh bad test blocking trunk/mainline/master?
• Tại sao cần release branch? Tại sao ko dùng main branch? Source control như git chẳng hạn có thể tag commit dưới dạng “release xyz”.
• Patching process. Về lý thuyết thì nếu có continuous deployment pipeline thì sẽ liên tục ra version mới, lúc đó patching là fix forward nếu good commit trên trunk/mainline được deploy (hoặc rollback deployment đợi good commit ra). Nhưng nếu có release branch thì patching là 1 vấn đề khác.

Còn nhiều lắm nhưng đần và đụt như tôi thì biết ko nên hỏi nhiều. Bấy nhiêu để mong được học hỏi thêm và tạo điều kiện cho các thím khác biết thêm nếu chưa gặp.

code4sticker said:

Để tăng phần thú vị, 1 thằng lười, đụt và dốt như tôi muốn nêu thêm vài vấn đề sau để xem chủ thớt từng giải quyết thế nào hoặc trả lời tại sao (dựa trên #1)

• Code Review có cần thiết hay ko? Đọc theo #1 thì ko hiểu ý này. “Ko có PR thì sao review code” thì ko rõ nghĩa là ko xài PR để review code hay ko review code hoàn toàn.
• Định nghĩa test xịn? Ai đóng vai trò trong việc đảm bảo test nào xịn test nào ko?
• Quản lý chất lượng test như thế nào? Ví dụ: test có thể bất ngờ chuyển trạng thái từ ổn định sang flaky (nhất là integration/end-to-end) thì làm sao - ko phải broken test nhé?
• Thêm 1 bài toán là khi code base to, lượng test nhiều, đặc biệt khi số lượng code được dàn trải ra nhiều services khác nhau thì làm sao quyết định test nào được chạy trên CI?
• Số lượng commits nhiều nhưng CI chạy lâu, giải quyết thế nào? Tức nếu CI chạy test quá lâu thì dần dần nó sẽ trở thành bottleneck.
• Làm sao duy trì được tính ổn định ở trunk/mainline/master? Tức bad commit có thể block trunk/mainline/master mà mọi người vẫn cắm đầu cắm cổ push. Làm sao để developer viết code trên stable base commit (sau khi rebase) mà ko bị ảnh hưởng bởi bad commit? Làm sao deal với bad commit?
• Bad test thì sao? Làm cách nào để tránh bad test blocking trunk/mainline/master?
• Tại sao cần release branch? Tại sao ko dùng main branch? Source control như git chẳng hạn có thể tag commit dưới dạng “release xyz”.
• Patching process. Về lý thuyết thì nếu có continuous deployment pipeline thì sẽ liên tục ra version mới, lúc đó patching là fix forward nếu good commit trên trunk/mainline được deploy (hoặc rollback deployment đợi good commit ra). Nhưng nếu có release branch thì patching là 1 vấn đề khác.

Còn nhiều lắm nhưng đần và đụt như tôi thì biết ko nên hỏi nhiều. Bấy nhiêu để mong được học hỏi thêm và tạo điều kiện cho các thím khác biết thêm nếu chưa gặp.

Click to expand...

Bằng những kiến thức đụt của tôi thì

• Code Review optional. Cty tôi có cơ chế code thấy cần thì review, còn code đã có test cover khi push lên PR thì khỏi review, tất cả dc quản lý = tag bên source control và đã có process định nghĩa sẵn
• Test xịn theo ý fence là gì? Tui ko hỏi lại mà cái chữ xịn nó rất mơ hồ, test nó có automtion test, manual test, rồi có function/ non-functional. Mỗi loại trong đó lại cover từng thứ khác nhau, xịn hay là test dc viết tốt và nhanh. Cơ chế CI là phải fast feedback, tức test muốn "xịn" phải nhanh , 9 xác, và ko bị flaky. Muốn đạt dc test "xịn" phải dàn trải test theo từng layers theo mô hình test kim tự tháp, và cái này tuỳ thuộc exp của testers cũng như của project .
• Việc đảm bảo test có xịn hay ko ko phải là của cá nhân mà của toàn team, ví dụ test bạn viết nhanh mà như loằn thì khi lên CI team nó ko biết failed do đâu hay test này làm cái gì thì rõ là "dỏm"
• Muốn quản lý test tốt phải tính efforts để maintain, cái này do team fence . Test đang từ ngon sang flaky thì phải xem lại rất nhiếu thứ: trace history, trace system, trace network, trace libraries, trace logs.... Nếu bị vậy phải có cơ chế isolate mấy cái flaky tests này, và ko cho run trong suite nữa cho tới khi fix , vì nếu CI như vậy sẽ ảnh hưởng mood của team, ảnh hưởng results, ảnh hưởng độ tin cậy của test
• Vẫn là vấn đề liên quan tới team và project bạn. Team / Project bạn phải tự đánh giá dc tests hiện tại thông qua những KPI như thời gian chạy, độ chính xác, có flaky hay ko rồi hẵn tính tới chuyện nên improve thế nào khi code base càng bự.
• vẫn như trên, khi fence đã phát hiện điều này thì phải plan với team cách improve thôi. Nguyên tắc là test nếu càng phát hiện dc càng sớm càng tốt, mà muốn phát hiện sớm thì phải test từ trong trứng, tức là codebase phải có unit test và những cái test trên UI có thể làm dc với unit test thì nên làm, ko nên đợi tới tầng UI / E2E mới làm vì cost nó sẽ cao và efforts fix cũng sẽ cao . Test trên UI chạy càng lâu hơn so với test dưới nó là integration và E2E

Tạm thế đã, nhiều quá mấy câu sau reply sau

toi5 said:

Bằng những kiến thức đụt của tôi thì

• Code Review optional. Cty tôi có cơ chế code thấy cần thì review, còn code đã có test cover khi push lên PR thì khỏi review, tất cả dc quản lý = tag bên source control và đã có process định nghĩa sẵn
• Test xịn theo ý fence là gì? Tui ko hỏi lại mà cái chữ xịn nó rất mơ hồ, test nó có automtion test, manual test, rồi có function/ non-functional. Mỗi loại trong đó lại cover từng thứ khác nhau, xịn hay là test dc viết tốt và nhanh. Cơ chế CI là phải fast feedback, tức test muốn "xịn" phải nhanh , 9 xác, và ko bị flaky. Muốn đạt dc test "xịn" phải dàn trải test theo từng layers theo mô hình test kim tự tháp, và cái này tuỳ thuộc exp của testers cũng như của project .
• Việc đảm bảo test có xịn hay ko ko phải là của cá nhân mà của toàn team, ví dụ test bạn viết nhanh mà như loằn thì khi lên CI team nó ko biết failed do đâu hay test này làm cái gì thì rõ là "dỏm"
• Muốn quản lý test tốt phải tính efforts để maintain, cái này do team fence . Test đang từ ngon sang flaky thì phải xem lại rất nhiếu thứ: trace history, trace system, trace network, trace libraries, trace logs.... Nếu bị vậy phải có cơ chế isolate mấy cái flaky tests này, và ko cho run trong suite nữa cho tới khi fix , vì nếu CI như vậy sẽ ảnh hưởng mood của team, ảnh hưởng results, ảnh hưởng độ tin cậy của test
• Vẫn là vấn đề liên quan tới team và project bạn. Team / Project bạn phải tự đánh giá dc tests hiện tại thông qua những KPI như thời gian chạy, độ chính xác, có flaky hay ko rồi hẵn tính tới chuyện nên improve thế nào khi code base càng bự.
• vẫn như trên, khi fence đã phát hiện điều này thì phải plan với team cách improve thôi. Nguyên tắc là test nếu càng phát hiện dc càng sớm càng tốt, mà muốn phát hiện sớm thì phải test từ trong trứng, tức là codebase phải có unit test và những cái test trên UI có thể làm dc với unit test thì nên làm, ko nên đợi tới tầng UI / E2E mới làm vì cost nó sẽ cao và efforts fix cũng sẽ cao . Test trên UI chạy càng lâu hơn so với test dưới nó là integration và E2E

Tạm thế đã, nhiều quá mấy câu sau reply sau

Click to expand...

Đáng lẽ ra tôi nên đặt số. Chơi gạch đầu dòng khó theo quá. Sorry thím

• Code Review là optional cũng là 1 ý thú vị. Nhưng nếu chỉ cần test để khỏi review thì mình cũng khá ấn tượng. Đơn giản ví dụ khi code base đủ to thì ownership sẽ bị mập mờ. Code Review ko đơn thuần chỉ là bắt bớ cơ bản mà cũng là 1 quy trình để có hơn 1 người biết mình làm gì, có thêm 1 góc nhìn để đảm bảo mình ko nhầm nhọt hoặc hớ hênh và cũng là cách để dạy ngược lại người reviewer. Thím nào làm Google rồi thì vô comment phát coi review dễ ko
  
• Tôi đồng ý chữ “xịn” rất mơ hồ. Vì đó là trong #1 nên tôi mới hỏi. Vì bản thân tôi lười, đần và đụt nên phải hiểu chứ ko suy đoán được.
• Cơ chế quản lý test là 1 đề tài thú vị, đặc biệt khi nói về CI. Nó đáng để có bài riêng.
• Trong bài toán code base to, đặc biệt là deployment pipeline khác nhau thì việc quyết định tests nào nên chạy là rất phức tạp. Có ko ít các công ty phải có nguyên 1 org để giải quyết vấn đề này chứ ko đơn giản.
• Chuyện các loại test khác nhau ko phải cái tôi muốn đề cập. Tôi chỉ muốn nêu ra đó là 1 vấn đề thực tế về việc tăng hiệu xuất chạy CI. Ví dụ: ko phải CI chạy trên tất cả các commit. Nó có thể chia ra test siêu nhanh chạy trên mọi commit trước khi merge (unit tests chẳng hạn). Nguyên group commit (sau khi có trunk deployment) thì sẽ được test bởi UI/end to end tests, vân vân. Đây có lẽ cũng cùng với ý của thím. Test quá nhiều nữa thì có cơ chế chạy test bởi nguyên worker fleet vân vân. Hoặc thậm chí những test quá chậm thì có cơ chế chạy riêng để flag issue chẳng hạn. Mục đích câu hỏi là để bài viết của chủ thớt sẽ đầy đủ hơn cho anh em chứ tôi đần và đụt thì biết đâu là đúng
  

code4sticker said:

Đáng lẽ ra tôi nên đặt số. Chơi gạch đầu dòng khó theo quá. Sorry thím

• Code Review là optional cũng là 1 ý thú vị. Nhưng nếu chỉ cần test để khỏi review thì mình cũng khá ấn tượng. Đơn giản ví dụ khi code base đủ to thì ownership sẽ bị mập mờ. Code Review ko đơn thuần chỉ là bắt bớ cơ bản mà cũng là 1 quy trình để có hơn 1 người biết mình làm gì, có thêm 1 góc nhìn để đảm bảo mình ko nhầm nhọt hoặc hớ hênh và cũng là cách để dạy ngược lại người reviewer. Thím nào làm Google rồi thì vô comment phát coi review dễ ko
  
• Tôi đồng ý chữ “xịn” rất mơ hồ. Vì đó là trong #1 nên tôi mới hỏi. Vì bản thân tôi lười, đần và đụt nên phải hiểu chứ ko suy đoán được.
• Cơ chế quản lý test là 1 đề tài thú vị, đặc biệt khi nói về CI. Nó đáng để có bài riêng.
• Trong bài toán code base to, đặc biệt là deployment pipeline khác nhau thì việc quyết định tests nào nên chạy là rất phức tạp. Có ko ít các công ty phải có nguyên 1 org để giải quyết vấn đề này chứ ko đơn giản.
• Chuyện các loại test khác nhau ko phải cái tôi muốn đề cập. Tôi chỉ muốn nêu ra đó là 1 vấn đề thực tế về việc tăng hiệu xuất chạy CI. Ví dụ: ko phải CI chạy trên tất cả các commit. Nó có thể chia ra test siêu nhanh chạy trên mọi commit trước khi merge (unit tests chẳng hạn). Nguyên group commit (sau khi có trunk deployment) thì sẽ được test bởi UI/end to end tests, vân vân. Đây có lẽ cũng cùng với ý của thím. Test quá nhiều nữa thì có cơ chế chạy test bởi nguyên worker fleet vân vân. Hoặc thậm chí những test quá chậm thì có cơ chế chạy riêng để flag issue chẳng hạn. Mục đích câu hỏi là để bài viết của chủ thớt sẽ đầy đủ hơn cho anh em chứ tôi đần và đụt thì biết đâu là đúng
  

Click to expand...

Để tui nói nốt ý của cái chấm cuối. Khi system ngày càng scale rồi thì codebase sẽ scale, resoures scale, test cũng sẽ phải scale, và khi nó đã scale thành microservices rồi thì lại khác. Lúc này tests trên CI muốn cho hiệu quả phải plan rất nhiều, và dựa trên yếu tố :

• Unit test : Tốt nhất nên chạy hết
• Integration Test: Chạy cover ở mức call service A, xài db của service B => Tất nhiên test này tốn time , và cũng phải pick theo flow và heo project
• Contract test : Vì nếu microservices thì tests cái này cover E2E tốt hơn và giảm thiểu efforts test ở layer E2E
• UI/E2E Test : Cái này phải consider những case thực sự wan trọng, và đáp ứng dc flow của users

Bên Google nó chia thành 3 loại, small , medium và large tests. Nguyên tắc của nó là large tests chỉ bao nhiêu nhiêu đó tôi quên cmnr nhưng nó làm vậy để để đủ tests cho mọi layers và ko exceed quá số test cho 1 layer