Tìm kiếm
40 kết quả cho “Velo”. Tìm không phân biệt dấu.
- How LinkedIn handles merging code in high-velocity repositories Bài tóm tắt · LinkedIn · 2020
…đang hoạt động, có repo hơn 300 commit/ngày . Trunk-based development. - Ba ràng buộc: nhánh chính ( primary ) luôn xanh; commit vào nhanh; hệ phải tốt cho cả repo rất bận lẫn repo…
- Designing a Better Kubernetes Experience for Developers Bài tóm tắt · Spotify · 2021
…m/2021/03/01/designing-a-better-kubernetes-experience-for-developers/) Bài ngắn, nửa giới thiệu plugin mã nguồn mở của Backstage. Không có số liệu quy mô; ý chính là sự tách vai gi…
- Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents Bài tóm tắt · Spotify · 2026
…PI, vá lỗ hổng), và migration là nguồn bực bội số một của developer. Từ đó có Fleet Management/Fleetshift (xem ). - Script tất định đủ cho thay đổi đơn giản nhưng gãy với thay đổi…
- Moving Velo to Multiple Container Sites: The Why, The How and The Lessons Learned Bài tóm tắt · Wix · 2021
…ng bình — [bài gốc](https://www.wix.engineering/post/moving-velo-to-multiple-container-sites-the-why-the-how-and-the-lessons-learned) Bối cảnh - Velo (trước gọi là Corvid) cho ngườ…
- Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity Bài tóm tắt · Shopify · 2019
…ring/deconstructing-monolith-designing-software-maximizes-developer-productivity) Bối cảnh - Một trong những codebase Rails lớn nhất thế giới: hơn 10 năm, hơn 1.000 developer. Ban…
- Scaling Production Globally: Solving observability problems for developers (Part-2) Bài tóm tắt · Achievers · 2022
…ng-production-globally-solving-observability-problems-for-developers-part-2-b5416ce5eb8a) Phần 2 của series; phần 1 (service mesh Istio đa region): . Lấy từ bản Wayback (Medium chặ…
- 開発者全員が書けるE2Eテスト ─ 普通のgo testで実現するテスト基盤 (E2E tests every developer can write, with plain go test) Bài tóm tắt · Mercari · 2025
…thì test cập nhật sau, thêm test chậm nên coverage giảm, developer không hiểu test nên khó debug. Thêm các vấn đề quen thuộc: dựng môi trường phức tạp, chạy song song thì tranh tà…
- How the Miro Developer Platform leverages contract testing Bài tóm tắt · Miro · 2023
…bài gốc](https://medium.com/miro-engineering/how-the-miro-developer-platform-leverages-contract-testing-91fae20987d1) Bối cảnh - Miro Developer Platform 2.0 (REST API công khai) ra…
- Migrating Doximity's iOS Newsfeed to SwiftUI Without Disrupting Users or Development Bài tóm tắt · Doximity · 2026
…ity-s-ios-newsfeed-to-swiftui-without-disrupting-users-or-development) Bối cảnh - Newsfeed là màn hình được dùng nhiều nhất của app iOS. Feed là server-driven : server chọn card, s…
- Building Git infrastructure for agent-scale development Bài tóm tắt · GitHub · 2026
…-optimization/building-git-infrastructure-for-agent-scale-development/) Bài định hướng, mở đầu series: nêu bài toán và nguyên tắc thiết kế; chi tiết kiến trúc mới hẹn ở bài sau. Số…
- Catching bugs on the client-side: how we developed our error tracking system Bài tóm tắt · Bumble · 2020
Bumble và Badoo có web (desktop, mobile) và app Android, iOS với hàng triệu người dùng. Web phát hành 1–2 lần mỗi ngày, app native khoảng một lần 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…
- Code caching for JavaScript developers Bài tóm tắt · V8 (Google) · 2019
Parse + compile JavaScript chiếm phần đáng kể thời gian khởi động trang. Code cache lưu kết quả (bytecode) để lần sau bỏ qua bước đó.
- Tracing Discord's Elixir Systems (Without Melting Everything) Bài tóm tắt · Discord · 2026
…tadata tương đương. Thay đổi chính - Thư viện Transport + Envelope: bọc message trong một struct có trường trace carrier (context đã serialize). Cung cấp bản thay thế cho GenServer…
- How we deliver mobile app updates faster Bài tóm tắt · Mercari · 2025
…rge dần vào master, tính năng ẩn sau flag riêng; xong thì developer và QA thử, rồi bật dần qua flag . Vì master luôn ổn định nên cắt bản lúc nào cũng được. - Release train hằng tuầ…
- Building Scalable Real Time Event Processing with Kafka and Flink Bài tóm tắt · DoorDash · 2022
…g CD biên dịch và deploy). - Định dạng event thống nhất : envelope (ngữ cảnh, metadata, tham chiếu schema, phần JSON không schema để đổi linh hoạt) + payload. Envelope nằm trong Ka…
- How GitHub uses merge queue to ship hundreds of changes every day Bài tóm tắt · GitHub · 2024
…ngoài (ChatOps, label). Thay đổi chính - Yêu cầu từ 2020: developer chỉ cần nói "tôi muốn ship" và "tôi chuyển sang việc khác"; PR có vấn đề không được làm chậm tất cả PR khác ( ưu…
- Predictive test selection Bài tóm tắt · Meta · 2018
…ng bình — [bài gốc](https://engineering.fb.com/2018/11/21/developer-tools/predictive-test-selection/) Bài ngoài sheet. Có bài báo đi kèm (arXiv 1810.05286). Số liệu do Facebook tự…
- How we achieved independent deployments in a micro-frontend architecture Bài tóm tắt · Allegro · 2026
…anh, chỉ xoá khi không môi trường nào dùng. - Thành phần: Developer Portal (Backstage) để quản lý phiên bản; Dependencies Registry giữ trạng thái bật/tắt và lịch sử; Validator kiểm…
- Using Fault Injection Testing to Improve DoorDash Reliability Bài tóm tắt · DoorDash · 2022
…vọng cho lúc dependency lỗi, nên khi assertion thất bại, developer buộc phải quyết định hệ thống nên làm gì rồi ghi lại bằng assertion có điều kiện ("service X sập thì trả mã Y").…
- How Deterministic Controls Turn AI Output Into Reliable Prompt Templates Bài tóm tắt · Salesforce · 2026
…h danh bản ghi: model không bao giờ cầm ID ; nó viết theo developer name ổn định, lớp transpose phía server khớp với bản ghi có sẵn và gắn lại đúng ID. - Định dạng output: server b…
- Coding Had a Concurrency Problem: How Mux Helped Solve It Bài tóm tắt · Coinbase · 2026
Đầu 2026 mọi engineer Coinbase có Cursor, Copilot, OpenCode, Claude Code. Agent viết nhanh nhưng quy trình vẫn tuần tự: một branch, một terminal, một việc; agent làm thì người chờ; đổi việc thì stash, đổi branch, mất…
- Introducing Grab-Kit: Distributed Service Design at Grab Bài tóm tắt · Grab · 2018
Sau khi tách monolith thành microservices, Grab gặp bài toán mới: tăng trưởng theo cấp số nhân mà vẫn giữ được sự nhất quán. Các service có API, SDK, xử lý lỗi, transport khác nhau; log mỗi nơi một định dạng; không truy…
- Reducing local dev time by 83%: Why we migrated off Next.js Bài tóm tắt · Inngest · 2026
Inngest từng chuyển từ Vite sang Next.js "trong chưa tới một ngày", dùng App Router từ bản beta và React Server Components (RSC) với lời hứa bỏ được màn hình trống và network waterfall của SPA.
- How we deploy to production over 100 times a day Bài tóm tắt · Monzo · 2022
Theo Monzo, công ty lớn lên thường chậm lại: chi phí của lỗi tăng nên thêm quy trình phê duyệt, nhiều người đụng vào cùng hệ, nhiều người mới phải hiểu hệ. Hậu quả là engineer gom thay đổi thành bản phát hành lớn, vừa…
- Building visibility into a CI platform Bài tóm tắt · Optiver · 2026
Lượng code qua pipeline của Optiver tăng mạnh vài năm gần đây, không chỉ do software engineer: researcher và trader cũng viết code (visualisation, thí nghiệm, tự động hoá phân tích) qua cùng pipeline build/test, và AI…
- Secret Management Architectures: Finding the balance between security and complexity Bài tóm tắt · Slalom Build · 2017
Nhiều team để secret dạng plain text trong code hoặc file cấu hình, chỉ dựa vào việc repo là private. Slalom đề nghị tự hỏi: nhân viên nghỉ thì rotate secret có dễ không, bị lộ thì mất bao lâu để khoanh vùng, có audit…
- Fulfilling the promise of CI/CD Bài tóm tắt · Stack Overflow · 2021
Theo tác giả, ai cũng nói "CI/CD" nhưng thực ra chỉ làm CI; gần như không ai thực hành continuous deployment. Mục đích của CI vốn là dọn đường cho CD.
- 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…
- 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.
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- 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.
- 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.
- 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:
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- 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…
- 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…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Tracing phân tán và log theo request Chủ đề
Khi một request đi qua hàng chục service, metric của từng service cho biết có chậm, log của từng service cho biết từng mảnh; không cái nào trả lời "request này chậm vì đâu" hay "trang này tốn bao nhiêu". Tracing phân…
- 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ỡ: