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

• 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âu thì phải fix, phải xem lại tests mình viết thế nào, chạy có phù hợp ngữ cảnh ko. ví dụ validate cái field chỉ cho nhập số mà phải lên tận UI test để check là ko dc rồi , vì unit test đã check dc rồi , nhá . Chạy test quá lâu có thể ko phải là vấn đề của execution, mà vấn đề time wait để chờ CI nó feedback lại cho devs sau khi push PR thôi, vấn đề quá lâu này giải quyết = cách plan lại tests nào cần chạy, chạy lúc nào, chạy vào thời điểm nào blah blah
  
  
• 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?
  => Khi tests của fence đã ổn áp thì lập tức notify thằng dev mày commit code mà static/lint tests báo code style tè le, tests thì failed abc là ngăn dc liền. Còn việc branch nhiều test failed mà vẫn còn cho phép commit là thuộc phạm vi thằng quản lý cái branch đó ko block lại hay review lại. Muốn deal với bad commit thì: 1. thằng dev phải test bên local nó, 2. tests phải tin cậy, 3. khi commit lên phải tests, 4. tests liên tục
  
  
• Bad test thì sao? Làm cách nào để tránh bad test blocking trunk/mainline/master?
  => Bad test theo fence là gì, là tests ko hợp, tests validate tùm lum, tests chạy lâu, tests ko đúng hay gì . Test có bad hay ko là do vấn đề viết test
  
  
• 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”.
  => Theo model câu hỏi ở trên chắc là xài trunk development model rồi , nên mới có 1 main branch. Mà model này phải đảm bảo test nhiều.
  
  
• 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.
  => Ko rõ fence hỏi gì xD
  
  Tóm lại là tui trả lời chung chung vậy thôi chứ ko details hết dc )

Lâu thì phải fix, phải xem lại tests mình viết thế nào, chạy có phù hợp ngữ cảnh ko. ví dụ validate cái field chỉ cho nhập số mà phải lên tận UI test để check là ko dc rồi , vì unit test đã check dc rồi , nhá . Chạy test quá lâu có thể ko phải là vấn đề của execution, mà vấn đề time wait để chờ CI nó feedback lại cho devs sau khi push PR thôi, vấn đề quá lâu này giải quyết = cách plan lại tests nào cần chạy, chạy lúc nào, chạy vào thời điểm nào blah blah

Click to expand...

Khi tests của fence đã ổn áp thì lập tức notify thằng dev mày commit code mà static/lint tests báo code style tè le, tests thì failed abc là ngăn dc liền. Còn việc branch nhiều test failed mà vẫn còn cho phép commit là thuộc phạm vi thằng quản lý cái branch đó ko block lại hay review lại. Muốn deal với bad commit thì: 1. thằng dev phải test bên local nó, 2. tests phải tin cậy, 3. khi commit lên phải tests, 4. tests liên tục

Click to expand...

1. Chạy test trên commit trước khi merge vào trunk/mainline. Việc bắt được bad commit tại thời điểm này là tốt nhất, nhưng không bao giờ đảm bảo 100% luôn bắt được. Feedback cho dev tại thời điểm này dễ nhất (như kiểu static/lint/unit tests/fast integration tests vân vân)
2. Chạy test trên trunk/mainline sau khi merge. Việc bắt bad commit tại thời điểm này là không khó (đồng ý với điểm số 4 - chạy tests liên tục sẽ giúp tóm được đám này chẳng hạn), nhưng việc blocking trunk/mainline lại là 1 việc cực kì tốn kém. Để duy trì trunk/mainline healthy thì nhiều công ty tôi đã kinh qua phải có build coach/release engineer oncall để làm cảnh sát. Việc trunk/mainline bị block khi có CD pipeline sẽ là thảm hoạ khi có sự cố trên production và cần phải release fix ngay (ko phải sự cố nào cũng có thể rollback). Vì việc commit đã vô trunk nên việc revert cũng phải cân đo đong đếm - đơn giản vì thằng release engineer nó chả biết cái commit kia làm cái quái gì và revert thì có thật sự fix được trunk/mainline hay không? Việc tìm bad commit khi đã vào trunk đòi hỏi cần phải có giải pháp bisect hiệu quả.

