Tìm kiếm
40 kết quả cho “module test”. Tìm không phân biệt dấu.
- Why isn't all test automation run on the pipeline? Bài tóm tắt · Slalom Build · 2019
…t đã chạy trong mọi pipeline, nhưng test API, UI, tích hợp, module thường vẫn chạy tay trên laptop. Theo tác giả, lý do quy về ba thứ: giá trị (chưa ai tin đáng làm), kiến trúc (hệ…
- Python at Scale: Strict Modules Bài tóm tắt · Instagram · 2019
…c](https://instagram-engineering.com/python-at-scale-strict-modules-c0bb9245c834) Bài thứ ba trong series "Python at scale" (sheet chỉ trỏ bài này). Medium chặn crawler; đọc qua tr…
- Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo Bài tóm tắt · Stripe · 2026
…commit tăng. - Phân tích phụ thuộc tĩnh (theo import, theo module) dùng tốt ở các codebase khác của Stripe, nhưng Ruby có metaprogramming, dispatch động, nhánh theo cấu hình, và t…
- Service Level Testing for Microservices in Swiggy Bài tóm tắt · Swiggy · 2021
…ng API) unit test không phủ. Theo Swiggy, unit test hợp với module độc lập trong monolith, còn ở microservice phần lớn code là giao tiếp: dựng endpoint, client DB, client gọi servi…
- Acceptance Tests On CI Pipeline Bài tóm tắt · Trendyol · 2020
…u. Liên quan - · - Cùng công ty: - Cùng bài toán: (đưa test module vào pipeline bằng cách giả dependency) · ·…
- Finding Order in Chaos: How We Automated Performance Testing with Torque Bài tóm tắt · Dream11 · 2021
…t viết bằng code (Gatling, Scala), mỗi service mới thêm một module; chạy qua Jenkins job nên ai cũng dùng được (SDET, dev, DevOps) mà không cần hiểu bên trong. - Quy trình một lần…
- Building and Open-Sourcing Wix's A/B Testing System Bài tóm tắt · Wix · 2015
…st (ví dụ đọc header Accept-Language ). - Mở mã nguồn: tách module lõi (dùng chung giữa repo công khai và nội bộ) khỏi module tích hợp với hệ thống riêng của Wix (vòng đời request,…
- The Ultimate Load Test Bài tóm tắt · Tinder · 2020
…test riêng các service downstream dùng chung, vì test từng module công khai chỉ đẩy vào chúng một phần tải tổng. Kết quả: thêm vài cache, danh sách việc cần làm ở production. - Độ…
- Managing Software Dependency at Scale Bài tóm tắt · LinkedIn · 2018
…n chạy dependency test nào, bản deploy chứa version nào của module, ai còn dùng thư viện có bug nghiêm trọng. - Hệ cũ dựng trên graph database thương mại , ghi phụ thuộc ở mức prod…
- Evolving Mercari's iOS codebase into a multi-product monorepo Bài tóm tắt · Mercari · 2025
…chuyển hành vi bằng directive biên dịch, không có kiến trúc module, rồi mỗi nước fork riêng vì quá phức tạp; Mỹ bản 2 lai native + React Native, bản 3 React Native toàn bộ; Nhật vi…
- Enforcing best practice on self-serve infrastructure with Terraform, Atlantis and Policy As Code Bài tóm tắt · Loveholidays · 2021
…quản lý bằng Terraform, trong 33 repository (2021) cộng các module nội bộ (mỗi module một repo, phát hành bằng git tag) mã hoá best practice như label bắt buộc, region. - Mục tiêu:…
- Best practices can slow your application down Bài tóm tắt · Stack Overflow · 2021
…hạn; khi một thứ cực quan trọng (hiệu năng), thứ khác (tách module, test tự động) phải lùi lại. Best practice là best , không phải bắt buộc : bài toán phức tạp hoặc hỗn loạn có thể…
- Terraform Poka-Yokes: Writing Effective, Scalable, Dynamic, and Error-Resistant Terraform Bài tóm tắt · CapitalOne · 2020
…t bằng CloudFormation, CDK hay công cụ khác. - Poka-yoke 1, module hai tầng: module cấp thấp không chủ kiến (ví dụ ecs-service : service, autoscaling target, policy scale lên/xuống…
- Building a region‑aware, SEO‑friendly global web app Bài tóm tắt · Mercari · 2025
…n Protobuf + ConnectRPC , cùng giao thức với giao tiếp giữa module backend, để ít công nghệ hơn. BFF viết bằng Go, nằm ở backend nhưng sở hữu chung giữa client và backend. Theo tác…
- Behind the Global Launch: Decoding the Android Engineering Strategy for Our New App Bài tóm tắt · Mercari · 2025
…ái có app/core/feature) và library (nền dùng chung). Plugin modules-graph-assert kiểm đồ thị phụ thuộc trên CI và làm build fail nếu vi phạm: module sản phẩm không phụ thuộc sản ph…
- 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.
- 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…
- 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…
- 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…
- Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) Chủ đề Thành viên
Từ 2026 các công ty bắt đầu giao cho coding agent những việc trước đây là dự án nhiều tuần: migrate hàng trăm module hay dataset, dọn feature flag, viết lại cả framework hay app. Agent viết nhanh, nhưng ba thứ không tự…
- 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.
- Đổ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.
- 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,…
- 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ể…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- 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…
- 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…
- 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…
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- Giao dịch phân tán và nhất quán xuyên service Chủ đề Thành viên
Với một DB quan hệ, BEGIN … COMMIT lo hết. Khi dữ liệu bị chia (shard, tách service, thêm Redis bên cạnh Postgres), một thao tác nghiệp vụ chạm nhiều nơi, và câu hỏi khó nhất trở thành "timeout rồi, việc đó đã xảy ra…
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồ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ỡ:
- How Uber Executed A JUnit Migration at Massive Scale Bài tóm tắt · Uber · 2026
…huyển test suite riêng. Thay đổi chính - Nền trước: đưa mọi module test lên JUnit Platform , chạy cả test JUnit 4 (engine Vintage) lẫn JUnit 5 (Jupiter); viết test runner riêng làm…
- 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…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi replica…
- モジュラモノリスの品質を支えるリーダビリティチーム ― AI時代のスケーラブルなコード管理 (Readability team for a modular monolith in the AI era) Bài tóm tắt · Mercari · 2025
…–4, request đi từ tầng trên xuống tầng dưới, giao tiếp giữa module chuẩn hoá bằng Protobuf + gRPC. Theo tác giả, modular monolith tự nó không giải được vấn đề của thời microservice…
- Slalom Build Công ty Thành viên
Nguồn đầu tiên của Slalom Build (công ty tư vấn) trong wiki là bài đề xuất kèm proof of concept năm 2016: "Lego monolith" gom nhiều bounded context vào một repo và một đơn vị deploy, ép ranh giới bằng phụ thuộc module…
- 5-year Evolution of Ele.me's Transaction System - Part 1 Bài tóm tắt · Ele.me · 2020
…main). Bối cảnh - 2012: Zeus là một ứng dụng Python gom các module lõi (đơn hàng, user, nhà hàng) trong một repo, chạy trên cùng máy. Module đơn hàng EOS (Ele.me Order Service) có…