Tìm kiếm
40 kết quả cho “Release”. Tìm không phân biệt dấu.
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- A Lightweight Distributed Architecture to Handle Thousands of Library Releases at eBay Bài tóm tắt · eBay · 2022
…ght-distributed-architecture-to-handle-thousands-of-library-releases-at-ebay/) Bối cảnh - eBay còn hơn 3.000 thư viện cũ build bằng hệ build dựa trên Ant, không còn được hỗ trợ. Mã…
- How we deliver mobile app updates faster Bài tóm tắt · Mercari · 2025
…g . Vì master luôn ổn định nên cắt bản lúc nào cũng được. - Release train hằng tuần: cắt nhánh release tự động mỗi thứ Ba (cùng lịch cho iOS và Android, chạy độc lập). Build bằng f…
- GitLab's unconventional journey to CI/CD and Kubernetes Bài tóm tắt · GitLab · 2019
…//about.gitlab.com/blog/gitlab-journey-to-cicd/) Bối cảnh - Release theo tháng: - feature freeze từ ngày 7, release ngày 22; - dev "panic merge" sát hạn, còn bản sửa lỗi gấp phải c…
- The Invisible Rewrite: Modernizing the Kubernetes Image Promoter Bài tóm tắt · Kubernetes · 2026
…tes.io/blog/2026/03/17/image-promoter-rewrite/) Bài của SIG Release. Phần chữ ký số (cosign, SLSA, SBOM) chỉ tóm tắt ngắn; lõi của bài là viết lại một công cụ hạ tầng mà mọi bản ph…
- How we designed our continuous integration system to be more than 50% faster Bài tóm tắt · Pinterest · 2021
…CI của Optimus chạy mọi target của service có thay đổi, và release rule chia rất nhỏ. P50 của một build CI là 52 phút , P90 là 69 phút . Thay đổi chính - Bazel làm build tool chun…
- How we built a dynamic Kubernetes API Server for the API Aggregation Layer in Cozystack Bài tóm tắt · Kubernetes · 2024
…n Cozystack là một Helm chart, triển khai bằng resource HelmRelease của FluxCD trong namespace của tenant. - Giới hạn RBAC: không lọc được quyền list trên cùng một kind theo label…
- How we achieved independent deployments in a micro-frontend architecture Bài tóm tắt · Allegro · 2026
…onent/plugin/service (gói npm) làm phụ thuộc. - Deploy theo release train thủ công hai lần mỗi ngày: phải gom đủ tác giả các thay đổi, kỹ sư trực tự dò lỗi và tìm chủ, một thay đổi…
- How we prevented security fixes leaking into our public repositories Bài tóm tắt · GitLab · 2021
…bản vá lên GitLab.com trước để kiểm. Trong lúc làm security release, bất kỳ user đăng nhập nào cũng bấm vào SHA đó và xem toàn bộ cây mã, kể cả bản vá. Thay đổi chính - Tạm thời: d…
- Deploying Large-scale Fraud Detection Machine Learning Models at PayPal Bài tóm tắt · PayPal · 2021
…chờ đợt sau, thường vài tuần; nhiều bước tay giữa các team, release engineer phải hiểu cả nền tảng lẫn quy trình nghiệp vụ; model lên production có khi lệch điểm hoặc lệch dữ liệu…
- Advancing Our Chef Infrastructure: Safety Without Disruption Bài tóm tắt · Slack · 2025
…úc được đưa vào, với thay đổi nhỏ); prod-2 → prod-6 đi theo release train : phiên bản mới chỉ vào prod-2 khi phiên bản trước đã đi hết tới prod-6 . Thay đổi tới hết prod chậm hơn,…
- Using OxCaml to implement type-safe reference counting between OCaml and Python Bài tóm tắt · Jane Street · 2026
…y.newref (local → unique), Py.decref (tiêu thụ unique). ppx release ( let%release df = … ) giải phóng sớm cả khi có exception. Vì sao - Chuyển lỗi giữ object quá lâu từ "phải cẩn t…
- Catching bugs on the client-side: how we developed our error tracking system Bài tóm tắt · Bumble · 2020
…mỗi tuần; phân tích lỗi là một bước của mỗi lần phát hành : release manager cần bản tổng hợp lỗi của phiên bản để quyết định có đưa build lên không, hay gỡ tính năng hỏng khỏi bản…
- Phoenix — Tinder's Testing Platform, Part II (Levers) Bài tóm tắt · Tinder · 2019
Một tính năng của app mobile đi qua PM, design, code, QA, build rồi duyệt của app store. Bất kỳ thay đổi nào sau đó (bug lọt QA, chỉnh chi tiết, muốn ra mắt đúng giờ) đều phải lặp lại cả vòng; trên mobile không thể…
- Evolution of the PyTorch Media Processing Landscape Bài tóm tắt · PyTorch · 2026
Vài năm trước, giải mã/mã hoá media rải rác và trùng lặp giữa TorchVision và TorchAudio, mỗi bên một stack. TorchVision riêng có nhiều lối vào (readvideo, VideoReader) trên ba backend (PyAV, FFmpeg C++, CUDA/NVCUVID),…
- The static-all Split - Dividing Zillow's JavaScript Monolith Repository Bài tóm tắt · Zillow · 2017
Năm 2012, dự án "The Great Schism" tách mọi tài nguyên tĩnh (JS, CSS, ảnh, template) khỏi ứng dụng monolith Java vào một repo tên static-all.
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Mô hình tổ chức SRE Chủ đề
Lúc nhỏ, một team ops hay SRE tập trung trực và vận hành mọi thứ. Khi chuyển sang microservice và "you build it, you run it", team sản phẩm phải tự sở hữu service trên production, nhưng nhiều team chưa có kỹ năng, còn…
- Quản lý fleet và migrate code hàng loạt Chủ đề Thành viên
Khi số component (repo, service, pipeline, thư viện) tăng nhanh hơn số kỹ sư, chi phí của mỗi thay đổi xuyên suốt (nâng thư viện, vá bảo mật, đổi API nội bộ, khai tử dataset) tỉ lệ với số component chứ không với độ khó…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Load shedding, rate limit và backpressure Chủ đề Thành viên
Mọi hệ đều có lúc nhận nhiều việc hơn sức làm: spike của người dùng, client nội bộ có bug, dependency chậm đi, retry dồn lại. Theo Discord, khi chạm giới hạn năng lực thì đó là bài toán kinh tế: hoặc tăng cung (thêm…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Thử nghiệm A/B và nền tảng experimentation Chủ đề Thành viên
Khi nhiều team cùng thay đổi một sản phẩm, "ship rồi xem metric" không còn trả lời được thay đổi nào gây ra gì. Thí nghiệm có đối chứng trả lời được, nhưng ở quy mô lớn nó thành một hệ thống: gán người dùng vào biến thể…
- Bảo mật hạ tầng và quản lý secret Chủ đề Thành viên
Khi hệ thống lớn lên, số credential (mật khẩu DB, API key, SSH key, token, cookie phiên) tăng theo số service, pipeline, nhà cung cấp, và chúng rải vào code, cấu hình, hệ build, log. Các nguồn trong wiki cho thấy kẻ tấn…
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Xử lý sự cố và on-call Chủ đề Thành viên
Khi hệ còn nhỏ, vài người biết hết mọi thứ; có lỗi thì người thấy đầu tiên sửa luôn. Khi có hàng trăm service và hàng trăm engineer, câu hỏi đổi khác:
- Đổi ngôn ngữ và runtime Chủ đề Thành viên
Ngôn ngữ ban đầu được chọn để làm nhanh. Khi lớn lên, nó có thể thành nút thắt về hiệu năng, latency, hoặc tổ chức code. Có ba hướng: tối ưu runtime đang dùng, cải tiến dần, hoặc viết lại có phạm vi.
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Xác thực và phân quyền (authn/authz) Chủ đề Thành viên
Ở monolith, mỗi dữ liệu thường chỉ có một đường vào, nên kiểm tra quyền nằm ngay đó: một hàm hasaccess?, một API mỗi resource. Khi hệ thống tách thành nhiều service, nhiều client, nhiều loại token, cả hai nửa đều vỡ:
- Open Sourcing Coinbase's Secure Deployment Pipeline (Odin) Bài tóm tắt · Coinbase · 2018
…n" (tạo service mới, chờ khoẻ, xoá cái cũ); khai báo (mô tả release thành công trông thế nào, không mô tả cách deploy); scale cả dọc lẫn ngang; an toàn; thất bại êm; cấu hình giống…
- How We Upgrade Kubernetes on GKE Bài tóm tắt · Gojek · 2020
…2 minor; thử đúng bộ phiên bản trên cụm staging trước. Đọc release note, changelog mỗi lần (thường có API bị xoá). - Node pool: nâng từng zone; dùng surge upgrade (tạo node mới, đ…
- Evolution of our platform architecture Bài tóm tắt · Allegro · 2015
…ết. Nhược: chờ lâu, phụ thuộc một team, frontend chung buộc release đồng bộ, phụ thuộc giữa module mọc lại, phần kỹ thuật chung (job nền, cache) không ai sở hữu. 4. "Rubikon", micr…
- eBay Công ty Thành viên
Hai bài về nhất quán và độ bền ở eBay: protocol GRIT (2019) cho giao dịch ACID xuyên microservice và nhiều DB bằng OCC + log + áp bất đồng bộ ; và các phương án chạy Kafka đa region khi event phải đúng thứ tự (2020),…
- Mercari Công ty Thành viên
PaymentService của Merpay (2019) giữ nhất quán thanh toán qua nhiều service bằng cách tự làm ở tầng ứng dụng: chia pha + state machine, idempotency key bắt buộc, bù trừ kiểu TCC, đối soát và fault injection . Ba năm…