Quy trình triển khai Magento 2

Hiện tại chúng tôi cam kết composer.lockvới kho lưu trữ và sau đó chạy composer install --no-devtrên máy chủ sản xuất. Tôi không nghĩ rằng đây là cách tốt nhất để làm điều đó bởi vì phải mất vài phút để nhà soạn nhạc tạo ra tất cả các tệp và nó rất rủi ro.

Tôi tự hỏi liệu có tốt hơn để cam kết repo tất cả các tệp cần thiết để chạy trong chế độ sản xuất.

Làm thế nào để người khác quản lý quá trình triển khai với magento 2?

Đồng ý 100% với claudiu-creanga về việc không cam kết nhà cung cấp và cũng tránh chạy cài đặt trình soạn thảo trong sản xuất.

Cách chúng tôi đã xử lý việc này là để có một thư mục trực tiếp và thư mục ứng viên phát hành. Trong thư mục ứng cử viên phát hành, chúng tôi chạy các lệnh git pull và trình soạn thảo cài đặt --no-dev. Quá trình của chúng tôi có thể được tóm tắt như thế này:

1. Trong thư mục ứng viên phát hành:

   • Kiểm tra những thay đổi bất ngờ
   • Cập nhật repo
   • Trình soạn thảo cài đặt

2. Đồng bộ hóa tập tin vào thư mục trang web trực tiếp

3. Trong thư mục trang web trực tiếp:
   • Triển khai các tệp tĩnh
   • Bật chế độ bảo trì
   • Kích hoạt mô-đun
   • Chạy các kịch bản thiết lập
   • Biên dịch DI
   • Xóa bộ nhớ cache
   • Tắt chế độ bảo trì
   • Cập nhật quyền

Tôi đã viết một bài viết blog dài hơn đưa ra các lệnh thực tế và lý do đằng sau điều này: https://www.c3media.co.uk/blog/c3-news/deploying-magento-2-production-en môi /

CẬP NHẬT: Bây giờ chúng tôi sao chép cơ sở dữ liệu trực tiếp vào cơ sở dữ liệu dàn và sử dụng cơ sở dữ liệu này để chạy các tập lệnh thiết lập, triển khai các tệp tĩnh và biên dịch DI tất cả ngoại tuyến. Điều này sau đó có thể được triển khai để sống bao gồm các tệp pub / static và var. Chúng tôi vẫn nhanh chóng gỡ trang web xuống nếu tập lệnh thiết lập đang được chạy, nhưng nếu không thì trang web bị bỏ lại. Thêm chi tiết tại https://www.c3media.co.uk/blog/c3-news/magento-2-deployment-without-dftimeime/

CẬP NHẬT: Tôi đã thay đổi suy nghĩ về việc cam kết thư mục nhà cung cấp - bằng cách cam kết thư mục bạn có khả năng theo dõi lịch sử về cách các tệp này thay đổi, hãy xem bạn có vô tình thay đổi điều gì không và quan trọng nhất là bạn tránh phải chạy trình soạn thảo tại thời điểm triển khai. Điều thứ hai là rất quan trọng bây giờ chúng tôi đang dựa vào các nhà cung cấp bên ngoài của kho lưu trữ. Điều gì nếu một trong số họ không có sẵn? Đột nhiên bạn không thể triển khai. Nhược điểm là một kho lưu trữ lớn hơn, nguy cơ thực hiện các vụ hack cốt lõi và làm phiền các nhà phát triển như tôi :)

Cho đến nay, chúng tôi cũng cam kết thư mục nhà cung cấp, tất nhiên sẽ thêm rất nhiều tệp vào repo của bạn. (Hãy chắc chắn xóa mọi thư mục .git trong tệp nhà soạn nhạc của nhà cung cấp, vì nếu không nội dung thư mục sẽ không được cam kết - ví dụ như firegento). Nhưng symlinking thư mục nhà cung cấp không hoạt động, chỉnh sửa đường dẫn trong tệp của nhà cung cấp_path.php cũng không hoạt động và chúng tôi không có thời gian để tìm kiếm một giải pháp tốt hơn cho đến nay.

