GitHub Spark Ngừng Tạo App Mới: Cách Export Repository Và Migration Trước Hạn

GitHub đã cập nhật tài liệu chính thức với một mốc chuyển đổi rất ngắn cho Spark: từ ngày 4/8/2026, dịch vụ không còn nhận người dùng mới và không cho tạo ứng dụng mới. Người dùng hiện hữu vẫn có thể mở và sử dụng các ứng dụng đã tạo, nhưng GitHub yêu cầu mở workbench của từng ứng dụng, chọn menu ba chấm và dùng Create repository để lưu mã nguồn trước ngày 31/8/2026. Đây không chỉ là một thay đổi về nút bấm. Với nhóm từng dùng Spark để biến prompt thành sản phẩm React, mốc này tạo ra một bài toán bàn giao gồm mã nguồn, dữ liệu, quyền truy cập, tính năng AI, tên miền, quy trình phát hành và trách nhiệm vận hành.

Bài viết này tập trung vào việc bảo toàn tài sản kỹ thuật và giảm rủi ro khi rời Spark. Mục tiêu không phải tiếp tục khởi tạo dự án mới trên một dịch vụ đã đóng luồng onboarding, mà là giúp chủ ứng dụng trả lời bốn câu hỏi: cần lấy gì ra khỏi Spark, repository nhận được có đủ để chạy độc lập hay không, dữ liệu và quyền nào chưa đi theo mã nguồn, và làm thế nào xác nhận hệ thống thay thế hoạt động đúng trước khi hết hạn. Các mốc thời gian được đối chiếu với tệp deprecation trong kho GitHub Docs chính thức; quy trình sản phẩm được đối chiếu thêm với tutorial Spark của GitHub.

GitHub Spark thay đổi điều gì và ai bị ảnh hưởng?

Thông báo của GitHub có ba ý cần tách riêng. Thứ nhất, sau ngày 4/8/2026, người chưa dùng Spark không thể tham gia như trước. Thứ hai, kể cả tài khoản đã có quyền truy cập, luồng tạo ứng dụng mới cũng bị đóng. Thứ ba, ứng dụng đã tồn tại vẫn có thể được truy cập trong giai đoạn chuyển tiếp, nhưng chủ ứng dụng phải tạo repository trước ngày 31/8/2026 nếu muốn giữ lại mã. Cụm “vẫn có thể truy cập” không nên được hiểu thành cam kết vận hành dài hạn, cũng không thay thế một bản sao do chính nhóm kiểm soát.

Nhóm chịu ảnh hưởng trực tiếp nhất là người đã publish ứng dụng bằng miền github.app, nhóm nội bộ dùng Spark làm công cụ prototype, designer hoặc product manager tạo ứng dụng mà chưa có repository, và đội kỹ thuật đã nối Spark với dữ liệu hoặc tính năng AI. Rủi ro cao hơn nếu một ứng dụng đang phục vụ người dùng thật nhưng không có người sở hữu kỹ thuật rõ ràng. Một prototype cá nhân chỉ lưu vài mục dữ liệu có thể chuyển trong vài giờ; một ứng dụng có người dùng, quyền theo tổ chức, dữ liệu ghi được và logic AI cần một kế hoạch như migration production.

Cần tránh hai phản xạ sai. Một là chỉ chụp màn hình rồi cho rằng đã sao lưu. Ảnh giúp lưu thiết kế, nhưng không giữ logic, trạng thái, dependency hay cấu hình. Hai là bấm Create repository rồi coi công việc đã xong. Repository là điều kiện cần để tiếp tục phát triển, nhưng chưa chắc chứa dữ liệu runtime, secret, cấu hình quyền, lịch sử publish hay hành vi do hạ tầng Spark cung cấp.

Việc đầu tiên: lập danh mục ứng dụng và chốt người chịu trách nhiệm

Trước khi export, hãy lập một bảng inventory duy nhất. Mỗi hàng tương ứng một Spark app, không phải một repository. Ghi tên ứng dụng, URL đang chạy, chủ tài khoản, tổ chức liên quan, đối tượng sử dụng, mức độ quan trọng, dữ liệu đang lưu, tính năng AI, thư viện ngoài, ngày kiểm tra gần nhất và người quyết định đích migration. Nếu một app được tạo chỉ để demo và không còn giá trị, đánh dấu loại bỏ có chủ ý thay vì để nó biến mất mà không ai biết.