Bad test theo fence là gì, là tests ko hợp, tests validate tùm lum, tests chạy lâu, tests ko đúng hay gì . Test có bad hay ko là do vấn đề viết test

Click to expand...

Theo model câu hỏi ở trên chắc là xài trunk development model rồi , nên mới có 1 main branch. Mà model này phải đảm bảo test nhiều.

Click to expand...

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.
=> Ko rõ fence hỏi gì xD

Click to expand...

code4sticker said:

Xin lỗi thím trước vì tôi đần và đụt nên trình bày không được ngắn gọn súc tích dễ gây khó hiểu.



Trường hợp này thím không tính đến việc tất cả test là hợp lý và cần phải chạy hết. Thật sự nó là vấn đề của execution nếu chạy test chỉ trên 1 host. Đây là vấn đề thực tế tôi đã thấy. Tôi đã đề cập 1 cách giải quyết (mà tôi được thấy) bằng việc chạy song song nhiều host 1 lúc và aggregate kết quả chạy để feedback. Đây là nói về việc những test phải chạy trên mỗi commit mới trước khi merge vô trunk/mainline nhé. Ko phải chạy continuous trên trunk/mainline như điểm số 4 của thím ở ý sau.



Có 2 nhóm

1. Chạy test trên commit trước khi merge vào trunk/mainline. Việc bắt được bad commit tại thời điểm này là tốt nhất, nhưng không bao giờ đảm bảo 100% luôn bắt được. Feedback cho dev tại thời điểm này dễ nhất (như kiểu static/lint/unit tests/fast integration tests vân vân)
2. Chạy test trên trunk/mainline sau khi merge. Việc bắt bad commit tại thời điểm này là không khó (đồng ý với điểm số 4 - chạy tests liên tục sẽ giúp tóm được đám này chẳng hạn), nhưng việc blocking trunk/mainline lại là 1 việc cực kì tốn kém. Để duy trì trunk/mainline healthy thì nhiều công ty tôi đã kinh qua phải có build coach/release engineer oncall để làm cảnh sát. Việc trunk/mainline bị block khi có CD pipeline sẽ là thảm hoạ khi có sự cố trên production và cần phải release fix ngay (ko phải sự cố nào cũng có thể rollback). Vì việc commit đã vô trunk nên việc revert cũng phải cân đo đong đếm - đơn giản vì thằng release engineer nó chả biết cái commit kia làm cái quái gì và revert thì có thật sự fix được trunk/mainline hay không? Việc tìm bad commit khi đã vào trunk đòi hỏi cần phải có giải pháp bisect hiệu quả.

Vì thím đã đề cập chạy test liên tục, tức sẽ có test sẽ bị sai nếu dev không biết để sửa trong cùng commit. Cơ chế isolate broken test và feedback lại là cần thiết (để có người sửa). Ví dụ nếu có CD pipeline và release engineer thì cái người này muốn thấy là green tests để CD pipeline được thông suốt chứ không phải broken test run và kiểm tra có đúng đó làm đám test đã chết để mà override cho qua. Điểm này là lập lại cùng với ý cơ chế quản lý test đã nói (chỉ là nói chung chung chứ quản lý là thế nào cũng không rõ).



Đúng là trunk development vì ở trên chủ thớt kêu nó là tiền đề ở #13 nhưng #1 thì vậy. Kẹt cái tôi đụt quá phải hỏi.



Này là lỗi của tôi, xin ghi nhận. Ý tôi muốn nói là làm sao hotfix/patch 1 version đã released khi có release branch. Tôi đần lắm nhưng đoán là có thể sửa trực tiếp trên release branch rồi cherry pick qua trunk/mainline hoặc ngược lại. Nhưng cái nào cũng có vấn đề của nó, và đó là những thứ gì thì nếu ai biết thì kể cho đám đần và đụt biết thêm. Nếu sử dụng trunk development thì code chỉ có move forward, lúc đó fix/patch sẽ như nào thì tôi miệng lưỡi kém cõi nên lãi nhãi chả vào đâu