Chúng tôi không có máy chủ xây dựng và chúng tôi không chạy trình soạn thảo trên máy chủ, chúng tôi chạy và kiểm tra tất cả các cập nhật cục bộ và cam kết chúng. Điều này lần lượt kích hoạt kịch bản triển khai của chúng tôi.

Tập lệnh triển khai của chúng tôi thay thế tệp env.php, thực hiện một số điều tùy chỉnh và sau đó cũng kích hoạt setup:upgradevà setup:static-content:deploytrước khi chuyển liên kết trực tiếp sang thư mục mới.

Thư mục duy nhất chúng tôi symlink là pub / media.

Cuối cùng, chúng tôi đã chọn không tham gia một dịch vụ như deploybot( http://deploybot.com/ ). Bạn có thể sử dụng capistranomiễn phí. Deploybot tạo một thùng chứa docker trong khi cài đặt trình soạn thảo đang chạy và nếu lệnh thành công thì nó sẽ triển khai mã, nếu không nó sẽ không triển khai bất cứ điều gì để môi trường sản xuất của bạn sẽ an toàn.

Tôi coi đây là cách tiếp cận tốt nhất bởi vì:

1) có thư mục nhà cung cấp trong repo git của bạn không được các nhà soạn nhạc khuyên dùng vì lý do chính đáng:

The general recommendation is no. The vendor directory (or wherever your dependencies are installed) should be added to .gitignore/svn:ignore/etc.

Thông tin thêm: https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

2) Chạy composer install in productionkhông có lưới an toàn là rủi ro , các gói có thể bị hỏng (xem npm), bạn có thể gặp sự cố về bộ nhớ hoặc bất kỳ lỗi nào có thể xảy ra trong khi nhà soạn nhạc tạo tệp và bạn sẽ phải xử lý môi trường sản xuất bị hỏng.

Tôi cũng đang xem xét điều này, cách tiếp cận tôi đã thực hiện cho đến nay là:

Khởi động máy chủ:

1. Thiết lập dự án với composer --create-project ... --no-devmột srcthư mục (mặc dù tôi vẫn thấy rất nhiều dev cruft đi qua)
2. Cài đặt ứng dụng, Biên dịch tệp tĩnh, nâng cấp db, v.v.
3. Đặt tất cả các quyền chính xác

Cái nào sẽ cho tôi một cổ phiếu, chạy cửa hàng từ thư mục src của tôi (nhưng webroot của tôi không trỏ đến đó)

Sau đó, quá trình triển khai của tôi:

1. Tạo một thư mục phát hành mới
2. rsync các tập tin src vào bản phát hành của tôi (không bao gồm cruft)
3. triển khai và giải nén các tùy chỉnh của tôi trên đầu trang (một số ít tệp chủ đề và mô-đun)
4. cài đặt bất kỳ mô-đun magento của bên thứ ba thông qua kết nối magento
5. trỏ máy chủ lưu trữ web của tôi vào bản phát hành mới của tôi (với một liên kết tượng trưng)
6. duyên dáng tải lại máy chủ web của tôi

Điều này cho phép tôi duy trì mã lõi Magento tách biệt với mã riêng của mình, sử dụng trình soạn thảo để cập nhật mã .. và tôi không cần gửi 39.102 !!! các tệp với mỗi lần triển khai hoặc chạy các lệnh tổng hợp tại thời điểm triển khai ..

... Muốn nghe về các phương pháp khác hoặc để thực hành tốt nhất về vấn đề này, và id cũng thích biết những tập tin nào thực sự cần thiết cho sản xuất và đó là dev .. vì vậy tôi có thể giữ sạch webroot của mình.

Sau khi tôi kết thúc, tôi sẽ có một playbook ansible và một số lệnh Fabric để sắp xếp cấu hình và triển khai, tôi rất vui được chia sẻ.

Mong rằng sẽ giúp