CI nhanh nhất mà chúng tôi tạo ra đã thất bại
(earthly.dev)- Thay vì đối đầu trực tiếp với các đối thủ hiện hữu trên thị trường công cụ CI/CD, Earthly đã tập trung vào tốc độ build, nhưng nay dừng Earthly CI và quay lại tập trung vào Earthly cùng Satellites
- Tầm nhìn ban đầu là hợp nhất hệ thống build và CI rồi thực thi phân tán, để cung cấp đồng thời khả năng song song tự động, caching và tái hiện cục bộ
- Earthly và Earthly Satellites lần lượt được kiểm chứng nhờ tính nhất quán của build và pipeline CI nhanh hơn 2–20 lần, nhưng sản phẩm thay thế CI hoàn chỉnh không tạo ra đủ mức chuyển đổi
- Khách hàng mới nhìn thấy chi phí migration và gánh nặng viết lại script là rất lớn, còn khách hàng Satellites hiện có thì chỉ với tổ hợp CI sẵn có như GitHub Actions đã nhận được 95% giá trị của Earthly CI
- Earthly CI sẽ ngừng hoạt động vào ngày 1 tháng 10 năm 2023; Earthly sẽ đầu tư vào Satellites theo hướng giúp người dùng có build nhanh trong khi vẫn giữ CI hiện tại
Dừng Earthly CI và tái tập trung
- Earthly dừng Earthly CI và tái định hướng công ty xoay quanh Earthly cùng Earthly Satellites
- Giá trị trọng tâm trong tương lai được thu hẹp còn hai điểm
- Build cục bộ và khả năng tái hiện
- Earthly Satellites có thể dùng cùng CI hiện có
- Earthly CI nhắm tới CI nhanh, nhưng không tạo được đủ tín hiệu chấp nhận ban đầu trên thị trường
Tầm nhìn ban đầu về “CI nhanh nhất”
- Earthly khởi đầu vào tháng 4 năm 2020 với mục tiêu cải thiện công cụ CI/CD
- Điểm xuất phát là hai câu hỏi
- Nếu CI có thể chạy cả trên laptop thì nó sẽ trông như thế nào
- Hệ thống CI nhanh nhất trên Trái Đất sẽ trông như thế nào
- Câu trả lời Earthly tìm ra là hệ thống build và CI phải là một, đồng thời phải được phân tán
- Mục tiêu là không lặp lại các bước build không bị ảnh hưởng bởi thay đổi, cung cấp thực thi song song tự động, và tái hiện ổn định bất kỳ phần nào của build trên laptop
Cách một đội nhỏ cạnh tranh với các nhà cung cấp CI hiện hữu
- Startup giai đoạn đầu khó cạnh tranh với các công ty hiện hữu có vốn, nhân lực, uy tín và hơn 10 năm đi trước về mức độ hoàn thiện, số lượng tính năng và phạm vi tích hợp
- Chiến lược Earthly chọn là thay vì thuyết phục toàn bộ thị trường, cung cấp một giải pháp tốt hơn 10 lần cho một số ít đội đang chịu đau đớn nặng nề vì một vấn đề cụ thể
- Kiểm chứng ban đầu gần với trạng thái hình thành một nhóm nhỏ người dùng sử dụng sản phẩm nhiệt tình dù sản phẩm còn lỗi và giới hạn
- Khi MVP không đạt đủ mức kiểm chứng, cách đơn giản là thêm nhiều tính năng thường dễ kéo sản phẩm vào cuộc cạnh tranh có lợi cho các đối thủ hiện hữu
Kế hoạch 3 giai đoạn hướng tới Earthly CI
- Earthly không xây ngay mục tiêu cuối cùng là Earthly CI, mà chia thành nhiều sản phẩm độc lập để thử kiểm chứng theo từng giai đoạn
-
Giai đoạn 1: Earthly
- Cột mốc đầu tiên là Earthly
- Earthly trước hết cung cấp cú pháp build và trải nghiệm chạy build theo nhu cầu
- Giá trị cốt lõi là tính nhất quán của build, giúp build chạy giống nhau bất kể môi trường thực thi
- Ban đầu nó chạy cục bộ và trên các CI khác, sau đó được dùng trong hàng nghìn repository
- VMware, Adobe, Namely, Roche, ExpressVPN, Bluecore... được nhắc đến như người dùng
- Đây là dự án không có vốn, do một người phát triển, cũng có lỗi và ràng buộc, nhưng việc mọi người thực sự sử dụng đã trở thành tín hiệu kiểm chứng
-
Giai đoạn 2: Earthly Satellites
- Cột mốc thứ hai là Earthly Satellites
- Satellites là remote runner có thể được gọi từ laptop hoặc bất kỳ CI nào
- Giá trị cốt lõi là tốc độ build giúp pipeline CI nhanh hơn 2–20 lần nhờ caching và song song hóa
- Vì Earthly là mã nguồn mở, trước khi dịch vụ thương mại ra mắt, người dùng vẫn có thể tự vận hành remote runner dựa trên Buildkit để đạt hiệu quả tương tự
- Khi Satellites dạng managed ra mắt, người dùng bắt đầu dùng sản phẩm để khỏi phải tự quản lý remote runner
- Satellites ban đầu có lỗi, kém hiệu quả và thiếu ổn định, nhưng vì có ít lựa chọn thay thế cung cấp tốc độ CI/CD ở mức tương tự nên người dùng đã đến
-
Giai đoạn 3: Earthly CI
- Cột mốc thứ ba là Earthly CI
- Earthly CI là nền tảng CI đầy đủ kết hợp Earthly và Satellites, nhằm cạnh tranh với các CI như GitHub Actions, CircleCI, Jenkins
- Vì Earthly nhắm tới tính nhất quán của build, còn Earthly CI nhắm tới tốc độ build, Earthly cho rằng Earthly miễn phí sẽ không làm xói mòn khả năng kiếm tiền của Earthly CI
- Tuy nhiên về sau, sự khác biệt trong đề xuất giá trị giữa tính nhất quán và tốc độ lại trở thành vấn đề
Rào cản chuyển đổi lộ rõ sau khi ra mắt
- Earthly CI đã được ra mắt, được TechCrunch giới thiệu, và cũng chuẩn bị các bài blog cho Reddit và HackerNews
- Trong 1–2 tuần đầu sau khi ra mắt, khoảng 50 email đã đăng ký vào danh sách chờ, vượt mục tiêu
- Có sự khác biệt rõ giữa khách hàng mới và người dùng Earthly hiện có
- Khách hàng mới thường xem “CI về cơ bản đều giống nhau, chỉ khác cú pháp” và không đào sâu điểm khác biệt của Earthly CI
- Các cuộc trao đổi phần lớn chuyển sang chi phí migration do phải viết lại và thích nghi các script hiện có
- Người dùng Earthly hiện có đã hoàn tất chuyển sang Earthfile và đã trải nghiệm lợi ích của Earthly, nên sẵn sàng trở thành người ủng hộ trong tổ chức
- Với khách hàng mới, Earthly thiếu uy tín để chứng minh rằng mình có thể cung cấp các lợi ích đã hứa ở quy mô lớn, và khó chứng minh trong một cuộc gọi Zoom ngắn rằng trải nghiệm của người dùng hiện có “dễ hơn 10 lần”
Vì sao cả khách hàng hiện có cũng không chuyển sang Earthly CI
- Hầu hết khách hàng Earthly Satellites hiện có đã dùng Satellites trong CI/CD
- Earthly cho rằng vì nhà cung cấp CI chỉ phụ trách trigger pipeline còn việc thực thi thực tế diễn ra trên Satellites, nhu cầu về Earthly CI đã được kiểm chứng
- Nhưng khách hàng Satellites đã nhận được 95% giá trị của Earthly CI
- So với cấu hình GitHub Actions + Satellites, Earthly CI không đủ tốt hơn và thiếu lý do để chuyển đổi
- Người dùng Earthly hiện có đã dùng Earthfile nên tưởng như việc chuyển đổi sẽ dễ, nhưng yêu cầu thực tế nhiều hơn
- Hệ sinh thái plugin của GitHub
- codecov action
- Trigger thủ công
- Trigger dựa trên việc tạo git tag
- Lựa chọn kích thước máy
- Hủy các build cũ
- Niềm tin để giao phó build secret
- MVP của Earthly CI là CI nhanh nhất, nhưng không đáp ứng được một số yêu cầu cốt lõi
- Một số người dùng nhiệt tình đã thử Earthly CI, nhưng sản phẩm không được dùng rộng rãi vượt quá 2–3 người trong các tổ chức có quy mô và ngân sách
- Một số người dùng Earthly CI sau đó chuyển thành người dùng Satellites để vừa có hệ sinh thái GitHub vừa có tốc độ của Satellites
Vì sao yêu cầu demo lại trở thành tín hiệu tiêu cực
- Earthly đã có hơn 100 cuộc gọi với khách hàng tiềm năng, nhưng qua trao đổi trực tiếp rất khó thuyết phục họ dùng bất kỳ sản phẩm nào trong Earthly CI, Satellites hay Earthly
- Ngược lại, khi người dùng tự tìm đến qua website, tăng trưởng theo sản phẩm, truyền miệng và content marketing, việc chấp nhận Earthly diễn ra hằng ngày và cũng tăng mạnh
- Công cụ dành cho developer, đặc biệt là công cụ cần công việc tích hợp, khó được kiểm chứng bằng phương thức bán hàng trực tiếp truyền thống
- Tiêu chí loại trừ tiêu cực mạnh nhất là khách hàng tiềm năng yêu cầu demo
- Những đội thực sự chuyển đổi đã tải Earthly, đọc tài liệu, tự viết Earthfile rồi mới tìm đến, và không cần demo
- Công cụ developer cần công việc tích hợp được đưa vào sử dụng theo lịch trình của người dùng; rất khó bán ép hoặc thúc đẩy nhanh
A/B test đổi “CI” thành “build”
- Thông điệp trên website Earthly lúc đó là “Earthly makes CI super simple”, và phần lớn màn hình đầu nhấn mạnh CI
- Gavin Johnson đề xuất A/B test thay từ “CI” trên website bằng “build”
- Câu chữ được đổi thành “Earthly makes builds super simple”
- Chỉ thay một từ này đã làm tỷ lệ chuyển đổi tới trang CTA chính “Get Earthly” tăng gấp đôi
- Sau kết quả này, nghi ngờ về chính Earthly CI tăng lên
Bài học từ trải nghiệm ShiftLeft
- ShiftLeft, được khởi động trước Earthly, hiện được gọi là Qwiet.ai
- Tầm nhìn ban đầu là một security agent cài trong production để bảo vệ cloud app khỏi các cuộc tấn công khai thác lỗ hổng trong mã nguồn
- Sản phẩm này cần một bộ phân tích mã hỗ trợ nhiều ngôn ngữ lập trình, agent cho từng runtime, và backend phân tán để tích hợp mọi thứ; điều này giống như một startup nhỏ đồng thời xây độ phức tạp tương đương ba công ty
- Sau hơn một năm nỗ lực, họ tạo được luồng end-to-end hoạt động cho một ngôn ngữ lập trình, nhưng phản ứng thị trường không tốt
- Khách hàng mục tiêu của sản phẩm bảo mật là các enterprise chịu nhiều quy định, và vì phải đưa sản phẩm vào cả CI/CD lẫn production nên đường đi tới adoption rất khó
- Khi đó họ cho rằng thêm nhiều tính năng hơn sẽ vượt qua được khó khăn trong adoption, nên tiếp tục xây thêm một năm rưỡi nữa, nhưng thị trường không muốn sản phẩm
- Muộn màng họ mới nhận ra có thể tách sản phẩm phức tạp thành hai sản phẩm khác nhau
- Công cụ soi xét mã cho chuyên gia bảo mật
- Bộ phân tích mã độc lập nhanh hơn 40 lần so với các bộ phân tích mã khác trên thị trường
- Điều hối tiếc lớn nhất là đã không dừng sớm hơn khi có tín hiệu
Phán đoán của Earthly
- Tình hình Earthly tổng kết như sau
- Mọi người muốn build nhanh hơn
- Mọi người ghét chuyển đổi CI
- CI mới bị gắn định kiến là không khác biệt, và ngay khi thấy “CI” trên website, người dùng rời đi
- Cách tham gia kiểu design partner thông qua tiếp xúc trực tiếp với khách hàng không hiệu quả vì nhận thức chi phí migration cao
- MVP của Earthly CI không tạo được đủ nhóm early adopter ban đầu
- Phản ứng trở nên tốt hơn khi nói rằng có thể có build nhanh hơn với Earthly Satellites mà không cần thay CI hiện có
- Vấn đề cốt lõi không phải là Earthly CI thiếu tính năng
- Với một sản phẩm ban đầu có triển vọng, phải có một nhóm sẵn sàng chấp nhận thiếu tính năng để nhận được lợi ích, nhưng Earthly CI không có đủ tín hiệu ở mức đó
- Vì vậy Earthly quyết định dừng Earthly CI và tập trung vào Earthly cùng Earthly Satellites, những thứ đang hoạt động
Lịch dừng và chuyển đổi người dùng
- Earthly CI sẽ ngừng hoạt động vào ngày 1 tháng 10 năm 2023
- Earthly CI được đánh dấu là beta/thử nghiệm, nhưng Earthly hỗ trợ người dùng chuyển đổi
- Vì Earthly hoạt động cùng bất kỳ CI nào, Earthly cho rằng migration ra khỏi Earthly CI là dễ dàng
- Nếu vẫn muốn build nhanh, người dùng có thể kết nối Earthly Satellites; Satellites cũng có tier miễn phí
- Hỗ trợ chuyển đổi được cung cấp trực tiếp trong Earthly Slack community
Hướng đầu tư tương lai cho Satellites
- Earthly Satellites đang có tín hiệu tăng trưởng vì không chỉ cung cấp build nhanh và nhất quán, mà còn cho phép người dùng giữ CI của mình
- Thời gian có được nhờ dừng Earthly CI sẽ được đầu tư vào các tính năng mà cộng đồng Earthly đã yêu cầu
- Satellite metrics, bao gồm mức sử dụng CPU, bộ nhớ, đĩa và network I/O
- Build history trong web UI cho cả build cục bộ lẫn build trên Satellites
- Auto-skip, bỏ qua ngay nếu các file đã thay đổi không ảnh hưởng tới build
- Tính năng chạy từ xa build Dockerfile trên Satellites như một lựa chọn thay thế nhanh cho
docker build - self-hosted Satellites, phiên bản được hỗ trợ tốt hơn của self-hosted remote Buildkit
- Tính năng phân tán một build đơn lên nhiều Satellites để tăng tốc
- Compute v2, Satellites serverless phân tán hoàn toàn
- Earthly Satellites là remote build runner hoạt động cùng bất kỳ CI nào và có thể dùng thông qua Earthly Cloud
- Earthly là framework build mã nguồn mở cung cấp tính nhất quán của build — viết một lần, chạy ở mọi nơi — và giúp dễ dàng tái hiện lỗi CI trên máy cục bộ
1 bình luận
Các ý kiến trên Hacker News
Đây là một bài viết cho thấy rất rõ vì sao khi mở mã nguồn không nên trao đi toàn bộ giá trị cốt lõi. Vì Earthly là mã nguồn mở, người dùng Earthly Satellite thực ra đã hưởng được 95% giá trị của Earthly CI
Tôi rất thích mã nguồn mở, nhưng nếu mô hình kinh doanh có mã nguồn mở thì cần có yếu tố khác biệt hóa. Không chỉ đơn giản là cực nhanh; phải có lý do để người ta rút thẻ tín dụng ra, hoặc xa hơn là khởi động quy trình đặt mua qua bộ phận kế toán
GitLab giới hạn CI/CD cho khách hàng trả phí, Travis/CircleCI giới hạn thời gian build hoặc credit, Azure DevOps thì như quỷ dữ, còn ArgoCD thì phức tạp. GitHub Actions khá ổn nếu có phần cứng để chạy runner, và trong doanh nghiệp thì đám Jenkins vẫn là thứ quen thuộc
Với tư cách một cựu giám đốc DevOps, điều đầu tiên tôi hỏi là: “Tính năng nào khiến tôi phải mua thay vì tự host?” Nếu tôi có năng lực kỹ thuật để tự vận hành, và có thể vận hành cloud cùng pipeline DevOps của mình theo đúng nhu cầu doanh nghiệp, thì bạn phải thuyết phục tôi vì sao tôi nên trả tiền cho bạn
Ý tôi không phải là giấu các tính năng thiết yếu để phần mềm hoạt động, mà là đặt các tính năng phục vụ kinh doanh như hỗ trợ hoặc tích hợp cấp doanh nghiệp vào gói trả phí. Cũng có thể làm mô hình phân tầng, trong đó người dùng nâng cao tự hỗ trợ được nhiều hơn nên trả ít hơn
Có thể chuyển đổi số người dùng còn lại sang trả phí, nhưng đó là một canh bạc khá lớn. Một ví dụ đảo chiều tốt gần đây có thể là Docker, nhưng việc đó đòi hỏi họ phải từ bỏ mã nguồn mở nghiêm ngặt và thực hiện các thay đổi giấy phép/sản phẩm gây nhiều tranh cãi
Việc không thể đọc mã ngoài phần “open core”, không thể đóng góp sửa lỗi hoặc tự host thật sự rất khó chịu; còn những yếu tố phân biệt giấy phép mã nguồn mở với giấy phép công khai mã nguồn thì với tôi không cần thiết lắm
Tôi không muốn dội gáo nước lạnh, nhưng đây gần như đúng nghĩa là một sản phẩm sao chép-dán
Đã có Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines; nhìn lý lịch Ex-Google, Ex-VMW, RabbitMQ thì cũng không ngạc nhiên
Ngay cả nếu tác giả bài gốc không ở gần nguồn gốc của các công cụ trên, thì ít nhất cũng là họ hàng trong cùng câu chuyện đó
Chu kỳ bán hàng dài, còn tích hợp thì cần sự đồng thuận của nhiều cấp điều hành trên nhiều trục, bao gồm cả bảo mật và networking
Họ đã tạo ra thứ tốt, nhưng vấn đề ở thượng nguồn quá phức hợp nên câu chuyện này có cảm giác khá nhạt trong một lĩnh vực cứ liên tục dao động giữa hàng đặt riêng và sản phẩm phổ dụng. Nó trộn lẫn từ thiếu giám sát đến quản lý vi mô, từ non nớt đến kinh nghiệm quá nhiều đến mức không buông được “cách vẫn làm từ trước đến nay”
Có thể là quan điểm không được ưa chuộng, nhưng bán toolchain là đang cố đun sôi cả đại dương vấn đề. Kinh doanh và công nghệ chảy như nước, luôn tìm lỗ có ít lực cản nhất, và trong quá trình đó đôi khi làm xói mòn nền móng của “mảng kinh doanh cốt lõi”. Theo kinh nghiệm của tôi, các toolchain hoạt động như hướng dẫn hay “chiến lược nuôi dưỡng”, kèm guardrail có thể tháo lắp, mới mang lại phần thưởng lớn nhất
“Nhanh” không phải là điểm bán hàng. Lập trình viên không muốn pipeline chậm, nhưng điều đó không có nghĩa là họ muốn pipeline nhanh
Tốc độ pipeline phụ thuộc nhiều vào cách bạn cấu hình pipeline hơn là overhead của dịch vụ pipeline, và các dịch vụ CI/CD khác cũng đã rất nhanh. Ví dụ CircleCI cũng không dễ bán so với GitHub Actions và GitLab CI/CD; vậy dịch vụ này khác biệt ở đâu? Nó có bổ sung giá trị thực chất so với GitHub/GitLab/CircleCI không? Giảm vài mili-giây trong một bản build kéo dài vài phút không phải là câu trả lời
Lý do thất bại là marketing lộ liễu cẩu thả và khá thiếu trung thực
Dù biên dịch bằng Jenkins, Actions hay Earthly, nếu dùng cùng một node build thì thời gian biên dịch sẽ giống nhau. Trong bối cảnh CI khởi động chỉ trong vài giây, tuyên bố nhanh hơn 20 lần không có nhiều ý nghĩa
Caching và chạy song song là các khái niệm lâu đời trong CI, và mọi hệ thống build hiện đại đều làm được
Cốt lõi của CI là phản hồi, nhưng tôi không thấy nhiều ở khía cạnh cộng tác hay đưa dữ liệu lên cấp cao hơn. Tôi chưa xem kỹ, nhưng đáng lẽ những thứ này phải nằm ở tuyến đầu. Cuối cùng, tôi không muốn đưa thêm DSL nào vào cho build nữa
CI nhanh rốt cuộc nghĩa là gì?
CI là một shell script phình to quá mức, chạy build và báo khi thất bại. Thông thường bản thân công cụ build đã chậm đến mức chi phí cho runner CI gần như phải bằng 0 so với nó
Nếu muốn CI nhanh, thì tsc, clang, rustc, v.v. phải nhanh lên, chứ không phải chương trình gọi chúng bằng
execphải nhanh hơnNói sát chủ đề hơn, nếu đang bán CI mà kinh doanh thất bại thì đó là vì không cung cấp được giá trị. Người ta vẫn có thể chạy build script ngon lành mà không cần bạn
Không phải chuyện chương trình gọi
execnhanh hơn, mà là chuyện một chương trình biết ngay từ đầu rằng không cần gọiexecKhông biết họ đã đo cái gì, nhưng lấy một ví dụ: trang landing mặc định của Jenkins là thảm họa về tốc độ. Nó cố hiển thị dữ liệu build gần đây của cả cluster ở khắp nơi, và ngay cả với một cluster không quá lớn, có thể phải lấy hàng trăm đến hàng nghìn mục từ từng node riêng lẻ đang chạy mỗi build
Chỉ riêng việc tải landing page, nếu không có cấu hình cụ thể để chặn hành vi mặc định, tôi đã làm Jenkins chết không biết bao nhiêu lần
CI server thường có database riêng và quản lý đủ loại thực thể CI như job, artifact, user, secret. Nó có thể phình ra khá lớn và cần được chăm chút đúng mức về indexing, v.v.
CI có nhiều runner, và chúng thường được provision động. Cứ hình dung phải triển khai VM hoặc Docker image lên các node runner. Phân phối việc đó nhanh trên cluster cũng không hề dễ. Bạn cũng sẽ muốn phân tán artifact trên toàn cluster, và việc này cũng tốn thời gian lẫn tài nguyên
CI thực tế còn cần sổ sách nội bộ cho garbage collection, reporting và tự chẩn đoán. Trong một cluster đủ lớn, nếu không nỗ lực đặc biệt để giảm latency, tất cả những thứ này có thể tạo ra độ trễ rất cao
Đã nghe tới ccache chưa?
Nhưng thật sự, nói rằng “chỉ cần tsc/clang/rustc nhanh là đủ” là quá ngây thơ. Muốn build nhanh trong một hệ phân tán như CI thì còn phải giải quyết cách phân tán cache này và cách module hóa build. Chắc bạn từng nghe câu một trong những việc khó nhất trong lập trình là cache invalidation, và câu đó chỉ là đùa một phần thôi
Tôi đã mất khá lâu để chỉnh một GitHub Actions script khá lộn xộn, vì vòng lặp debug mất 10 phút
Thật may là họ chỉ đóng dịch vụ chứ không dẹp luôn cả công ty. Tôi thật sự thích công cụ này, đến mức thường xuyên vào xem trang tuyển dụng của họ
Cú pháp Earthfile là một bước tiến hóa rất hợp lý và tiệm tiến của cú pháp Dockerfile, giúp dễ dàng làm nhiều việc vốn bất khả thi hoặc rất vụng về nếu chỉ dùng Dockerfile
Tôi nhớ khi Docker đưa BuildKit và buildx vào, họ từng muốn đẩy Dockerfile thành một hệ thống build đa dụng, tức không chỉ để tạo container mà còn tạo artifact dạng file, v.v. Earthly đã thực sự triển khai tốt ý tưởng đó
Tôi đang dùng khá hài lòng, nhưng vẫn chưa trả tiền
Chỉ đọc bài này thì thành thật mà nói hơi khó hiểu chuyện gì đã xảy ra. Đọc vài lần rồi mà thuật ngữ vẫn còn rối. Có vẻ ít nhất đã có hai vấn đề riêng biệt
Vấn đề di chuyển cấu hình CI từ CI YAML hiện có, tức GitHub/GitLab, sang Earthly, một dạng lai giữa Makefile/Dockerfile
Vấn đề di chuyển trình chạy tác vụ từ CI hiện có sang dịch vụ do Earthly lưu trữ
Tôi đã nghĩ vấn đề thứ nhất là việc khó. Vì đổi ngôn ngữ có thể mất vài tháng hoặc vài năm
Nhưng tôi không rõ bài blog đang nói gì. Tôi tưởng phần đó đã được kiểm chứng, chẳng phải nghĩa là mọi người đã có thể chuyển đổi sao?
Thế nhưng đến cuối lại nói là chưa được kiểm chứng. Có phải khách hàng phải thực hiện không phải một mà là hai lần di chuyển không?
Vậy giờ sẽ thế nào? Giữ cú pháp Earthly nhưng từ bỏ CI à? Chẳng phải phần khó di chuyển chính là cú pháp đó sao? Vẫn còn rối
Ý chính có phải là họ giả định rằng build nhanh hơn nhiều là killer feature, nhưng đã không kiểm chứng giả định đó trước khi xây dựng? Hay là họ không phân khúc người dùng đúng cách nên không biết nhu cầu của khách hàng trả nhiều tiền là khác? Hoặc là họ đã đem cho miễn phí thứ thực sự giải quyết vấn đề của khách hàng trả tiền?
Và xét việc bài viết khá rối này do CEO viết, tôi tự hỏi sự rối rắm chỉ là do thiếu biên tập, hay trong suốt quá trình đó nội bộ công ty cũng thật sự có nhiều hỗn loạn
Từ lâu Steve Blank đã viết trong bài “Founders and dysfunctional families” [1] rằng nhiều nhà sáng lập lớn lên trong hỗn loạn nên giỏi quản lý hỗn loạn, và điều đó chắc chắn cũng đúng với tôi. Ông nói thêm rằng khác biệt giữa thành công và thất bại có thể phụ thuộc vào việc nhà sáng lập có xử lý được cả trạng thái không hỗn loạn hay không
Những nhà sáng lập không làm được điều đó có xu hướng ném “lựu đạn tổ chức” vào chính công ty mình để kéo mọi thứ về mức hỗn loạn mà họ giỏi xử lý. Quan sát đó đã nhiều lần khiến tôi phải dừng lại suy nghĩ trong nhiều năm sau đó
[1] https://steveblank.com/2009/05/18/founders-and-dysfunctional...
CI của mọi người theo thời gian trở thành một mô hình hỗn hợp, gói gọn toàn bộ cách mỗi công ty xây dựng và triển khai phần mềm của mình. Hãy hình dung tình huống CI bị lạm dụng như một trình chạy tác vụ tự động hóa tùy ý, kiểu Airflow
Việc di chuyển bắt đầu bằng chuyện trước tiên phải reverse engineer những gì mọi người từng biết, rồi sau đó mới có thể tháo gỡ toàn bộ và biểu diễn lại theo cách khác
Không ai muốn dừng cả thế giới lại để dọn dẹp chuyện đó
Bài này khó hiểu vì tác giả ở quá gần vấn đề, và cần giải thích từ góc nhìn của người ngoài trước khi đi vào chi tiết. Dù vậy có vẻ những thông tin cần thiết vẫn có
Kết quả là dường như họ đã tạo ra một lớp đóng gói giữa các hệ thống build theo từng ngôn ngữ và hệ thống build liên tục chạy chúng
Có thể so sánh với thứ như Bazel: Bazel làm được mọi thứ, nhưng để áp dụng hoàn toàn thì phải dốc toàn lực thay thế hệ thống build theo ngôn ngữ bằng ngôn ngữ build của Bazel, và nhiều khi còn phải di chuyển vị trí file nguồn để nó chạy được
Điều này có thể xa lạ so với cách dùng hệ thống build riêng của ngôn ngữ, nhưng với lập trình viên C, nơi ngôn ngữ không có hệ thống build riêng, thì có thể lại tự nhiên. Java cũng đã đi qua vài hệ thống build đáng tiếc rồi rốt cuộc không may lại dừng ở Gradle
Các hệ thống build theo ngôn ngữ cuối cùng không làm mọi thứ, vì mỗi ngôn ngữ có quy ước và hệ sinh thái khác nhau. Những hệ thống hiện đại biết phạm vi mình làm tốt và ở yên trong đó
Vì vậy công cụ thực sự hiểu nhiều ngôn ngữ và artifact thường là shell script, makefile, Dockerfile, hoặc chính hệ thống build liên tục. Thậm chí đôi khi làm thủ công. Lớp mà họ muốn cải thiện chính là phần này
Tuy nhiên insight căn bản về việc tại sao cách của họ tốt hơn thì vẫn chưa hiện lên thật rõ
Trước đây tôi từng xem qua Earthly một chút vì công việc. Lý do là phải viết tích hợp cho nhiều nền tảng CI như GitLab, Azure DevOps, Jenkins, và có lẽ cả GitHub Actions
Cuối cùng tôi chọn Dagger, một sản phẩm rất tương tự: cũng là một BuildKit frontend khá ổn khác có thể tích hợp với nhiều hệ thống CI, và khi đó DSL dùng để định nghĩa pipeline trông có vẻ tốt hơn
Nhưng rồi tôi đã hối hận sâu sắc về quyết định này. Vì các nhà phát triển Dagger về cơ bản đã bỏ ngôn ngữ đó và chuyển sang tung ra hàng loạt SDK cho các ngôn ngữ lập trình phổ biến. Tất cả đều là imperative, tất cả đều Turing complete, và theo tôi thì không phù hợp với lĩnh vực này
Vì vậy giờ tôi lại quay về địa ngục, tự tay tích hợp với tất cả các hệ thống này, và ngần ngại giao loại công cụ như vậy cho một startup lần nữa
Với tôi, đây vẫn là use case hấp dẫn nhất của những thứ như Earthly. “Push lên rồi xem chuyện gì xảy ra” gần như là tiêu chuẩn của mọi hệ thống CI, nhưng đó là một workflow kinh khủng
Nếu phải hỗ trợ các đội dùng nhiều nền tảng CI/CD khác nhau trong một tổ chức lớn, một thứ như Earthly có thể giảm khá nhiều đau đớn. Nhưng điểm hấp dẫn không nằm ở việc thêm một CI nữa, mà chính xác là ở hỗ trợ các nền tảng CI hiện có
Vấn đề chính của triển khai CUE trước đây là cố gắng khớp bộ giải đồ thị có hướng không chu trình của BuildKit với bộ giải đồ thị có hướng không chu trình của CUE, trong khi hai thứ này hoạt động theo hướng ngược nhau
Khoảng 3 năm trước, với tư cách một chuyên gia CUE, tôi đã cố giúp giải quyết vấn đề này. Tôi nghĩ với Dagger thì SDK là lời giải tốt hơn nhiều
Dù thích hay không, một phần đáng kể của ngành đang đi theo hướng này. Pulumi cũng là một ví dụ khác. Tôi đã bị thuyết phục bởi hạ tầng đám mây theo kiểu imperative, và build cũng có vẻ phần nào phù hợp với điều này
Ngoài ra, tôi dự định sẽ khám phá cấu hình CUE + Dagger mới, nhưng nó sẽ hoạt động khác với engine Dagger trước đây
Điểm cốt lõi là chúng tôi đã chuyển lớp khai báo từ cấu hình CUE tĩnh sang truy vấn GraphQL động. Và từ GraphQL schema, chúng tôi đã tạo ra client library cho nhiều ngôn ngữ
Vì vậy bạn không chỉ có thể cấu thành đồ thị có hướng không chu trình theo cách khai báo như trước, mà còn có thể làm bằng bất kỳ ngôn ngữ nào bạn thích. Bạn cũng có thể chạy DAG trực tiếp bằng GraphQL thuần. Hãy xem https://play.dagger.cloud để thử ngay trên trình duyệt
Một phép so sánh hữu ích là SQL. SQL là ngôn ngữ khai báo, nhưng thường được dùng cùng với ngôn ngữ khác, và thường là ngôn ngữ imperative
Hy vọng phần giải thích này hữu ích và khiến bạn cân nhắc Dagger thêm một lần nữa
Cụm “build nhanh hơn 2~20 lần” xuất hiện nhiều lần trong toàn bài. So với cái gì? Nếu không có baseline thì câu này chỉ là lời marketing vô giá trị
Đoạn “Tại sao không đơn giản hóa stack? Đừng trả tiền cho cả nhà cung cấp CI lẫn chúng tôi; chỉ trả cho chúng tôi thôi là được mà?” là vì CI mà họ “trả tiền” được cung cấp kèm với phần còn lại của stack. GitLab và GitHub có nhiều thứ hơn rất nhiều so với một sản phẩm CI đơn thuần
Tôi cũng hiểu đoạn “những người mới nhìn Earthly CI với thái độ hoài nghi, cho rằng mọi CI đều giống nhau chỉ khác cú pháp, rồi không xem tiếp”
Chúng tôi không mấy quan tâm đến bản thân CI; chúng tôi chỉ cần nó và nó hoạt động đúng là được
Nếu một app đã có CI manifest hoạt động, app mới sẽ dùng cùng manifest đó và chỉ tìm-thay vài chỗ. Lúc tạo lần đầu có thể đau đớn, nhưng nhìn các ví dụ thì cũng không thấy dễ hơn hẳn so với làm cùng việc đó trên GitLab
Nói thật, nếu họ đưa vào một bộ chuyển đổi nhận cấu hình GitLab hoặc GitHub CI rồi tạo Earthfile ngay tại chỗ, thì ít nhất có lẽ cũng khiến người ta thử dùng