2011-01-15 13 views
9

Dưới đây là yêu cầu cơ bản của chúng tôi:Chạy một phiên bản tùy biến của một ứng dụng Rails

  • Chúng tôi có một ứng dụng cơ sở Rails, hiện đang được tích cực duy trì.
  • Chúng tôi muốn cung cấp phiên bản tùy chỉnh của ứng dụng này, cho rằng:
    • máy chủ phải nằm trong tiền đề của khách hàng và chạy trên một miền khác.
    • có công cụ ghi nhật ký cụ thể để theo dõi riêng của họ trong trung tâm dữ liệu.

Để làm điều đó, tôi có thể thấy một vài lựa chọn để đạt được mục tiêu đó:

  • chi nhánh Git
  • Rails::Engine
  • Rails::Application

Câu trả lời rõ ràng nhất sẽ là Git branch, cho sự linh hoạt hoàn toàn. Tuy nhiên, tôi không chắc đó có phải là một ý kiến ​​hay hay không, vì cơ sở mã phần lớn được chia sẻ và đường chính có nhiều hoạt động hơn - bắt kịp với việc rebase/merge có thể chỉ là rắc rối.

Chúng tôi muốn tách riêng bản gốc và các phiên bản tùy chỉnh càng nhiều càng tốt. Nói cách khác, chúng tôi muốn có càng ít xung đột càng tốt giữa bản gốc và tùy chỉnh.

Rails::Engine hoặc Rails::Application dường như là một ý tưởng gần gũi (Tôi không quen thuộc với Rails Engines), nhưng tôi không hiểu làm thế nào để có OurApp::ApplicationOurCustomizedApp::Application ở một nơi và chuyển đổi giữa chúng trên toàn cầu và năng động.

Có lẽ nó sẽ được tốt đẹp để có:

  • tùy chỉnh initializers, bộ điều khiển và quan điểm trong một thư mục riêng biệt để ghi đè lên (hoặc miếng dán) bản gốc khả năng
  • để xác định các ứng dụng (bản gốc hoặc tùy chỉnh) để khởi động bởi một biến môi trường như RAILS_APP
  • tập tin cấu hình riêng biệt, như vậy: config/database.ymlconfig/customer1/database.yml
  • khả năng sử dụng cùng một deploy.rb cho capistrano (p robably với config/servers.ymlconfig/customer1/servers.yml để xác định vai trò và IP?)

Có thực tiễn/quy ước nào cho các yêu cầu của chúng tôi không? Lời khuyên nào?

Ứng dụng của chúng tôi chạy trên Ruby 1.9.2 + Rails 3.0.3.

CẬP NHẬT

Chúng tôi bắt đầu nó như là một chi nhánh Git. Chúng tôi tạo ra một nhiệm vụ cào để tạo ra một tập tin tại config/branch bao gồm văn bản như "chủ" hoặc "tùy chỉnh", và application.rb đọc nó khi bootstrap.Các xác nhận như database.yml hoặc servers.yml hiện đang hoạt động ở config/mainline/ hoặc config/customized/ và application.rb xử lý chúng tương ứng.

config.paths.config.database = "config/#{branch}/database.yml" 

Không hoàn hảo, nhưng đủ tốt cho bây giờ. Tôi sẽ cập nhật khi chúng tôi tìm ra cách tốt hơn để thực hiện việc này.

Trả lời

1

Tôi biết đó không phải là câu trả lời chính xác, nhưng tôi tin Git sẽ là số lượng công việc ít nhất - và dễ quản lý, lâu dài - hơn tùy biến ứng dụng và thêm logic để xử lý các tệp cấu hình bổ sung, sửa đổi các tệp triển khai của bạn và cũng quản lý các tệp css/js/template mới (có khả năng).

Sử dụng rebase & hợp nhất sẽ ít bị lỗi hơn và miễn là bạn giữ cho các chi nhánh của mình được đồng bộ hóa thường xuyên, bạn không nên gặp phải bất kỳ sự cố nghiêm trọng nào khi cập nhật chúng. Xét cho cùng, đó là những gì Git giỏi! ;)

