Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Odoo Online không chạy được module tùy chỉnh. Database chạy bản trung gian phải chờ lên bản chính mới chuyển ra ngoài được. Ba lựa chọn và những đường một chiều giữa chúng.
Tài liệu giải pháp đã chốt, khách đã ký, trong đó có ba hạng mục phải lập trình. Tới lúc đội kỹ thuật vào dựng hệ thống thì phát hiện ra nền tảng mà khách đang dùng không chạy được module tùy chỉnh.
Từ đó có hai đường, và cả hai đều tốn. Một là thuyết phục khách chuyển sang nền tảng khác, kéo theo cả một quy trình chuyển đổi có điều kiện. Hai là bỏ ba hạng mục kia ra khỏi phạm vi, kéo theo một cuộc trao đổi mà bạn ở thế yếu vì chính bạn đã hứa.
Ba lựa chọn hạ tầng của Odoo không chỉ khác nhau ở chỗ máy chủ đặt đâu và ai quản lý, mà khác nhau ở chỗ mỗi lựa chọn cho phép bạn làm gì với hệ thống.
Nói cách khác, chọn hạ tầng là chốt trước một cái trần cho phần tùy biến của dự án. Chốt trần trước khi biết dự án cần tùy biến những gì thì bạn đang đặt cược, và cái giá của việc đặt cược sai không nằm ở hóa đơn hạ tầng mà nằm ở phạm vi phải đàm phán lại.
Do đó câu hỏi về hạ tầng phải được đặt trong buổi kick-off chứ không phải trong tuần dựng hệ thống, và người đặt câu hỏi đó nên là người nắm phạm vi. Toàn bộ phần ràng buộc trong bài này tôi mô tả theo tài liệu chính thức của Odoo 19, và đây là loại chính sách bạn phải đọc lại trên đúng thời điểm tư vấn chứ không nên tin theo trí nhớ.
Lựa chọn thứ nhất là database riêng do chính Odoo lưu trữ và vận hành, truy cập bằng trình duyệt và không phải cài gì trên máy.
Đây là lựa chọn nhẹ nhất về vận hành: không phải lo máy chủ hay cập nhật, sao lưu chạy hằng ngày theo cam kết dịch vụ của Odoo, và bạn tạo được bản sao database để thử nghiệm. Bản sao đó mặc định bật chế độ thử nghiệm, tức các tác vụ ra bên ngoài như gửi email hay thanh toán đều bị tắt, nhưng nó hết hạn sau mười lăm ngày và mỗi database chỉ tạo được tối đa năm bản sao.
Đổi lại là giới hạn quyết định nhất trong cả bài, và tài liệu chính thức nói rất thẳng: Odoo Online không tương thích với module tùy chỉnh, và cũng không tương thích với module lấy từ Odoo Apps Store. Thứ được phép là những tùy biến không cần code, tức cấu hình cộng với Studio.
Hệ quả của câu đó rất lớn: trần tùy biến của dự án dừng ở cấu hình và Studio, còn mọi thứ cần một dòng mã riêng, kể cả thứ tưởng là mua sẵn từ kho ứng dụng, đều nằm ngoài tầm.
Ngoài ra Odoo Online còn có một nhịp nâng cấp bắt buộc. Database ở phiên bản chính phải nâng cấp hai năm một lần, còn database ở phiên bản trung gian thì phải lên bản kế tiếp chỉ vài tuần sau khi bản đó ra; nếu bạn không làm trước hạn thì hệ thống tự nâng cấp.
Với một doanh nghiệp nhỏ chỉ cần nghiệp vụ chuẩn thì đây là lựa chọn hợp lý và tiết kiệm được nhiều công vận hành. Với một dự án có bất kỳ hạng mục lập trình nào thì đây là lựa chọn sai, và phải nói ra ngay từ đầu.
Lựa chọn thứ hai là nền tảng cloud chính thức của Odoo để lưu trữ và quản lý các ứng dụng Odoo, và điểm khác biệt của nó là bộ công cụ dành cho người phát triển.
Trên Odoo 19, tài liệu mô tả nó có web shell, quản lý phụ thuộc giữa các module, tích hợp liên tục và truy cập qua SSH. Quan trọng hơn với BA là mã nguồn của dự án nằm trong một kho GitHub gắn với project, và mọi module tùy chỉnh hay module cộng đồng chỉ cần đưa vào một nhánh của kho đó là nền tảng tự nhận ra; nói cách khác, đây là lựa chọn cloud của chính Odoo mà chạy được code riêng.
Tài liệu còn mô tả riêng ba loại nhánh, và phần này đáng đọc kỹ vì nó giải quyết đúng bài toán môi trường mà dự án nào cũng gặp.
Về nâng cấp, Odoo.sh cho bạn ba năm hỗ trợ chuẩn của phiên bản cộng thêm hai năm nữa để hoàn tất việc lên bản mới. Theo cách tôi nhìn thì đây là lựa chọn hợp với phần lớn dự án triển khai có tùy biến, bởi nó giữ được phần tiện của cloud mà không mất phần tự do của việc tự host.
Cần lưu ý rằng Odoo.sh đòi một thuê bao Enterprise có bao gồm nền tảng này, còn giới hạn tài nguyên và số môi trường staging thì đi theo gói, nên bạn phải lấy trực tiếp trước khi tư vấn cho khách.
Lựa chọn thứ ba là doanh nghiệp tự chuẩn bị máy chủ rồi cài Odoo lên, và trong thực tế thì đây là lựa chọn của những khách hàng quan tâm tới hiệu năng hoặc có ràng buộc về nơi lưu trữ dữ liệu.
Tài liệu chính thức của Odoo 19 mô tả ba cách cài, và mỗi cách có mục đích khác nhau chứ không phải ba cách làm cùng một việc.
Đặc biệt, tự host là lựa chọn duy nhất nếu khách chọn bản Community, bởi cả Odoo Online lẫn Odoo.sh đều gắn với thuê bao Enterprise.
Còn nếu sau này khách muốn chuyển lên Enterprise thì cách cài đặt có ảnh hưởng: tài liệu mô tả thủ tục chuyển cho cả bản cài từ gói lẫn bản cài từ mã nguồn, nhưng trang giới thiệu hai phiên bản lại ghi bản cài từ mã nguồn là ngoại lệ. Đây là chi tiết đội kỹ thuật thường quyết một mình vào tuần đầu dự án, nên bạn nên hỏi ngay và dựng thử trên đúng phiên bản trước khi hứa với khách.
Về nâng cấp thì tự host là lựa chọn duy nhất cho phép đứng yên ở một phiên bản bao lâu tùy ý, dù tài liệu không khuyến khích, và vòng đời phiên bản cùng bài toán upgrade là chủ đề của một bài riêng.
Phần đáng giá nhất của bài nằm ở đây, bởi đây là chỗ mà một quyết định tưởng là đảo được hóa ra không đảo được.
Chiều từ tự host sang Odoo Online thì có điều kiện, và thứ tự các bước cũng quan trọng chứ không chỉ nội dung từng bước.
Điều kiện đi kèm là phiên bản hệ thống đang chạy phải còn trong thời gian được hỗ trợ.
Ngoài ra đây không phải thao tác tự làm được mà phải mở ticket hỗ trợ, kèm theo một loạt thông tin gồm:
Mục cuối cùng nghe như tùy chọn nhưng tài liệu khuyến nghị khá mạnh, nhất là với database từng cài ứng dụng của bên thứ ba. Chiều từ Odoo.sh sang Odoo Online cũng theo đúng tinh thần đó, tức gỡ module ngoài chuẩn trên nhánh staging trước rồi mới tới production.
Chiều ngược lại, tức từ Odoo Online ra hai lựa chọn kia, có một cái bẫy ít người biết. Ngoài các phiên bản chính thì Odoo còn phát hành các bản trung gian chỉ chạy trên Odoo Online, và database đang chạy một bản trung gian thì không được hỗ trợ trên Odoo.sh hay tự host. Muốn chuyển thì phải nâng lên phiên bản chính kế tiếp trước, và nếu phiên bản chính đó chưa được phát hành thì bạn phải chờ.
Nghĩa là thời điểm muốn chuyển chưa chắc là thời điểm chuyển được, và với một dự án đang chạy thì vài tháng chờ là chuyện lớn.
Gộp lại thì việc chọn hạ tầng rút gọn về ba câu, và cả ba đều nên được hỏi trong buổi kick-off.
Câu thứ nhất là dự án này có bất kỳ hạng mục nào cần mã riêng không, kể cả module mua sẵn từ kho ứng dụng. Nếu câu trả lời là có, dù chỉ một hạng mục, thì Odoo Online bị loại ngay.
Câu thứ hai là ai sẽ vận hành hệ thống này sau khi dự án kết thúc. Nếu doanh nghiệp không có đội kỹ thuật và cũng không định thuê ai dài hạn thì tự host là lựa chọn tạo ra một khoản nợ vận hành mà không ai đang tính tới.
Câu thứ ba là dữ liệu có ràng buộc nào về nơi lưu trữ không. Với một số ngành và một số loại dữ liệu thì đây không phải chuyện sở thích mà là chuyện tuân thủ, và nó có thể loại thẳng hai lựa chọn cloud.
Trả lời xong ba câu đó thì thường chỉ còn một lựa chọn hợp lý, và bạn có căn cứ để giải thích vì sao.
Có ba nhóm thông tin tôi cố tình không đưa vào bài, và tôi nghĩ nên nói thẳng thay vì viết chung chung cho đủ.
Với cả ba nhóm, cách đúng là hỏi trực tiếp trước khi tư vấn, và ghi lại ngày bạn hỏi.
Khi đã chốt bản nào và host ở đâu thì công việc chuyển vào bên trong hệ thống, và thứ đầu tiên bạn phải quyết ở đó là dữ liệu sẽ được lưu dưới dạng nào.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận