Nhật ký công việc cho nhiệm vụ "Kiểm kê trang web Ruby hiện tại"

Kiểm kê kỹ thuật ban đầu của trang web legacy

Tài liệu ban đầu về việc triển khai hiện tại của bizneshelper.ru đã được nhận.

Stack đã được xác nhận

• Ruby on Rails 3.2.21 — phiên bản framework legacy.
• Phiên bản Ruby không được ghim rõ ràng; dự án giả định một dải các phiên bản Ruby cũ tương thích, xấp xỉ 1.9.3–2.2.x. Để chạy lại cục bộ, Ruby 2.2.10 có vẻ là điểm khởi đầu hợp lý, nhưng tính tương thích cần được xác nhận bằng việc chạy thực tế.
• MySQL thông qua mysql2 ~> 0.3.11.
• Bundler 1.15.4.
• Một môi trường Solr riêng biệt được sử dụng để tìm kiếm toàn văn thông qua sunspot_rails / sunspot_solr.

Các phụ thuộc quan trọng

• devise — xác thực, bao gồm quyền truy cập quản trị.
• ckeditor — chỉnh sửa nội dung.
• paperclip ~> 3.0 — xử lý tệp và hình ảnh được tải lên.
• friendly_id ~> 4.0.9 — URL thân thiện với con người; rất quan trọng để phân tích các định tuyến hiện tại và giữ lại URL trong quá trình di chuyển.
• sunspot_rails, sunspot_solr — tìm kiếm; cần có Solr để tái tạo hoàn toàn hành vi legacy.
• omniauth và các nhà cung cấp mạng xã hội — các kịch bản OAuth lịch sử, tính liên quan của từng nhà cung cấp cần được kiểm tra riêng.
• will_paginate, simple_form — phân trang và biểu mẫu.

Cấu trúc dữ liệu và tệp

• db/ chứa 77 migration, schema.rb và seeds.rb; đây là nguồn quan trọng để khôi phục mô hình dữ liệu thực tế và lịch sử phát triển của nó.
• files/ chứa khoảng 1320 mục; danh mục này cần được đối chiếu riêng với các mô hình Paperclip và URL media công khai.
• public_html/ chứa các tài nguyên tĩnh cần được phân biệt với các trang do Rails tạo ra khi chuẩn bị sơ đồ di chuyển (migration map).
• solr/ chứa cấu hình tìm kiếm và phải được tính đến khi kiểm kê chức năng tìm kiếm.

Các tính năng công khai

• Giao diện quản trị có sẵn tại /admin và sử dụng Devise.
• Ngôn ngữ mặc định là tiếng Nga (config.i18n.default_locale = :ru).

Rủi ro kỹ thuật chính

1. Stack đã lỗi thời đáng kể, vì vậy việc chạy cục bộ trên một hệ thống hiện đại có thể yêu cầu môi trường legacy riêng hoặc container hóa.
2. therubyracer / libv8 có khả năng gây ra vấn đề khi build trên các hệ điều hành hiện đại.
3. mysql2 ~> 0.3.11 có thể không tương thích với các thư viện client MySQL hiện tại nếu không có các biện pháp bổ sung.
4. Việc tái tạo hoàn toàn tính năng tìm kiếm sẽ cần Solr; nếu không có nó, trang web có thể khởi động, nhưng một trong các kịch bản người dùng sẽ không đầy đủ.
5. Cần nghiên cứu friendly_id trước khi thiết kế các định tuyến cho haih-cms, vì các slug và quy tắc URL hiện tại có thể là một phần của tài sản SEO tích lũy.
6. Paperclip và thư mục files/ yêu cầu đối chiếu riêng: cần hiểu sơ đồ đường dẫn, liên kết với các mô hình và tỷ lệ các tệp thực sự được sử dụng.
7. Các nhà cung cấp OAuth thuộc về các tích hợp legacy; một số trong số chúng có thể không hoạt động hoặc không cần thiết trong phiên bản mới, vì vậy chúng không được tự động chuyển đổi như một chức năng bắt buộc.

Các bước tiếp theo cần kiểm tra

• Phiên bản Ruby thực tế thông qua các tệp lock/config/deploy hoặc chạy thử cục bộ thành công.
• Gemfile.lock và các phiên bản chính xác của tất cả các gem.
• schema.rb và các mô hình Rails: thành phần của các thực thể, mối quan hệ và các trường đính kèm của Paperclip.
• routes.rb: các định tuyến công khai thực tế, /admin, friendly_id và các chuyển hướng legacy.
• Bộ điều khiển (controllers) và giao diện (views): các loại trang công khai thực tế.
• Mối liên hệ giữa các tệp trong files/ với các bản ghi cơ sở dữ liệu.
• Việc sử dụng Solr trong các kịch bản người dùng.
• Tính thực tế của OAuth và các tích hợp bên ngoài khác.

Kết luận

Dự án là một nguyên khối Rails 3.2 legacy cổ điển với các hệ thống con lưu trữ tệp và tìm kiếm Solr riêng biệt. Để di chuyển sang haih-cms, điều quan trọng là trước tiên phải tái tạo mô hình dữ liệu hiện tại, các định tuyến và liên kết media, sau đó mới chuyển nội dung và tính năng. Cố gắng coi trang web chỉ như một tập hợp các trang HTML sẽ dẫn đến việc mất đi một phần đáng kể logic của hệ thống legacy.