Phân loại ứng dụng theo ba mức. Mức A là ứng dụng đang có người dùng hoặc dữ liệu cần giữ; phải export sớm, có kiểm thử và kế hoạch rollback. Mức B là prototype có khả năng tái sử dụng; cần giữ mã, tài liệu thiết kế và ảnh chụp trạng thái. Mức C là thử nghiệm đã hết giá trị; chỉ cần ghi lại quyết định đóng. Cách phân loại này ngăn đội ngũ dành thời gian ngang nhau cho mọi app trong khi thời hạn hữu hạn.

Mỗi ứng dụng mức A và B cần một người chịu trách nhiệm duy nhất. Người đó không nhất thiết tự viết mã, nhưng phải xác nhận repository đã tạo, quyền sở hữu đúng, dữ liệu đã được xử lý, bản build độc lập chạy được và stakeholder đã biết URL mới. Nếu app thuộc tài khoản cá nhân nhưng phục vụ tổ chức, hãy giải quyết quyền sở hữu trước khi migration; đừng để repository sống trong namespace mà đội ngũ không kiểm soát.

Export đúng cách bằng Create repository

Theo hướng dẫn deprecation của GitHub, thao tác trọng tâm là mở workbench của ứng dụng, chọn menu ... rồi chọn Create repository. Thực hiện từng app và ghi lại URL repository ngay khi hoàn tất. Nếu giao diện yêu cầu chọn owner, tên hoặc visibility, hãy dùng quy ước của tổ chức thay vì lựa chọn tạm thời. Repository cho ứng dụng nội bộ không nên mặc định public chỉ vì prototype trước đó dễ chia sẻ.

Sau khi tạo repository, mở tab code và xác nhận tối thiểu các thành phần: cây src, tệp entry của React, package.json, lockfile, tài nguyên tĩnh, kiểu TypeScript, cấu hình build và tài liệu README. GitHub mô tả Spark là môi trường tạo ứng dụng bằng React và TypeScript; vì vậy một repository chỉ có ảnh hoặc mã đã biên dịch là dấu hiệu export chưa đạt mục tiêu. Kiểm tra lịch sử commit và nhánh mặc định, nhưng không giả định toàn bộ lịch sử prompt đều được chuyển thành Git history.

Clone repository về một máy hoặc Codespace sạch. Cài dependency đúng theo lockfile, chạy typecheck, build production và dev server. Việc dùng môi trường sạch rất quan trọng: máy của người tạo app có thể chứa cache hoặc biến môi trường khiến lỗi bị che. Ghi lệnh đã chạy và kết quả vào issue migration. Nếu build thất bại, giữ nguyên bản export đầu tiên ở một tag hoặc nhánh bảo toàn, sau đó sửa trên nhánh riêng để luôn có điểm đối chiếu.

Nếu đội ngũ đang chuẩn hóa quy trình tự động hóa bằng GitHub, bài GitHub Agentic Workflows bằng Markdown giúp hình dung cách biến checklist thủ công thành workflow có review. Tuy vậy, với migration Spark, automation chỉ nên chạy sau khi bản export nguyên gốc đã được khóa và quyền truy cập đã được kiểm tra.

Repository chứa gì và không chứa gì?

Mã nguồn thường giúp giữ UI, component, logic phía client, khai báo dependency và một phần kết nối dịch vụ. Nó không mặc nhiên là bản sao hoàn chỉnh của môi trường Spark. Hãy xem repository như một gói bàn giao kỹ thuật cần thẩm định, không phải ảnh chụp toàn bộ hệ thống. Những thứ có thể nằm ngoài repository gồm dữ liệu key-value, secret, phiên đăng nhập, cấu hình publish, quyền theo tổ chức, telemetry, lịch sử thao tác trong workbench và tài nguyên được dịch vụ quản lý.

Đọc từng import trong dự án, đặc biệt các package hoặc API thuộc hệ sinh thái Spark. Tạo một bảng gồm tên phụ thuộc, chức năng, nơi chạy hiện tại, giải pháp thay thế và chủ sở hữu. Nếu code gọi API runtime mà nền tảng mới không có, build thành công vẫn chưa chứng minh ứng dụng hoạt động. Cần thiết kế adapter hoặc thay thế bằng dịch vụ lưu trữ, xác thực và model provider khác.