Dù sao thì good talk với thím, ít ra tôi thấy đã cover được khá nhiều điểm thú vị cho đám đần và đụt như tôi

Click to expand...

code4sticker said:

Xin lỗi thím trước vì tôi đần và đụt nên trình bày không được ngắn gọn súc tích dễ gây khó hiểu.



Trường hợp này thím không tính đến việc tất cả test là hợp lý và cần phải chạy hết. Thật sự nó là vấn đề của execution nếu chạy test chỉ trên 1 host. Đây là vấn đề thực tế tôi đã thấy. Tôi đã đề cập 1 cách giải quyết (mà tôi được thấy) bằng việc chạy song song nhiều host 1 lúc và aggregate kết quả chạy để feedback. Đây là nói về việc những test phải chạy trên mỗi commit mới trước khi merge vô trunk/mainline nhé. Ko phải chạy continuous trên trunk/mainline như điểm số 4 của thím ở ý sau.



Có 2 nhóm

1. Chạy test trên commit trước khi merge vào trunk/mainline. Việc bắt được bad commit tại thời điểm này là tốt nhất, nhưng không bao giờ đảm bảo 100% luôn bắt được. Feedback cho dev tại thời điểm này dễ nhất (như kiểu static/lint/unit tests/fast integration tests vân vân)
2. Chạy test trên trunk/mainline sau khi merge. Việc bắt bad commit tại thời điểm này là không khó (đồng ý với điểm số 4 - chạy tests liên tục sẽ giúp tóm được đám này chẳng hạn), nhưng việc blocking trunk/mainline lại là 1 việc cực kì tốn kém. Để duy trì trunk/mainline healthy thì nhiều công ty tôi đã kinh qua phải có build coach/release engineer oncall để làm cảnh sát. Việc trunk/mainline bị block khi có CD pipeline sẽ là thảm hoạ khi có sự cố trên production và cần phải release fix ngay (ko phải sự cố nào cũng có thể rollback). Vì việc commit đã vô trunk nên việc revert cũng phải cân đo đong đếm - đơn giản vì thằng release engineer nó chả biết cái commit kia làm cái quái gì và revert thì có thật sự fix được trunk/mainline hay không? Việc tìm bad commit khi đã vào trunk đòi hỏi cần phải có giải pháp bisect hiệu quả.

Vì thím đã đề cập chạy test liên tục, tức sẽ có test sẽ bị sai nếu dev không biết để sửa trong cùng commit. Cơ chế isolate broken test và feedback lại là cần thiết (để có người sửa). Ví dụ nếu có CD pipeline và release engineer thì cái người này muốn thấy là green tests để CD pipeline được thông suốt chứ không phải broken test run và kiểm tra có đúng đó làm đám test đã chết để mà override cho qua. Điểm này là lập lại cùng với ý cơ chế quản lý test đã nói (chỉ là nói chung chung chứ quản lý là thế nào cũng không rõ).



Đúng là trunk development vì ở trên chủ thớt kêu nó là tiền đề ở #13 nhưng #1 thì vậy. Kẹt cái tôi đụt quá phải hỏi.



Này là lỗi của tôi, xin ghi nhận. Ý tôi muốn nói là làm sao hotfix/patch 1 version đã released khi có release branch. Tôi đần lắm nhưng đoán là có thể sửa trực tiếp trên release branch rồi cherry pick qua trunk/mainline hoặc ngược lại. Nhưng cái nào cũng có vấn đề của nó, và đó là những thứ gì thì nếu ai biết thì kể cho đám đần và đụt biết thêm. Nếu sử dụng trunk development thì code chỉ có move forward, lúc đó fix/patch sẽ như nào thì tôi miệng lưỡi kém cõi nên lãi nhãi chả vào đâu

Dù sao thì good talk với thím, ít ra tôi thấy đã cover được khá nhiều điểm thú vị cho đám đần và đụt như tôi

Click to expand...

toi5 said:

Theo kiến thức đụt của thím thì ko còn đụt nữa, tui đụt chỉ trả lời dc kiểu đụt thui á, với lại tôi mong là fence ko troll nhá

Click to expand...