Triển khai lên máy chủ riêng của bạn nghĩa là trao cho một tác nhân quyền truy cập gần giống SSH vào một máy chủ mà bạn đang trả tiền, và có thể đã có những thứ khác đang chạy trên đó. Đó là một mức độ tin cậy khác so với việc xuất bản lên một tên miền phụ miễn phí, và việc thiết lập phản ánh điều đó — một vài trường, điền một lần, và sau đó mỗi bản build tiếp theo chỉ còn là một nút bấm. Đây là những gì mọi người thực sự hỏi trước và sau khi họ thiết lập một đích triển khai.
Tôi cần gì để tạo một đích triển khai?
Năm thứ, trong Cài đặt → Triển khai:
- Một cái tên bạn sẽ nhận ra sau này — "prod-vps", "client-hostgator", hoặc bất cứ tên gì còn sống sót trong một danh sách thả xuống lúc 11 giờ đêm
- Máy chủ (host) và cổng (port)
- Thông tin đăng nhập SFTP
- Đường dẫn webroot
Không cần token API, không cần cài CLI trên máy chủ, không cần trông chừng một cron job. Nếu nhà cung cấp host của bạn có truy cập SFTP — điều này bao trùm gần như mọi shared host, mọi VPS, mọi máy chủ WordPress được quản lý — bạn sẽ hoàn tất trong khoảng hai phút.
Mật khẩu hay khóa (key)?
Khóa, nếu host của bạn hỗ trợ. Mật khẩu vẫn hoạt động tốt và chúng tôi lưu trữ chúng gắn với tài khoản của bạn, nhưng dùng khóa nghĩa là ít một bí mật hơn nằm ở bất kỳ đâu — khác biệt giữa "thu hồi một khóa" và "đặt lại mật khẩu ở mọi nơi mật khẩu đó lỡ bị dùng lại" nếu có sự cố xảy ra sau này. Nhiều gói shared-hosting SFTP giá rẻ chỉ hỗ trợ xác thực bằng mật khẩu, và điều đó cũng ổn. Chỉ cần đừng dùng lại mật khẩu đó ở bất kỳ đâu khác.
Làm sao để tìm đúng đường dẫn webroot?
Đây là trường thông tin mà mọi người thường điền sai ngay lần đầu, vì câu trả lời sai vẫn nghe có vẻ hợp lý. Đó không phải thư mục home của bạn, cũng không phải /var/www — đó chính xác là thư mục mà web server của bạn được cấu hình để phục vụ.
| Máy chủ | Webroot thông thường |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — hoặc một đường dẫn nào đó mà một lập trình viên trước đây đặt tên ba năm trước vì lý do không ai còn nhớ |
Nếu không chắc chắn, hãy thả một file test.txt tạm bợ vào thư mục mà bạn nghĩ là đúng bằng bất kỳ SFTP client nào, rồi kiểm tra xem nó có tải được tại yoursite.com/test.txt hay không. Nếu chọn sai, lần deploy vẫn sẽ báo cáo thành công — agent trung thực ghi các file vào đúng thư mục sai, và bạn sẽ nhìn chằm chằm vào một trang web đang live mà chẳng thay đổi gì, tự hỏi tại sao.
Một đích triển khai có thể bao phủ nhiều hơn một tên miền không?
Có, và đây là phần tiết kiệm thời gian thực sự khi bạn đã qua khỏi trang web đầu tiên. Một đích triển khai là một máy chủ và một bộ thông tin đăng nhập — nó không gắn với một tên miền duy nhất. Trong Quản lý tên miền, bạn gắn từng tên miền vào một đích triển khai với đường dẫn webroot riêng của nó. Chạy ba trang web trên một VPS với các server block Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Một đích triển khai, ba lần gắn kết. Bạn không phải nhập lại mật khẩu SSH ba lần, và bạn không phải duy trì ba đích triển khai gần giống nhau rồi bị lệch đồng bộ vào ngày bạn xoay vòng một khóa mà quên mất một trong số chúng. Nhấp triển khai trên bất kỳ tên miền nào trong ba tên miền đó, nó đã biết máy chủ nào và thư mục nào — bạn không bao giờ phải chọn lúc triển khai.
Tác nhân thực sự làm gì khi nó kết nối?
Đầu tiên, nó quan sát xung quanh — chỉ đọc, chưa ghi gì cả. Sự kiểm tra đó nhằm xác định:
- Một thư mục trống
- Một phiên bản trước đó của chính bản build này
- Một bản cài đặt WordPress cũ
- Một placeholder "sắp ra mắt" mà host của bạn đặt sẵn ở đó theo mặc định
Điều đó quyết định chiến lược. Một webroot trống sẽ được tải lên đơn giản. Một webroot đã có sẵn thứ gì đó sẽ được xử lý cẩn thận hơn, vì nhiều thiết lập thực tế có những thứ đang nằm cạnh trang web mà không nên biến mất:
- A
.well-knownthư mục dùng để xác thực SSL - Một
uploadsthư mục mà không ai đưa vào git - A
wp-config.phpkhông ai muốn đụng vào
Công việc ở đây gần với "tìm ra cái gì đã thay đổi và điều hòa nó" hơn là "xóa sạch và thay thế".
Sau đó, trước khi một byte nào bị ghi đè, webroot hiện tại được chụp lại thành một phiên bản trên chính máy chủ của bạn. Không phải một bản ghi cơ sở dữ liệu, không phải một bản khác biệt mà chúng tôi tính toán rồi hy vọng là đúng — mà là một ảnh chụp thực sự của những gì đang nằm ở đó. Điều này quan trọng nhất ở lần triển khai đầu tiên đến bất kỳ đích nào, vì lần triển khai đó luôn đáp xuống trên thứ gì đó, ngay cả khi thứ đó là không có gì. Thư mục trống, ảnh chụp trống. Trang web tĩnh năm năm tuổi không ai nhớ đã xây dựng — được bảo tồn nguyên vẹn, miễn phí, trước khi bị đụng đến. Lần triển khai đầu tiên đó cũng là lần bạn ít chắc chắn nhất, vì vậy đó là lần điều này quan trọng nhất.
Nó tải lên mã nguồn của tôi hay trang web đã được build?
Luôn là site đã build. Với một site tĩnh, đó là các trang đã được tạo ra. Với một bản build framework — Next.js, Vite, hay bất cứ loại site nào yêu cầu — đó là output đã biên dịch, thư mục dist hoặc build , không bao giờ là cây thư mục mã nguồn. Tôi cho rằng đây là quyết định đúng đắn dù nó có nghĩa là bạn không thể SSH vào và chạy npm run dev trên những gì có trên server. Tải mã nguồn lên đồng nghĩa với việc webroot production của bạn cần một runtime Node và một bộ công cụ build chỉ để phục vụ HTML — biến một máy chủ hosting dùng chung, vốn chưa bao giờ được thiết kế để chạy pipeline build, thành một máy như vậy, và biến mỗi lần deploy thành "hy vọng server có đủ bộ nhớ để hoàn thành npm install." Chỉ triển khai output đã biên dịch giữ cho webroot đúng như những gì một static file server cần. Nhàm chán. Nhàm chán chính là điều bạn muốn vào lúc 2 giờ sáng khi có gì đó sai và bạn đang nhìn chằm chằm vào thư mục đó cố tìm hiểu thực sự đang được phục vụ những gì.
Làm sao tôi biết một lần deploy thực sự thành công?
Sau khi tải lên, agent sẽ truy cập URL live và kiểm tra xem nó có phân giải được không — không phải lỗi 500, không phải trang trắng. Bất kể phát hiện được gì, cộng với bất cứ điều gì nó nhận thấy trong quá trình kiểm tra mà muốn bạn xác nhận ("webroot này có một thư mục wp-content mà tôi để nguyên không đụng vào, hãy xác nhận đó là điều mong muốn"), sẽ xuất hiện trong luồng chat của build đó. Đó là mẫu hình xuyên suốt toàn bộ nền tảng này: không có thành công âm thầm, không có thất bại âm thầm rồi biến thành một ticket hỗ trợ. Agent cho bạn biết nó đã thấy gì và đã quyết định gì, ngay trong cùng luồng chat mà bạn đã yêu cầu bản build đó.
Lịch sử phiên bản thực chất chứa những gì?
Mỗi lần deploy đều tạo thêm một phiên bản — không chỉ lần build đầu tiên. Vì vậy lịch sử này không phải là các bản build của bạn được vẽ trên một dòng thời gian trừu tượng; đó là chuỗi thực tế những gì đã được phục vụ từ webroot đó, theo đúng thứ tự, bắt đầu từ bất cứ thứ gì đã có ở đó trước khi bạn xuất hiện. Phiên bản một luôn là trạng thái trước-nền-tảng đó, được tự động ghi lại. Bạn không cần phải bận tâm về nó.
Revert thực sự khôi phục lại điều gì?
Chính xác là phiên bản live trước đó — không phải chạy lại một bản build cũ, không phải một sự gần đúng. Đó là các file thực tế đã phục vụ traffic trước đó. Đây là một đảm bảo mạnh mẽ hơn đáng kể so với hầu hết các tính năng "rollback" mà tôi từng dùng ở nơi khác, thường có nghĩa là "deploy lại từ một commit cũ" và ngầm giả định rằng quy trình build của bạn có tính xác định và môi trường của bạn không bị trôi dạt kể từ đó. Ở đây, revert là khôi phục một snapshot đã biết là hoạt động tốt, đó là lý do vì sao có thể yên tâm dùng nó khi đang gặp áp lực — bạn không cần phải phân vân liệu rollback có thể hoạt động khác với thứ nó đang rollback về hay không.
Và thời điểm bạn thực sự cần đến nó không bao giờ là lúc bình tĩnh; đó là "bản build mới làm hỏng checkout và traffic đang live ngay lúc này."
Một cú click, phiên bản trước được khôi phục, xong. Lý do đằng sau việc coi đây là một tính năng hạng nhất thay vì một ý tưởng phụ được trình bày trong Lặp lại mà không sợ hãi — đáng đọc một lần, trước khi bạn cần đến nó. Cả lịch sử và điều khiển khôi phục đều nằm trên thẻ build và trong màn hình lịch sử riêng của target.
Tính năng này có sao lưu cả cơ sở dữ liệu của tôi không?
Không, và tôi thà nói thẳng điều đó hơn là để ai đó ngộ nhận. Lịch sử phiên bản trên host chỉ bao phủ những gì pipeline deploy này đưa vào webroot. Nếu trang web của bạn có cơ sở dữ liệu, hoặc các file người dùng tải lên, hoặc bất cứ thứ gì thay đổi bên ngoài các lần deploy, đó hoàn toàn là một vấn đề khác — revert không đụng đến nó và không nên bị nhầm lẫn là một chiến lược sao lưu bao gồm cả những thứ đó.