Đối chiếu giao diện đang chạy với source tree. Chọn một số luồng tiêu biểu, tìm component và handler tương ứng. Nếu UI có tính năng nhưng mã không xuất hiện, ghi lại ngay. Chụp ảnh màn hình các trạng thái chính, nhưng chỉ dùng ảnh làm bằng chứng đối chiếu. Với app quan trọng, quay video ngắn từng luồng và lưu cùng issue; video giúp tái tạo hành vi mà mã thiếu tài liệu.

Kiểm kê dữ liệu trước khi chuyển runtime

Tài liệu troubleshooting của GitHub cho biết Spark dùng một ngăn lưu trữ key-value và tổng kích thước của key cộng payload phải nhỏ hơn 512 kB cho một mục. Chi tiết này hữu ích để hiểu mô hình dữ liệu, nhưng không đồng nghĩa dữ liệu runtime sẽ tự động xuất hiện trong repository. Chủ app cần liệt kê key, kiểu dữ liệu, số bản ghi, quyền đọc/ghi, dữ liệu cá nhân và thời gian lưu. Nếu giao diện không có chức năng export trực tiếp, hãy tạo một phương án trích xuất có kiểm soát trước thời hạn hoặc liên hệ kênh hỗ trợ chính thức.

Không copy dữ liệu thật vào Git chỉ để “cho chắc”. Repository không phải kho bí mật hay cơ sở dữ liệu. Dữ liệu người dùng, token, email, nội dung nội bộ và cấu hình nhạy cảm phải được đưa vào nơi lưu trữ phù hợp, có mã hóa và kiểm soát truy cập. Trước khi chuyển, tạo checksum hoặc thống kê tổng để có thể xác nhận số lượng và tính toàn vẹn mà không đưa dữ liệu nhạy cảm vào log.

Thiết kế migration dữ liệu theo bốn bước: xuất từ nguồn, chuẩn hóa schema, nạp vào đích, rồi đối soát. Giữ bản xuất bất biến, có ngày giờ và người thực hiện. Với thay đổi schema, viết script có thể chạy lại an toàn và ghi số bản ghi thành công, bỏ qua, lỗi. Thử trên dữ liệu giả hoặc bản sao đã ẩn danh trước. Sau cutover, đặt khoảng thời gian chỉ đọc nếu có thể để tránh người dùng ghi dữ liệu vào hai nơi.

Rà soát quyền hiển thị và Data Access

Spark phân biệt ai có thể xem ứng dụng và quyền đối với dữ liệu. Một app có thể chỉ hiển thị cho chủ sở hữu, cho người dùng GitHub có liên kết hoặc cho thành viên tổ chức; đồng thời Data Access có thể cho phép xem hoặc sửa nội dung. Khi chuyển sang nền tảng khác, phải ánh xạ cả hai trục. Chỉ dựng lại trang đăng nhập mà quên quyền ghi là một lỗi nghiêm trọng: người từng chỉ xem có thể vô tình được phép sửa dữ liệu.

Lập ma trận vai trò gồm anonymous, người dùng GitHub, thành viên tổ chức, editor và admin. Với mỗi vai trò, ghi quyền xem app, đọc dữ liệu, tạo, sửa, xóa và quản trị. Sau đó ánh xạ sang hệ thống đích bằng nguyên tắc quyền tối thiểu. Nếu nền tảng mới không hỗ trợ mô hình giống hệt, chọn phương án chặt hơn trong lần phát hành đầu và mở dần sau khi xác minh.

Đừng quên quyền của repository. Repository private không tự động bảo vệ một deployment public, và repository public không có nghĩa mọi dữ liệu runtime được công khai. Kiểm tra branch protection, quyền của GitHub Actions, môi trường deployment, secret và tài khoản bot. Với pull request migration, có thể dùng quy trình review có kiểm soát như bài GitHub Copilot Code Review với Agent Skills và MCP, nhưng review AI không thay thế phê duyệt của chủ dữ liệu.

Di chuyển tính năng AI: prompt chỉ là phần nổi

Một Spark app có thể chứa tính năng AI được mô tả bằng prompt trong giao diện. Khi export, hãy tìm prompt trong code, xác định model hoặc API được gọi, đầu vào gửi đi, dữ liệu ngữ cảnh, giới hạn token, xử lý lỗi và cách hiển thị kết quả. Nếu model được Spark cung cấp gián tiếp, môi trường mới có thể cần khóa API, hợp đồng chi phí và lớp gateway riêng. Không nên hard-code secret để làm bản demo chạy nhanh.

