Tìm kiếm
40 kết quả cho “Deploy trước merge”. Tìm không phân biệt dấu.
- How GitHub uses merge queue to ship hundreds of changes every day Bài tóm tắt · GitHub · 2024
…tính năng sản phẩm của họ; số liệu tự đo. Bối cảnh - GitHub deploy trước rồi mới merge . Năm 2016, monorepo lớn đã có gần 1.000 PR merge mỗi tháng, nên họ cần gom nhiều PR deploy c…
- 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.
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- Stack Overflow: How We Do Deployment - 2016 Edition Bài tóm tắt · Stack Overflow · 2016
…s://nickcraver.com/blog/2016/05/03/stack-overflow-how-we-do-deployment-2016-edition/) Bài 3 trong series của Nick Craver. Bài trước: ; bài sau: . Bối cảnh Số liệu 2016: - khoảng 25…
- How we deploy to production over 100 times a day Bài tóm tắt · Monzo · 2022
…hó: Dễ — [bài gốc](https://monzo.com/blog/2022/05/16/how-we-deploy-to-production-over-100-times-a-day) Bối cảnh - Theo Monzo, công ty lớn lên thường chậm lại: chi phí của lỗi tăng…
- Improving how we deploy GitHub Bài tóm tắt · GitHub · 2021
…— [bài gốc](https://github.blog/2021-01-25-improving-how-we-deploy-github/) Bối cảnh - Trong một năm, số developer đóng góp vào app GitHub.com tăng gấp đôi , và công cụ deploy cũ k…
- GitHub Enterprise Cloud with data residency: How we built the next evolution of GitHub Enterprise using GitHub Bài tóm tắt · GitHub · 2024
…Hub để làm); phần kỹ thuật chủ yếu là cách mở rộng pipeline deploy sang target mới. Bối cảnh - Doanh nghiệp muốn kiểm soát dữ liệu của mình nằm ở vùng địa lý nào. GitHub làm Enterp…
- Fleet Management at Spotify (Part 3): Fleet-wide Refactoring Bài tóm tắt · Spotify · 2023
…và check; theo dõi sức khoẻ component sau merge qua sự kiện deploy. Rollout rất chậm: đầu tiên chỉ cho shift BOM, chia backend theo mức quan trọng và bật dần từng nhóm. Mặc định bậ…
- Argo Rollouts at scale: Bringing Automated Rollbacks to 2,100+ services at Monzo Bài tóm tắt · Monzo · 2022
…h) theo đuổi microservices: hơn 2.100 service, hơn 100 lượt deploy/ngày, hơn 27.000 lượt deploy trong năm 2021 . - Deploy bằng một lệnh CLI. Đã có nhiều lớp bắt lỗi, nhưng vẫn dựa…
- 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…
- Fleet Management at Spotify (Part 1): Spotify's Shift to a Fleet-First Mindset Bài tóm tắt · Spotify · 2023
…g production được nạp vào BigQuery để truy vấn (dependency, deploy, container, lỗ hổng). 2. Mọi thứ đã nằm trong version control chưa? Code thì rồi, nhưng nhiều resource cloud (buc…
- Smart alerts in ThirdEye, LinkedIn's real-time monitoring platform Bài tóm tắt · LinkedIn · 2019
…alert. - Notification flow: suppression trong lúc bảo trì, deploy, ngày lễ (chỉ báo khi lệch ngoài khoảng kỳ vọng); gửi theo chiều (lỗi Android tới on-call Android); kênh email ho…
- PostgreSQL Stories: From slow query to fast, via stats Bài tóm tắt · Render · 2024
…của một câu chuyện; phần 1 (tìm ra query làm treo pipeline deploy staging) chưa có trong wiki. Đây là DB nội bộ của Render, không phải sản phẩm Postgres cho khách. Bối cảnh - Pipe…
- 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…
- 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…
- 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ó…
- 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.
- 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.
- 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…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- 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:
- 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ả…
- 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,…
- Hạ tầng tìm kiếm Chủ đề Thành viên
Lúc đầu, tìm kiếm là LIKE trên database hoặc một thư viện (Lucene) nhúng trong app. Khi dữ liệu và tính năng tăng, search thành một hệ có trạng thái riêng, khác database ở mấy điểm:
- 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…
- 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:
- Độ 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.
- 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…
- Query planner và hiệu năng truy vấn Chủ đề Thành viên
Database quan hệ không chạy SQL theo đúng cách nó được viết. Query planner chọn một plan (dùng index nào, join kiểu gì: nested loop, merge, hash; dừng sớm khi có LIMIT hay không) dựa trên thống kê về dữ liệu: số dòng,…
- 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:
- 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…
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- GitHub Công ty Thành viên
Rails + một MySQL; sau đó tách vài tính năng, thêm replica, ProxySQL; nhưng lõi vẫn là cluster mysql1 được scale dọc liên tục. Từ 2019 họ tách ảo bằng schema domain + linter rồi dời vật lý bằng Vitess hoặc write-cutover…
- Stack Overflow Công ty Thành viên
Phản ví dụ nên đọc sớm cho niềm tin "lớn thì phải scale out". Năm 2009, với 16 triệu page view mỗi tháng, Stack Overflow chạy hai web server và một SQL Server, chạm giới hạn thì nâng RAM; theo Jeff Atwood, phần cứng rẻ…
- GitLab's unconventional journey to CI/CD and Kubernetes Bài tóm tắt · GitLab · 2019
…làm tay: - đồng bộ nhiều repo; - tạo branch, gắn version; - deploy lên GitLab.com rồi publish package cho bản self-managed. Mỗi lần mất từ nửa ngày tới vài ngày. - Khảo sát 2018: t…
- GoCD on Kubernetes Bài tóm tắt · Disney Hotstar · 2020
…rm Team ở Hotstar: tự động hoá mọi bước can thiệp tay trong deploy, từ lúc merge vào trunk tới production. Muốn vậy, không chỉ code mà cả script deploy, hạ tầng, cấu hình ứng dụng…
- Building an Effective Test Pipeline in a Service Oriented World Bài tóm tắt · Airbnb · 2020
…service trong môi trường dev riêng. Lý do: chưa có pipeline deploy kiểm soát thứ tự, nên master xấu có thể lên thẳng production. Vấn đề khi số service và test tăng - CI ngày càng c…
- The Legends of Runeterra CI/CD Pipeline Bài tóm tắt · Riot Games · 2021
…ient Unity + game server). Wiki giữ phần hạ tầng build/test/deploy, bỏ qua chi tiết riêng của client. Bối cảnh - Legends of Runeterra (2021): monorepo Git LFS khoảng 100 GB, một tr…