- Những bất mãn với GitHub Actions
- Nhóm gồm khoảng 15 kỹ sư, và mọi người đều liên tục push code lên nhánh main
- Code tồn tại dưới dạng monorepo được chia thành nhiều module, và được triển khai nhiều lần mỗi ngày theo phương thức phát triển dựa trên trunk
- Dù cũng có trường hợp GitHub Actions được sử dụng hiệu quả, nhưng ở một số quy mô hoặc môi trường nhất định, các giới hạn của nó bộc lộ rất rõ
Pull request và các kiểm tra bắt buộc
- Monorepo được chia thành nhiều thư mục, và mỗi thư mục tự thực hiện test, build, deploy một cách độc lập
- Sử dụng tính năng
paths của GitHub Actions để chỉ trigger pipeline tương ứng khi có thay đổi ở thư mục cụ thể
- Việc yêu cầu mọi kiểm tra đều phải pass trước khi merge pull request là một nguyên tắc tốt, nhưng khi kết hợp với cấu trúc monorepo thì phát sinh vấn đề
- Ví dụ: đặt check
web-app1 - Unit tests là “bắt buộc”, nhưng nếu không có thay đổi trong thư mục web-app1 thì check đó sẽ không chạy
- Kết quả là dù chỉ thay đổi một thư mục, các bài test liên quan đến thư mục khác không chạy, khiến bản thân việc merge trở nên bất khả thi
- Sẽ có thể giải quyết nếu phía GitHub xử lý theo cách như “có thể merge nếu tất cả các check hiện đang được trigger đều pass”, thay vì dựa vào tên của check bắt buộc, nhưng đáng tiếc là suốt 3 năm nay vẫn chưa có thay đổi nào
- Có thể thấy mức độ ảnh hưởng lớn của vấn đề này qua các thread issue GitHub liên quan 1, 2
- Cuối cùng, để lách qua vấn đề này thì phải chạy thêm pipeline hoặc duy trì các cấu hình phức tạp, vừa tốn công vừa tốn chi phí
Khả năng tái sử dụng và YAML
- Khi quy mô pipeline lớn dần, cảm giác ngày càng khó quản lý bằng GitHub Actions
- Có rất nhiều câu lệnh if xuất hiện, và dù tách workflow ra thì số lượng file phải quản lý cũng tăng lên, làm giảm khả năng bảo trì
- Ngay cả phần gọi tái sử dụng lẽ ra chỉ nên kết thúc trong một dòng cũng cần nhiều dòng và cấu hình lặp lại, đến mức trong thư mục
.github đã chất đống hơn 30 file
- Với mệnh đề
needs cũng vậy, nếu khi refactor không phản ánh đúng các job đã bị xóa thì sẽ mất thời gian mới phát hiện ra lỗi
- Không thể chạy GitHub Actions ở môi trường local nên việc phát triển và kiểm thử khá khó khăn
- Có các công cụ như
act, nhưng trong sử dụng thực tế thường có nhiều hạn chế và không đáp ứng được kỳ vọng
Sự thờ ơ của GitHub
- Trong các vấn đề trên, điều lớn nhất là GitHub dường như không xem những issue này là quá quan trọng
- Nhiều issue đã mở suốt nhiều năm và không được đưa vào roadmap công khai, nên trông có vẻ không có nhiều ý chí cải thiện
- Cộng đồng cũng đã phản ứng khi gần đây hàng loạt issue về những vấn đề được nhắc đến từ lâu bị đóng lại
Các lựa chọn
- Xét đến những vấn đề này và việc GitHub thiếu ý chí cải thiện, cần thận trọng trước khi áp dụng GitHub Actions
- Trên thị trường có nhiều lựa chọn CI/CD khác như Gitlab, Jenkins, TeamCity
- Những công cụ đưa ra cách tiếp cận mới như Dagger cũng đáng để xem xét
6 bình luận
CI/CD thì GitLab là đỉnh nhất
Tôi cũng từng dùng GitLab, nên khi rơi vào môi trường GitHub Actions thì có cảm giác chẳng có gì chạy được cả...
Việc GitHub không thể quản lý các repository bằng cách nhóm chúng theo từng nhóm cũng là một trong những điều khiến tôi rất không hài lòng..
Về pipeline thì có vẻ GitLab thực sự rất tốt. Những gì nói ở trên GitLab đều làm được.
Trong trường hợp monorepo, cũng khá tiện để cấu hình kiểu khi thư mục nào thay đổi thì cần chạy những gì, những gì, những gì để kiểm thử.
Muốn dùng lại GitHub Actions thì chắc tôi sẽ suy nghĩ thêm một lần nữa.
Chuyện này thì cần biết lịch sử của GitHub Actions...
Phiên bản GitHub Actions đầu tiên thật ra có dáng vẻ khá khác so với bây giờ... GitHub đã được MS mua lại vào khoảng 6 tháng trước khi mở ra công khai (trí nhớ tôi cũng hơi mơ hồ), và hình như việc phát triển Actions khi đó được phía MS làm cùng với đội Azure DevOps. Lúc đó Azure DevOps không còn có thêm tính năng mới nữa, còn các tính năng vốn có ở Azure DevOps thì lại xuất hiện dưới dạng tính năng mới trong GitHub Actions... Cũng vào thời điểm đó nó được chuyển sang Yaml, và môi trường hiện tại được hình thành như bây giờ.... hu hu
Sau đó có vẻ như các nhà phát triển quay lại về cùng một nhóm, và trông như không còn tiếp tục chăm chút vào nó nữa... Thật đáng tiếc... Hiện tại ở công ty tôi đang xây dựng CI/CD dựa trên GitHub Actions... vì đến giờ vẫn chưa có điểm gì thiếu nên vẫn đang dùng...
Chắc phải tiếp tục theo dõi kỹ vậy...
Ý kiến trên Hacker News
DSL của pipeline không nên chứa logic thực tế, mà chỉ nên dùng để điều phối công việc. Các tác vụ phức tạp nên được viết thành script để có thể chạy đơn giản. Nhờ vậy có thể thực hiện cùng một tác vụ một cách đơn giản trên GitHub Actions, Jenkins, Azure DevOps, v.v.
Khi cấu hình GitHub Actions, nên tránh các action dựng sẵn và dùng nó như một trình chạy shell đơn giản. Viết script bằng Python, Ruby, Bash, v.v. rồi chạy chúng trong GitHub Action sẽ giúp kiểm thử cục bộ dễ hơn và giảm bớt những phiền toái không cần thiết
GitHub Actions có thể chỉ chạy kiểm tra khi các điều kiện cụ thể được đáp ứng. Nhưng khi dùng các quy tắc này, bạn sẽ gặp vấn đề "pull request và required checks". Khi dùng cùng dịch vụ bên ngoài, các required checks bắt buộc phải pass; nếu không thì không thể merge
Một cách giải quyết vấn đề "pull request và required checks" là tạo phiên bản 'no op' cho từng workflow kiểm tra bắt buộc, để khi điều kiện không được đáp ứng thì workflow này chạy và thoát với mã 0. Đây là chức năng cơ bản nhưng là một cách giải quyết hơi phức tạp
Travis CI từng rất tuyệt để thử nghiệm CI ở môi trường local. GitHub Actions được tạo ra để cạnh tranh với GitLab CI, khi họ đang mất thị phần ở thị trường doanh nghiệp
Khuyến nghị thử Buildkite. Nếu đã vượt quá khả năng của GitHub Actions, Buildkite có thể là một lựa chọn thay thế tốt. Đã có kinh nghiệm dùng nó tại một công ty công nghệ lớn của Mỹ, và đó là phần duy nhất dễ chịu của CI
Kiến trúc của GitHub Actions có thể khiến người dùng đưa ra các quyết định bảo mật sai lầm. Ví dụ, secret ở cấp tổ chức hoặc repository thì tiện, nhưng có thể trở thành lỗ hổng bảo mật. Environment của repository có thể có secret riêng, nhưng cần đảm bảo workflow phù hợp chỉ có thể truy cập đúng environment phù hợp
Triết lý chung của các hệ thống CI là sai. Thay vì CI chạy code, code phải chạy CI. CI nên cung cấp API để người dùng có thể cung cấp thông tin cho hệ thống
Có thể dùng Bazel để công cụ CI build các target Bazel, và khi cần thì tăng tính song song thông qua remote build execution. Cách này phù hợp với khoảng 10M+ dòng code hoặc các dịch vụ quy mô lớn
Trên GitHub có thể chỉ định "required checks", và chúng phải luôn ở trạng thái xanh. Nhưng nếu chúng chỉ chạy khi có thay đổi ở một thư mục cụ thể, thì khi thay đổi ở thư mục khác sẽ không thể merge. Nếu không chạy toàn bộ test thì việc tích hợp sẽ mất ý nghĩa, vì vậy cần làm cho test chạy đủ nhanh