Tạo bộ test tối thiểu cho tính năng AI: câu hỏi bình thường, dữ liệu rỗng, đầu vào rất dài, ký tự lạ, yêu cầu độc hại, timeout, rate limit và response sai cấu trúc. Ghi tiêu chí chấp nhận ở mức hành vi thay vì yêu cầu câu trả lời giống từng chữ, vì model có tính xác suất. Với ứng dụng truy cập dữ liệu nội bộ, kiểm tra prompt injection và bảo đảm model không được trao quyền ghi ngoài phạm vi cần thiết.

Nếu chuyển sang một dịch vụ model mới, hãy coi đây là migration riêng. So sánh chất lượng, latency, quota, dữ liệu được lưu, vùng xử lý, cơ chế log và khả năng tắt tính năng. Bài GitHub Models ngừng hoạt động và kế hoạch migration cung cấp một khung hữu ích để tách model endpoint khỏi ứng dụng, nhờ đó lần thay đổi nhà cung cấp sau không buộc viết lại toàn bộ UI.

Chọn đích triển khai theo kiến trúc, không theo thói quen

Không có một đích migration đúng cho mọi Spark app. Nếu repository chỉ là website tĩnh và không cần secret phía server, một hosting tĩnh có CI/CD có thể đủ. Nếu app cần xác thực, API server, dữ liệu ghi được hoặc gọi model bằng khóa bí mật, cần runtime phía server hoặc hàm serverless. Nếu app phục vụ nội bộ, ưu tiên tích hợp danh tính tổ chức, audit log và chính sách truy cập thay vì chỉ tối ưu thao tác deploy nhanh.

Đánh giá đích theo sáu tiêu chí: mức tương thích với React/TypeScript, cách quản lý secret, lưu trữ dữ liệu, xác thực, quan sát vận hành và khả năng rollback. Thêm chi phí và giới hạn nhà cung cấp vào bảng, nhưng không quyết định chỉ từ giá tháng đầu. Một nền tảng rẻ nhưng không có log hoặc backup phù hợp có thể khiến đội tốn nhiều thời gian hơn khi sự cố.

Giữ lớp ứng dụng càng portable càng tốt. Tách UI khỏi adapter lưu trữ, bọc lời gọi model trong module riêng, đọc cấu hình từ biến môi trường và tránh phụ thuộc sâu vào SDK của đích mới. Mục tiêu của lần migration không phải xóa sạch mọi phụ thuộc nền tảng, mà là làm rõ ranh giới để lần thay đổi tiếp theo có phạm vi nhỏ hơn.

Bảo mật repository trước khi build và deploy

Ngay sau export, quét repository để tìm token, khóa API, URL nội bộ, dữ liệu mẫu thật và thông tin cá nhân. Kiểm tra cả commit history, không chỉ trạng thái hiện tại. Nếu phát hiện secret, thu hồi hoặc xoay khóa trước, sau đó mới làm sạch lịch sử nếu cần. Xóa chuỗi khỏi nhánh mới không làm secret cũ mất hiệu lực.

Rà package.json và lockfile để xác định dependency đã lỗi thời, package không còn duy trì hoặc script cài đặt bất thường. Chạy audit phù hợp, nhưng đọc kết quả theo phạm vi khai thác thực tế thay vì cập nhật mù. Với package gắn chặt Spark, xác định chức năng nào là UI helper, chức năng nào gọi runtime, rồi thay từng lớp có test. Không nâng đồng thời framework, build tool và toàn bộ dependency trong cùng một commit migration nếu không bắt buộc.

Thiết lập branch protection, review bắt buộc và môi trường deploy riêng. Secret chỉ được đặt trong secret store của môi trường, phân tách development, preview và production. GitHub Actions cần quyền mặc định tối thiểu; job deploy chỉ nhận quyền khi cần. Log không được in token hoặc payload người dùng. Nếu dùng Copilot hoặc agent để sửa mã, luôn review diff và chạy test trong sandbox trước khi cho phép ghi vào production.

QA độc lập: đừng chỉ tin nút Fix all

Giao diện Spark có thể hiển thị lỗi runtime và nút Fix all. Tính năng này hữu ích trong vòng lặp prototype, nhưng migration cần một cổng chất lượng độc lập. Chạy lint, typecheck, unit test và build production trong CI. Sau đó kiểm tra thủ công các luồng quan trọng bằng trình duyệt sạch, tài khoản có vai trò khác nhau và thiết bị có kích thước màn hình khác nhau.

