Thiết lập môi trường và tạo nhánh phát triển (Branch) mới
Để bắt đầu quy trình phát triển an toàn, chúng ta cần tạo một môi trường độc lập từ cơ sở dữ liệu chính (Main Branch) mà không làm gián đoạn dịch vụ hiện tại. Tính năng Branching của Neon cho phép bạn tạo ra một bản sao độc lập về mặt logic, nơi bạn có thể thử nghiệm các thay đổi schema hoặc dữ liệu.
Trước tiên, hãy đảm bảo bạn đã cài đặt CLI của Neon trên Ubuntu 24.04. Nếu chưa, thực hiện lệnh cài đặt sau để có công cụ quản lý từ terminal:
curl -fsSL https://neon.tech/install.sh | bash
Kết quả mong đợi: CLI được cài đặt vào thư mục `/usr/local/bin/neon` và bạn có thể chạy lệnh `neon --version` để xác nhận phiên bản.
Bây giờ, hãy đăng nhập vào tài khoản Neon của bạn để thiết lập quyền truy cập:
neon login
Trong trình duyệt, bạn sẽ thấy mã xác minh. Nhập mã này vào terminal. Kết quả mong đợi là terminal hiển thị thông báo "Logged in successfully" và bạn có quyền thực thi các lệnh quản lý.
Tạo nhánh phát triển từ Main Branch
Thay vì thay đổi trực tiếp trên production, chúng ta sẽ tạo một nhánh mới gọi là `dev-branch-01` từ nhánh chính `main` (hoặc `default`). Lệnh này sẽ tạo ra một điểm nhánh (branch point) dựa trên trạng thái hiện tại của cơ sở dữ liệu.
neon branch create dev-branch-01 --branch main
Kết quả mong đợi: CLI trả về thông báo xác nhận việc tạo nhánh thành công, bao gồm ID của nhánh mới và đường dẫn kết nối (connection string) riêng biệt dành cho nhánh này. Lưu ý kết nối string này để sử dụng trong các bước tiếp theo.
Verify kết quả tạo nhánh
Để xác nhận nhánh đã được tạo và đang hoạt động, liệt kê tất cả các nhánh hiện có trong project của bạn:
neon branch list
Kết quả mong đợi: Bảng hiển thị danh sách các nhánh, trong đó có nhánh `main` và nhánh mới `dev-branch-01` với trạng thái "active".
Sao chép dữ liệu và cấu hình kết nối cho nhánh phát triển
Khi mới tạo nhánh, Neon tự động sao chép toàn bộ dữ liệu và schema từ nhánh gốc tại thời điểm đó. Tuy nhiên, để ứng dụng của bạn trên Ubuntu có thể truy cập vào nhánh mới này, chúng ta cần cập nhật cấu hình kết nối (Connection String).
Cập nhật biến môi trường cho ứng dụng
Chúng ta sẽ tạo một file cấu hình riêng cho nhánh phát triển để tách biệt với production. Giả sử ứng dụng của bạn đang sử dụng file `.env` để lưu biến môi trường.
Tạo file cấu hình mới tại đường dẫn `/home/ubuntu/my-app/.env.dev`:
cat > /home/ubuntu/my-app/.env.dev
Kết quả mong đợi: File `.env.dev` được tạo thành công với nội dung chứa connection string trỏ đến nhánh `dev-branch-01`. Bạn có thể kiểm tra bằng lệnh `cat /home/ubuntu/my-app/.env.dev`.
Thực hiện kiểm thử truy cập dữ liệu
Để đảm bảo dữ liệu đã được sao chép chính xác từ Main Branch sang Dev Branch, hãy kết nối trực tiếp vào nhánh mới và kiểm tra một bảng quan trọng.
Sử dụng lệnh `neon connect` để mở session PostgreSQL trực tiếp vào nhánh dev:
neon connect --branch dev-branch-01
Trong shell PostgreSQL, thực hiện lệnh kiểm tra dữ liệu mẫu (giả sử bạn có bảng `users`):
SELECT COUNT(*) FROM users;
Kết quả mong đợi: Số lượng bản ghi trả về phải giống hệt với số lượng bản ghi bạn đã kiểm tra trên Main Branch trước khi tạo nhánh, chứng tỏ dữ liệu đã được sao chép (snapshot) hoàn chỉnh.
Verify kết quả sao chép dữ liệu
Để so sánh nhanh giữa hai nhánh, hãy thoát khỏi session hiện tại (gõ `\q`) và kết nối sang Main Branch:
neon connect --branch main
Thực hiện cùng lệnh đếm trên Main Branch:
SELECT COUNT(*) FROM users;
Kết quả mong đợi: Kết quả từ hai lệnh trên phải hoàn toàn giống nhau, xác nhận tính toàn vẹn của dữ liệu khi phân nhánh.
Thực hiện thay đổi Schema và Rollback an toàn
Đây là lợi thế lớn nhất của Branching. Bạn có thể thực hiện các thay đổi phá hủy (destructive changes) như xóa cột, thay đổi kiểu dữ liệu, hoặc thêm ràng buộc mới trên nhánh phát triển mà không gây rủi ro cho production.
Thực hiện thay đổi Schema trên nhánh con
Vẫn trong session kết nối với nhánh `dev-branch-01` (hoặc kết nối lại bằng lệnh `neon connect --branch dev-branch-01`), thực hiện lệnh SQL để thay đổi cấu trúc bảng. Ví dụ: thêm một cột mới hoặc xóa một cột không cần thiết.
Thực hiện lệnh thêm cột `last_login_at` vào bảng `users`:
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP;
Kết quả mong đợi: PostgreSQL trả về thông báo "ALTER TABLE" thành công. Dữ liệu hiện có không bị mất, chỉ có cấu trúc bảng được cập nhật.
Thêm một bản ghi mẫu để kiểm tra tính năng mới:
UPDATE users SET last_login_at = '2024-01-20 10:00:00' WHERE id = 1;
Kết quả mong đợi: Lệnh UPDATE thành công, xác nhận bạn có thể ghi dữ liệu mới vào nhánh phát triển.
Kiểm tra sự thay đổi không ảnh hưởng đến Production
Để chứng minh tính cô lập, hãy kết nối sang Main Branch và kiểm tra xem cột mới có xuất hiện hay không.
neon connect --branch main
Thử truy vấn cột mới vừa tạo:
SELECT last_login_at FROM users LIMIT 1;
Kết quả mong đợi: PostgreSQL trả về lỗi "column last_login_at does not exist". Điều này chứng tỏ thay đổi schema trên nhánh `dev-branch-01` hoàn toàn không lan truyền sang Main Branch, đảm bảo an toàn tuyệt đối cho production.
Rollback thay đổi (Mô phỏng việc hủy thay đổi)
Trong môi trường Dev, nếu bạn nhận ra thay đổi schema là sai lầm, bạn có thể "rollback" bằng cách đơn giản là xóa nhánh đó và tạo lại, hoặc sử dụng tính năng "Merge" nếu Neon hỗ trợ (tùy phiên bản). Ở đây, chúng ta sẽ mô phỏng việc rollback bằng cách tạo một nhánh mới từ Main Branch (lấy lại trạng thái sạch) và xóa nhánh cũ có lỗi.
Đầu tiên, tạo lại nhánh phát triển từ Main Branch để có một môi trường sạch (reset schema):
neon branch create dev-branch-01-reset --branch main
Sau đó, xóa nhánh phát triển cũ chứa các thay đổi sai lệch:
neon branch delete dev-branch-01
Kết quả mong đợi: CLI xác nhận nhánh `dev-branch-01` đã bị xóa và nhánh `dev-branch-01-reset` đã được tạo với cấu trúc giống hệt Main Branch (không có cột `last_login_at`).
Verify kết quả Rollback
Kết nối vào nhánh mới được tạo (đã reset) để xác nhận schema đã quay về trạng thái ban đầu:
neon connect --branch dev-branch-01-reset
Thử truy vấn cột `last_login_at`:
SELECT last_login_at FROM users LIMIT 1;
Kết quả mong đợi: Lệnh trả về lỗi "column does not exist", xác nhận thay đổi schema đã được rollback thành công và môi trường phát triển đã sạch sẽ để bắt đầu lại với thiết kế mới.
Điều hướng series:
Mục lục: Series: Triển khai Database Serverless với Neon và Ubuntu 24.04
« Phần 3: Cấu hình ứng dụng Python/NodeJS trên Ubuntu để tương tác với Neon
Phần 5: Tối ưu hóa hiệu năng và quản lý chi phí với tính năng Serverless »