+0

Chúng tôi đã kết thúc với chi nhánh Git và nó đã hoạt động khá tốt cho đến nay. Cảm ơn! – kenn

0

Chúng tôi sử dụng Git để làm điều đó khá thường xuyên.

2

Tôi nghĩ cách tiếp cận tốt nhất là làm theo cách cũ này.

Đầu tiên, thêm một lớp đơn lẻ vào dự án của bạn (trong /lib) được gọi là một cái gì đó như Affiliate. Lớp này sẽ cung cấp các triển khai mặc định (bất kể bạn muốn ứng dụng cơ sở của bạn sử dụng) cho bất kỳ phần nào của ứng dụng có thể được tùy chỉnh. Tại thời điểm này, ứng dụng của bạn hoạt động giống nhau, nhưng có móc để cho phép tùy chỉnh.

Tại trang web của khách hàng, triển khai cùng một mã nguồn (vận chuyển như một viên ngọc, có lẽ?), Mà còn triển khai một plugin Rails đó sẽ ghi đè Affiliate nên instance phương pháp singleton nó trả về một lớp tùy chỉnh mà cung cấp thông tin hoặc hành vi của khách hàng cụ thể .

Chỉnh sửa thêm: Rủi ro với cách tiếp cận này là các nhà phát triển vô ý phá vỡ mọi thứ vì họ chỉ kiểm tra thay đổi của họ đối với liên kết mặc định. Bạn nên sử dụng thử nghiệm tự động và tích hợp liên tục để nắm bắt điều này.

+0

tuỳ biến của chúng tôi là tương đối nhỏ, nhưng đủ lớn để không vừa với một lớp duy nhất và nơi để cho phép tùy chỉnh không thể đoán trước được từ quan điểm của đường chính. Tùy chỉnh cần nhiều quyền lực như trình khởi tạo tùy chỉnh, v.v. – kenn

1

Dường như bạn có hai yêu cầu thú vị ở đây. Bạn hỏi làm thế nào để có hai ứng dụng riêng biệt và chuyển đổi giữa chúng một cách năng động. Tôi giả định rằng bạn muốn cohost 'phiên bản' khác nhau của cùng một ứng dụng và chuyển ứng dụng sang các tùy chỉnh khác nhau dựa trên tên miền. Tuy nhiên điều này rất khác với việc sử dụng các nhánh Git để triển khai hai ứng dụng khác nhau.

Bạn có thể làm rõ các yêu cầu của mình tại đây không?

Tôi sẽ không đề xuất các chi nhánh Git làm giải pháp tại đây. Tôi sẽ khuyên bạn nên sử dụng động cơ. Đặc biệt là đóng gói động cơ của bạn thành một viên ngọc.

Bao gồm đá quý vào dự án Tùy chỉnh của bạn và sau đó sử dụng các cách truyền thống của chức năng ghi đè trong một công cụ. Bạn cũng có thể sử dụng các phương pháp truyền thống để mở rộng mã Ruby hiện có để ghi đè lên chức năng trong gem của bạn.

Bằng cách này, bạn giữ tất cả các khác biệt được nêu trong một dự án riêng biệt. Dự án riêng biệt này cũng sẽ có bộ thử nghiệm riêng, v.v.

+0

trong khi tôi nghĩ rằng có một công cụ để cohost nhiều ứng dụng, tôi không chắc chắn về việc duy trì nó như một đá quý - hoạt động của chúng tôi trên ứng dụng mainline là khá mãnh liệt, và tạo ra một gem cho mỗi cam kết sẽ không thực tế. Có vẻ như ứng dụng web được triển khai từ đá quý chứ không phải từ git repo. Tôi sẽ mang nó theo cách khác xung quanh - ứng dụng cho đường chính, và động cơ/plugin cho các tùy chỉnh, tuy nhiên nó không có vẻ như một phù hợp tốt hoặc. – kenn

Các vấn đề liên quan