Tạo một bảng test theo hành trình người dùng: mở app, đăng nhập, xem dữ liệu, tạo mục, sửa, xóa, tìm kiếm, gọi AI, tải tệp và đăng xuất. Với mỗi bước, ghi dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế và bằng chứng. Kiểm tra trạng thái loading, empty, error và offline; prototype thường chỉ đẹp ở happy path. Kiểm tra keyboard, focus, label, contrast và thông báo lỗi để tránh đánh rơi accessibility khi dựng lại giao diện.

Thêm kiểm tra vận hành: health check, log ứng dụng, cảnh báo lỗi, metric latency, quota model, backup và restore. Một app build thành công nhưng không có quan sát sẽ khó hỗ trợ sau cutover. Nếu app có người dùng thật, chạy bản preview với một nhóm nhỏ, thu phản hồi và sửa trước khi đổi URL chính thức.

Kế hoạch thực hiện từ nay đến hạn 31/8/2026

Giai đoạn 1 — bảo toàn, thực hiện ngay: khóa danh sách Spark app, phân mức A/B/C, chỉ định owner, tạo repository, clone về nơi do đội kiểm soát và gắn tag cho bản export gốc. Chụp trạng thái publish, quyền hiển thị, Data Access và các luồng chính. Với app quan trọng, tạo bản sao dữ liệu hoặc yêu cầu hỗ trợ trước khi thời gian còn lại quá ngắn.

Giai đoạn 2 — thẩm định: build trong môi trường sạch, lập bản đồ dependency, xác định dịch vụ Spark còn được gọi, kiểm kê secret, dữ liệu và model. Chọn đích triển khai dựa trên kiến trúc. Ước lượng công việc theo từng rủi ro thay vì theo số dòng code. Một app ít code nhưng phụ thuộc dữ liệu và quyền có thể khó hơn app giao diện lớn.

Giai đoạn 3 — thay thế và kiểm thử: viết adapter, chuyển dữ liệu, cấu hình auth, CI/CD và observability. Chạy bộ test chức năng, bảo mật, accessibility và hiệu năng. Mở preview cho stakeholder, chốt tiêu chí go/no-go. Mọi lỗi chặn phải có owner và deadline.

Giai đoạn 4 — cutover và hậu kiểm: thông báo URL mới, đặt hệ thống cũ ở chế độ hạn chế ghi nếu có thể, chuyển traffic, theo dõi lỗi và đối soát dữ liệu. Giữ kế hoạch rollback trong một khoảng xác định. Sau khi ổn định, đóng secret cũ, cập nhật tài liệu, chuyển quyền sở hữu repository cho đúng tổ chức và ghi quyết định lưu hoặc xóa tài sản cũ.

Checklist migration GitHub Spark

• Đã liệt kê mọi Spark app cùng URL, owner, người dùng và mức độ quan trọng.
• Đã dùng menu ba chấm và Create repository cho từng app cần giữ trước hạn.
• Đã xác nhận repository đúng owner, visibility, nhánh mặc định và quyền nhóm.
• Đã clone vào môi trường sạch, cài dependency, typecheck và build production.
• Đã giữ tag hoặc nhánh bất biến của bản export nguyên gốc.
• Đã tìm dependency Spark, API runtime và phần code cần adapter.
• Đã kiểm kê key-value data, dữ liệu cá nhân, schema và phương án đối soát.
• Đã tách secret khỏi mã, xoay khóa bị lộ và cấu hình secret store.
• Đã ánh xạ Visibility và Data Access sang vai trò ở hệ thống đích.
• Đã kiểm kê prompt, model, quota, timeout và chính sách dữ liệu AI.
• Đã chọn hosting theo nhu cầu server, auth, storage và observability.
• Đã chạy test happy path, error path, accessibility và phân quyền.
• Đã có backup, rollback, owner trực vận hành và thông báo URL mới.
• Đã xác nhận stakeholder chấp nhận trước khi đóng hoặc bỏ Spark app.

Những lỗi migration thường gặp

Đợi gần hạn mới export. Nếu repository thiếu thành phần hoặc tài khoản gặp lỗi quyền, đội ngũ không còn thời gian xử lý. Export sớm không buộc cutover sớm; nó chỉ tạo một bản sao an toàn.

