Kiểm soát nguồn
Kết nối tài khoản GitHub hoặc GitLab mà bạn làm việc và triển khai trực tiếp từ một nhánh: tới Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps hoặc AWS Amplify — hoặc lên dịch vụ lưu trữ được quản lý của chính chúng tôi, nơi kho lưu trữ và các tệp của trang web luôn được đồng bộ hóa theo cả hai hướng. Mỗi kết nối đều hiển thị các đặc quyền cần thiết, được kiểm tra đối chiếu với API của nhà cung cấp trước khi được lưu trữ và nằm trong Vault. Bạn cũng có thể đăng nhập bằng GitHub hoặc GitLab.
Kết nối là một thông tin xác thực mà quý vị đang giao cho người khác. Hệ thống của chúng tôi nêu rõ những gì cần thiết trước khi quý vị tạo nó, chứng minh nó hoạt động trước khi lưu trữ, và có thể thu hồi từ bất kỳ đầu nào.
Trước khi quý vị tạo mã token, chúng tôi sẽ cho quý vị biết mã đó cần phải làm được những gì và tại sao. Không có phạm vi bao quát chỉ vì dễ yêu cầu hơn, và không có chuyện sau đó mới phát hiện ra rằng chúng tôi cần nhiều hơn mức công việc đòi hỏi.
Chúng tôi gọi API của chính nhà cung cấp bằng mã thông báo của quý vị trước khi lưu trữ. Mã thông báo không chính xác, hết hạn hoặc sai phạm vi sẽ bị từ chối ngay tại biểu mẫu thay vì được chấp nhận, hiển thị là hoạt động tốt rồi thất bại ở lần triển khai thực tế đầu tiên.
Không có trong mã của chúng tôi, không có trong tệp môi trường, không có trong nhật ký và không có trên dòng lệnh. Được giải quyết ngay tại thời điểm nó được sử dụng, bởi khối lượng công việc sử dụng nó.
Kết nối tài khoản cá nhân và tài khoản tổ chức, hoặc hai tài khoản tổ chức. Mỗi trang web sẽ chọn tài khoản dùng để triển khai, vì vậy kho lưu trữ của khách hàng và của riêng bạn không bao giờ dùng chung thông tin đăng nhập.
Tám máy chủ biên được quản lý và đội ngũ phần cứng của riêng chúng tôi. Đích đến là một thuộc tính của trang web chứ không phải của kết nối, vì vậy cùng một kho lưu trữ có thể xuất bản một nhánh lên máy chủ Pages và một trang web khác có thể chạy trên phần cứng của chúng tôi.
Băng thông không giới hạn, cho phép sử dụng cho mục đích thương mại và quản lý tên miền đỉnh (apex domain) trên cùng nhà cung cấp thường nắm giữ vùng DNS của quý vị. Đó là điểm đến đầu tiên chúng tôi tìm tới, vì những lý do đó.
Lưu trữ Cloudflare Pages →Xuất bản trực tiếp từ kho lưu trữ vốn đã chứa mã nguồn. Được gắn cờ trên dòng Footprint-Free, vì cơ sở hạ tầng github.io dùng chung bản thân nó đã là một dấu vết.
Lưu trữ GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps và AWS Amplify đều là các đích đến mà bạn có thể trỏ trang web tới, với cùng một kết nối và cùng một lịch sử triển khai.
Lưu trữ trang web tĩnh →Một ứng dụng hoàn chỉnh thay vì một gói đã biên dịch — WordPress, PHP, Node. Đây là đích đến nhận đồng bộ hai chiều, để các tệp trên máy chủ và nhánh luôn đồng nhất.
Hosting được quản lý →Một trang web được xuất bản tới một máy chủ lưu trữ mà chúng tôi không sở hữu vẫn sử dụng hạn mức và vẫn xuất hiện trong trang tổng quan của quý vị cùng với các lần triển khai, thời gian hoạt động và dữ liệu SEO của trang đó bên cạnh mọi thứ khác mà quý vị vận hành.
Hạn mức trang web bên ngoài →Trình biên tập trong trình duyệt hoạt động trên cùng các tệp mà tính năng đồng bộ hóa hai chiều đẩy về, do đó, một bản sửa lỗi nhanh từ trang tổng quan sẽ trở thành một commit trên nhánh của quý vị thay vì là một thay đổi mà sau này không ai có thể tìm thấy.
Trình chỉnh sửa web →Đồng bộ hóa hai chiều
Hãy bật tính năng này và các tệp của chính trang web sẽ được commit trở lại nhánh của quý vị, trong khi các commit trên nhánh đó sẽ được chuyển ngược lại trang web. Tính năng này hoạt động trên mọi trang web chúng tôi lưu trữ, trên mọi đường truyền — yêu cầu duy nhất là máy chủ bên dưới có thể chạy Git đối với các tệp của nó, điều này được truy vấn từ máy chủ thay vì chỉ giả định dựa trên gói dịch vụ.
Quý khách chọn thư mục nào được đồng bộ hóa, bởi vì khách hàng WordPress muốn theo dõi chủ đề của họ chứ không phải bốn mươi nghìn tệp cốt lõi. Và tính năng này sẽ tắt cho đến khi quý khách bật: việc kích hoạt đồng bộ hóa là một quyết định liên quan đến kho lưu trữ của người khác, và quá trình di chuyển không bao giờ được phép quyết định thay cho quý khách.
Hai chế độ, và điểm khác biệt là nơi tiến trình xây dựng chạy. Cả hai đều kết thúc tại cùng một điểm: một ref mà chúng tôi tìm nạp và xuất bản, với commit được ghi lại cho lần triển khai đó.
GitHub hoặc GitLab, trong mục Kết nối. Các đặc quyền được liệt kê trước khi bạn tạo mã thông báo và mã này sẽ được kiểm tra với nhà cung cấp trước khi được lưu trữ.
Chủ sở hữu, kho lưu trữ, nhánh, và việc chúng tôi xuất bản một thư mục hay tìm nạp những gì CI của bạn đã xây dựng. Chúng tôi đăng ký webhook đẩy như một phần của quá trình đó.
Một lần push vào nhánh được chỉ định sẽ bắt đầu quá trình triển khai, hoặc quý vị có thể triển khai theo yêu cầu từ tab Triển khai của trang web. Quá trình bản dựng chạy trong nền.
Lịch sử triển khai cho biết nội dung gì đã được xuất bản và vào thời điểm nào. Bật tính năng đồng bộ hóa hai chiều và các chỉnh sửa bạn thực hiện tại đây sẽ quay trở lại dưới dạng các commit trên nhánh của bạn.
Khi xảy ra sự cố
Một kết nối kho lưu trữ trông có vẻ bình thường nhưng không nhận được gì là lỗi âm thầm kinh điển — một mã thông báo sai phạm vi, một lượt phân phối bị chặn tại nhà cung cấp, một webhook mà ai đó đã gỡ bỏ thủ công. Lỗi này vô hình trên mọi màn hình khác, vì vậy thẻ kho lưu trữ sẽ hiển thị trực tiếp: thời điểm nhà cung cấp gửi dữ liệu cho chúng tôi lần gần nhất và nội dung phản hồi là gì.
Các lượt phân phối đều được kiểm tra chữ ký trước khi chúng tôi xử lý, theo cơ chế riêng của từng nhà cung cấp thay vì cơ chế mà chúng tôi giả định là áp dụng cho tất cả. Lượt phân phối không xác minh được sẽ bị từ chối và ghi lại, chứ không bị âm thầm bỏ qua.
Danh tính
Bên cạnh địa chỉ email và mật khẩu, quý khách có thể đăng nhập vào tài khoản Zinn Digital® của mình bằng GitHub, GitLab, Google hoặc Microsoft. Lớp định danh thực hiện quá trình bắt tay; chúng tôi không bao giờ nhìn thấy mật khẩu nhà cung cấp của quý khách, và việc liên kết tài khoản mạng xã hội với tài khoản Zinn® hiện có vẫn phải được xác nhận qua email.
Đăng nhập bằng GitHub và kết nối GitHub cho việc triển khai là các quyết định riêng biệt và thông tin xác thực riêng biệt. Thực hiện việc này không có nghĩa là thực hiện việc kia, và xóa việc này cũng không xóa việc kia.
GitHub và GitLab. Hãy kết nối tài khoản mà quý vị đang làm việc và chúng tôi có thể triển khai từ các kho lưu trữ của tài khoản đó, đăng ký một webhook đẩy trên chúng, và — nếu quý vị muốn — đồng bộ hóa các tệp của trang web ngược trở lại. Cả hai đều đi qua cùng một điểm nối tài khoản đã kết nối, vì vậy mọi điều dưới đây đều đúng với cả hai.
Có, và với cả Google hoặc Microsoft. Cùng với địa chỉ email và mật khẩu, quý khách có thể đăng nhập vào tài khoản Zinn Digital® của mình bằng bất kỳ phương thức nào trong bốn phương thức này. Lớp định danh sẽ xử lý quá trình bắt tay và chúng tôi không bao giờ nhìn thấy mật khẩu nhà cung cấp của quý khách. Việc đăng nhập bằng GitHub là hoàn toàn tách biệt với việc kết nối GitHub để triển khai — quý khách có thể chọn một trong hai, cả hai hoặc không chọn cái nào.
Đến Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps hoặc AWS Amplify cho một trang web tĩnh hoặc đã được xây dựng — hoặc trên dịch vụ lưu trữ do chính chúng tôi quản lý, nơi kho lưu trữ và các tệp của trang web luôn được đồng bộ hóa theo cả hai hướng. Quý khách chọn đích đến cho trang web; kết nối kho lưu trữ đều giống nhau trong cả hai trường hợp.
Cách nào cũng được. Ở chế độ xuất bản, chúng tôi tiếp nhận nhánh ở trạng thái nguyên bản và xuất bản thư mục mà quý khách chỉ định. Ở chế độ CI, quy trình riêng của nhà cung cấp của quý khách sẽ chạy lệnh xây dựng và xác nhận kết quả đầu ra vào một nhánh xuất bản riêng biệt, sau đó chúng tôi sẽ tìm nạp nhánh này như bất kỳ ref nào khác. Cách thứ hai giữ bản dựng trong chính CI của quý khách, nơi đã có sẵn các thông tin bảo mật và bộ nhớ đệm của quý khách.
Theo mặc định, có — chúng tôi đăng ký một webhook trên kho lưu trữ và thao tác push vào nhánh bạn đã chỉ định sẽ bắt đầu quá trình triển khai. Bạn có thể tắt tính năng đó và giữ lại webhook, điều này hữu ích hơn bạn nghĩ: lượt gửi vẫn được ghi lại, vì vậy bạn có thể theo dõi các lượt push gửi đến trước khi cho phép chúng tôi xử lý chúng.
Những chỉnh sửa được thực hiện trên phần cứng của chúng tôi sẽ trở thành các commit trên nhánh của quý vị, và các commit trên nhánh của quý vị sẽ quay trở lại trang web. Tính năng này sẽ tắt cho đến khi quý vị bật lên, vì việc bật tính năng này là một quyết định liên quan đến kho lưu trữ của người khác và chúng tôi sẽ không đưa ra quyết định đó thay cho quý vị. Quý vị chọn thư mục nào được đồng bộ hóa — thường là một giao diện hoặc một tiện ích mở rộng, chứ không phải bốn mươi nghìn tệp cốt lõi của WordPress.
Không có gì bị ghi đè và không có gì được đẩy lên. Quá trình đồng bộ hóa sẽ dừng lại, thông báo cho quý vị biết rằng nhánh đã vượt qua commit mà chúng tôi dựa vào, và hỏi quý vị muốn giữ bên nào — giữ lại kho lưu trữ hay giữ lại trang web. Một trang web chưa từng được đồng bộ hóa và trỏ đến một nhánh đã có các commit cũng là một trạng thái riêng, và hệ thống sẽ hỏi thay vì đoán xem đâu là dữ liệu chính xác.
Chúng tôi hiển thị cho quý vị các đặc quyền mà kết nối cần trước khi quý vị tạo kết nối, kiểm tra mã thông báo với API của chính nhà cung cấp khi nhập — nhờ đó mã thông báo không hợp lệ hoặc sai phạm vi sẽ không bao giờ được lưu trữ — và chỉ sau đó mới ghi vào Vault. Mã thông báo không bao giờ chạm vào mã nguồn, nhật ký, tệp môi trường hoặc dòng lệnh của chúng tôi. Hãy thu hồi mã tại nhà cung cấp hoặc xóa kết nối tại đây bất cứ khi nào quý vị muốn.
Thẻ kho lưu trữ hiển thị thời điểm nhà cung cấp phân phối cho chúng tôi lần cuối và nội dung đã gửi. Chưa từng được phân phối là thông tin chẩn đoán hữu ích nhất trên màn hình đó, vì "đã kết nối nhưng chưa từng được phân phối" chính là biểu hiện của mã thông báo bị đặt sai phạm vi hoặc quá trình phân phối bị chặn — và thông tin này không hiển thị ở bất kỳ nơi nào khác. Mọi lượt phân phối đều được kiểm tra chữ ký trước khi chúng tôi xử lý.
Tính năng này được cung cấp và bị gắn cờ cảnh báo. GitHub Pages và GitLab Pages dùng chung cơ sở hạ tầng nhà cung cấp cũng như các tên máy chủ công khai github.io và gitlab.io, và đó là một footprint — điều duy nhất mà dòng sản phẩm này tồn tại để tránh. Đối với mạng lưới không có footprint, hãy triển khai trên dịch vụ lưu trữ biệt lập thay thế. Ở mọi nơi khác, Pages là lựa chọn hàng đầu.
Bởi vì gói miễn phí của nó chỉ được cấp phép cho mục đích phi thương mại. Chúng tôi suy luận đích đến từ các tài khoản bạn đã kết nối ở những nơi an toàn, và Vercel được cố tình loại trừ khỏi suy luận đó — việc kết nối tài khoản không bao giờ được âm thầm đặt một trang web thương mại vào nơi mà giấy phép của nó không cho phép. Hãy chọn nó và nó sẽ hoạt động chính xác như những dịch vụ khác.
Có. Mỗi lần triển khai đều ghi lại cam kết đã xuất bản, thời điểm chạy và kết quả hoàn tất, đồng thời thẻ Triển khai của trang web sẽ hiển thị lịch sử cùng với URL trực tiếp bên cạnh. Các quá trình triển khai chạy ngầm, do đó trang sẽ cập nhật ngay khi quá trình dựng hoàn tất thay vì bắt quý khách phải ngồi chờ biểu tượng tải xoay tròn.
Bắt đầu dùng thử 14 ngày không cần thẻ, kết nối GitHub hoặc GitLab và trỏ một trang web vào một nhánh. Xuất bản lên máy chủ biên hoặc trên dịch vụ lưu trữ của chính chúng tôi với các tệp được đồng bộ hóa hai chiều.
Bắt đầu miễn phí