Cho rằng Create repository mang theo dữ liệu. Mã và dữ liệu là hai tài sản khác nhau. Phải xác minh bằng read-back và đối soát, không suy luận từ việc cây tệp xuất hiện.

Deploy ngay repository nguyên trạng. Mã prototype có thể dùng API nền tảng, thiếu secret, thiếu xử lý lỗi hoặc quyền quá rộng. Luôn build và test trong môi trường đích trước.

Giữ nguyên mọi dependency vì sợ thay đổi. Một số dependency có thể gắn với runtime cũ. Giữ nguyên bản export để đối chiếu, sau đó thay có kiểm soát trên nhánh migration.

Chỉ kiểm tra bằng tài khoản admin. Lỗi quyền thường không xuất hiện với người có quyền cao. Cần test anonymous, member, editor và admin riêng.

Dùng AI review thay cho quy trình phát hành. Copilot có thể giúp tìm lỗi và giải thích diff, nhưng con người vẫn phải phê duyệt quyền, dữ liệu và cutover. Bài Copilot trong VS Code với worktree và multi-chat cho thấy cách tách nhánh làm việc của agent để giảm xung đột; nguyên tắc đó phù hợp khi sửa bản export Spark.

Câu hỏi thường gặp

Sau ngày 4/8/2026, app Spark cũ có dùng được không?

Theo thông báo GitHub, người dùng hiện hữu vẫn có thể truy cập và dùng các app đã tạo trong giai đoạn chuyển tiếp. Tuy nhiên, việc tạo app mới bị dừng và GitHub yêu cầu tạo repository trước 31/8/2026. Vì vậy không nên coi khả năng truy cập hiện tại là phương án lưu trữ dài hạn.

Create repository có phải là backup hoàn chỉnh không?

Không nên giả định như vậy. Repository giúp lưu mã nguồn, nhưng dữ liệu runtime, secret, quyền publish và dịch vụ do Spark quản lý có thể nằm ngoài Git. Hãy kiểm kê và kiểm thử từng lớp.

Có nên chuyển ngay sang một nền tảng vibe coding khác?

Chỉ sau khi đã bảo toàn mã và hiểu kiến trúc. Chọn nền tảng mới theo runtime, dữ liệu, auth, AI, log, backup và khả năng rời đi lần sau; đừng chỉ so sánh trải nghiệm prompt.

Nếu app chỉ là prototype, có cần migration đầy đủ?

Không nhất thiết. Với prototype mức B, repository, ảnh chụp, README về mục tiêu và quyết định lưu trữ có thể đủ. Điều quan trọng là quyết định có chủ ý và có owner, thay vì để tài sản biến mất.

Nếu repository build không chạy thì nên làm gì?

Giữ nguyên bản export, ghi log lỗi, kiểm tra phiên bản Node, package manager, lockfile, biến môi trường và dependency Spark. Sửa trên nhánh riêng, thêm test và không trộn nâng cấp lớn không liên quan vào cùng commit.

Nhóm cần hoàn thành tối thiểu điều gì trước 31/8?

Tối thiểu phải biết có bao nhiêu app cần giữ, tạo repository cho từng app, xác nhận quyền sở hữu, clone được mã và ghi lại dữ liệu hoặc dịch vụ chưa đi theo repository. Với app đang phục vụ người dùng, cần thêm kế hoạch runtime, bảo mật, kiểm thử và cutover.

Kết luận

Việc GitHub Spark dừng nhận người dùng và app mới biến “để sau tính” thành một rủi ro có ngày hết hạn. Hành động có giá trị nhất là tạo repository ngay, nhưng chất lượng migration được quyết định ở những bước sau đó: kiểm kê dữ liệu, tách phụ thuộc runtime, ánh xạ quyền, bảo vệ secret, kiểm thử độc lập và chuẩn bị rollback. Nếu thực hiện theo thứ tự bảo toàn trước, thẩm định sau, thay thế có kiểm soát và cuối cùng mới cutover, đội ngũ có thể biến một thông báo deprecation thành cơ hội chuẩn hóa ownership và khả năng vận hành.

Nguồn cần đánh dấu trong issue migration gồm thông báo deprecation chính thức, hướng dẫn xây dựng và quản lý Spark app, tài liệu troubleshooting Spark và trang sản phẩm GitHub Spark. Hãy lưu ngày kiểm tra cùng liên kết, vì tài liệu chuyển tiếp có thể tiếp tục được cập nhật.