Chiến lược triển khai tốt nhất là gì?

82

Thiết lập cửa hàng Magento không chỉ là vấn đề phát triển các tiện ích mở rộng có thể tự cài đặt mà còn đòi hỏi rất nhiều thao tác "nhập thủ công" như tạo thuộc tính chỉnh sửa cuối, danh mục, sản phẩm, quy tắc giá các trang CMS, v.v. các thay đổi đối với Cấu hình hệ thống.

Tôi muốn bạn giúp phác thảo chiến lược tốt nhất khi triển khai cửa hàng Magento từ phát triển đến môi trường dàn dựng và sản xuất.

Một chiến lược của tôi là viết "mô-đun triển khai", lập trình tạo ra các thực thể được đề cập ở trên nhưng đó là một nhiệm vụ rất tốn thời gian và đôi khi đối với tôi có vẻ hơi quá mức.

Gần đây, tôi bắt đầu sử dụng Selenium IDE để tái tạo các tác vụ Quản trị viên nhưng thời gian cần thiết để thiết lập tất cả các bộ thử nghiệm không xa so với các đề cập ở trên.

Có lẽ một giải pháp tối ưu có thể là việc sử dụng một mô-đun có khả năng thực hiện một ảnh chụp nhanh của Hệ thống Magento cho phép bạn chọn những gì cần triển khai.

Vì thế:

chiến lược của bạn để triển khai là gì?
Có một mô-đun có khả năng thực hiện một ảnh chụp nhanh của Hệ thống Magento cho phép bạn chọn triển khai cái gì không?
Nếu một mô-đun như vậy không tồn tại và cung cấp một mô-đun như vậy là một giải pháp hợp lý, có ai quan tâm đến việc đóng góp của mình để phát triển nó không?

Cảm ơn bạn!

deploy admin entities

— Alessandro Ronchi
nguồn

Điều này có thể chỉ ra sự cần thiết cho một thẻ hoặc loại thẻ khác. Bạn có phải là cửa hàng một lần hay bạn đang tìm kiếm đề xuất chung như một nhà cung cấp dịch vụ? Nếu sau này, bất kỳ câu trả lời nào cũng sẽ phải được ghi chú "phụ thuộc vào mức độ kiểm soát của khách hàng đối với dữ liệu thực thể".

— đánh dấu

Quan điểm của tôi là một trong những nhà phát triển thuộc nhóm phát triển. Giả sử tôi đang phát triển một phần cần một số dữ liệu để hoạt động, giả sử cấu trúc thể loại. Tôi tạo cấu trúc thông qua Admin, thực hiện mã và đẩy mã của mình. Tôi đang tự hỏi liệu chiến lược tốt nhất là viết và đẩy mã để tạo ra cấu trúc danh mục cần thiết. Điều gì xảy ra nếu cấu trúc danh mục hoặc cài đặt của tôi xảy ra với các nhà phát triển khác đã đẩy chính họ? Làm thế nào để tôi xử lý xung đột? Đó là quan điểm của tôi.

— Alessandro Ronchi

@AlessandroRonchi Đây là một điểm moot, và một cuộc xung đột không bao giờ nên xảy ra. Cấu trúc danh mục của bạn không phải là thứ gì đó nên thay đổi một cách phù phiếm, do đó, một nhà phát triển không nên đưa ra một thay đổi lớn cho cấu trúc của bạn, mà không có (các) người khác biết về nó. Nếu điều này xảy ra, bạn cần giải quyết liên lạc giữa các nhà phát triển. Nói chung, cấu trúc danh mục cho một trang web cần được ghim xuống từ ngày đầu tiên và không bao giờ cần thay đổi lại, chỉ cần được thêm vào. Nếu bạn cần thay đổi nó, bạn đã không tìm hiểu chính xác lần đầu tiên.

— ProxiBlue

@dedmeet thật không may, trên thế giới tôi biết và làm việc, mọi thứ thay đổi mỗi ngày; khách hàng thay đổi ý định, nhà phát triển thay đổi ý định, thiên nga đen xảy ra. Tôi phải chuẩn bị để thay đổi; dù sao ngay cả khi cấu trúc thể loại không cần phải thay đổi từ ngày đầu, nó chỉ là một phần nhỏ của toàn bộ và toàn bộ phần là một dự án "công việc đang tiến hành" được cho là sẽ thay đổi để hoàn thành công việc.

— Alessandro Ronchi

ok, được cho phép, chúng tôi làm việc trong một môi trường luôn thay đổi, nhưng tôi vẫn cho rằng không nên xảy ra xung đột cấu trúc thể loại. Nhiều nhánh không nên tồn tại khi mỗi nhánh thay đổi cấu trúc, điều đó sẽ dẫn đến các vấn đề và lãng phí thời gian dev. Tại sao dev lại dành thời gian để thay đổi cấu trúc, trong khi dev b đang làm tương tự, sang một cấu trúc khác và cả hai đều đẩy công việc của họ? Nếu cấu trúc phải thay đổi, tất cả các nhà phát triển tham gia vào dự án phải tham gia vào quá trình tìm ra cấu trúc mới. Bạn có thể cung cấp một ví dụ để giúp tôi hiểu khi nào điều này có thể xảy ra?

— ProxiBlue

39

Ý kiến của tôi là kịch bản tất cả. Tôi thường có một mô-đun cấu hình cơ sở cho bất cứ điều gì không liên quan trực tiếp đến một mô-đun cụ thể theo chức năng. (ví dụ: tạo url tùy chỉnh viết lại cho url trang web trước đó vào url trang web mới) và thêm bất cứ điều gì liên quan đến một mô-đun vào tập lệnh cài đặt của chính nó.

Suy nghĩ đằng sau điều này là nếu trang web cần được cài đặt lại, sử dụng db mới, thì mọi thứ sẽ quay trở lại như bạn đã có. Điều này cũng giúp trong thực tế là tôi định kỳ cập nhật trang web uat với một bản sao của db trực tiếp. Các mô-đun trong uat sau đó tiếp tục hoạt động khi chúng quay lại cấu hình của chúng.

Thay đổi về giá cước bưu chính, quy tắc giỏ hàng, v.v. (về cơ bản những thứ khách hàng tự quản trị trong quản trị viên) được coi là "dữ liệu dễ bay hơi" và không được viết kịch bản. Điều này bao gồm dữ liệu sản phẩm. Khách hàng có tùy chọn và được khuyến khích thử nghiệm nhập mới trên trang web uat trước.

Khách hàng được yêu cầu không tạo thuộc tính mà thay vào đó họ được tạo thông qua yêu cầu vé. Điều này sau đó cho phép tôi cũng thu thập thông tin về ý định của khách hàng đối với thuộc tính và đôi khi tôi có đề xuất tốt hơn hoặc có thể tạo mã tốt hơn khi tôi xử lý các thuộc tính nào tồn tại, cộng với các thuộc tính có thể chọn, đảm bảo dữ liệu là dọn dẹp.

Có kịch bản mất nhiều thời gian hơn, nhưng sẽ mất nhiều thời gian hơn để tạo lại toàn bộ cài đặt cấu hình trang web theo cách thủ công sau này. Nó cũng có thể gây lúng túng nếu bạn quên một cái gì đó và khiến trang web không hoạt động đúng hoặc có một nhà phát triển mới làm việc trên một trang web cục bộ thiếu một số thiết lập cấu hình quan trọng.

— ProxiBlue
nguồn

1

Tôi đồng ý với cống hiến. Khi bạn lần đầu tiên học cách tạo kịch bản cho tất cả các bản cập nhật, nó có thể là công việc ban đầu hơn nhưng nếu bạn phải áp dụng cập nhật cấu hình theo cách thủ công cho 3-4 nhà phát triển, dàn dựng, uat và trực tiếp, việc phối hợp và thực tế sẽ mất nhiều thời gian hơn. Quy trình làm việc của chúng tôi khá giống nhau: nếu cấu hình là cần thiết cho một phần mở rộng (có thể tái sử dụng), hãy đặt nó ở đó. Nếu cấu hình là dành riêng cho khách hàng, hãy đặt nó trong một phần mở rộng dành riêng cho dự án. Một trong vài trường hợp ngoại lệ là các quy tắc giỏ hàng không thú vị để cập nhật / tạo.

— Matthias Zeis

1

Tôi chỉ phát hành một mô-đun giúp tạo tập lệnh cấu hình cần thiết, do đó loại bỏ công việc trần tục là phải tự tạo các tập lệnh cài đặt. Mô-đun sử dụng màn hình lưới của bảng core_config_data để cho phép lựa chọn các giá trị cấu hình để xuất. Làm cho cuộc sống của tôi đơn giản hơn một chút, và tôi hy vọng nó sẽ làm việc cho người khác. proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

27

Tôi đã được một số nghiên cứu vài tháng trước. Đây là các trang web mà bạn có thể tham khảo.

~~Các cơ sở của Magento và cài đặt dev / dàn dựng~~
Magento Phát triển và triển khai
Magento Git Hướng dẫn và quy trình làm việc
nhanh hơn Việc hủy bỏ cơ sở dữ liệu MySQL Magento để phân nhánh

— Ouz Çelikdemir
nguồn

1

Cảm ơn bạn, tôi sẽ đọc tất cả chúng và quay lại với một số cân nhắc.

— Alessandro Ronchi

Tôi đã đọc tất cả các tài nguyên; Tôi đã biết một số trong số họ, những người khác mà tôi không biết là rất thú vị. Dù sao, không ai trong số họ là giải pháp cho vấn đề của tôi và tôi đã quyết định phác thảo một phần mở rộng sẽ cố gắng đáp ứng nhu cầu của tôi. Cảm ơn tất cả các bạn đã cho tôi lời khuyên quý giá. Tôi hy vọng sẽ trở lại đây với một số kết quả.

— Alessandro Ronchi

Alessandro thân mến, tôi cũng muốn xem cách mà bạn đang tìm kiếm kỹ thuật thoải mái hơn!

— Oğuz elikdemir

18

Tôi muốn cảm ơn tất cả các bạn vì những cân nhắc của bạn đã truyền cảm hứng và thúc đẩy tôi phát triển một phần mở rộng, được gọi là "Mageploy" với mục đích giải quyết vấn đề duy trì các môi trường khác nhau đồng bộ.

http://www.mageploy.com

Mageploy vẫn phải được gia hạn, ghi chép đầy đủ và được kiểm tra đầy đủ ngay cả khi tôi đã sử dụng nó trong một vài dự án có một số lợi ích.

Đó là nguồn mở và bất kỳ trợ giúp hoặc đề xuất nào sẽ được đánh giá cao.

Trân trọng

— Alessandro Ronchi
nguồn

7

Liên quan đến việc cài đặt các tập lệnh và tạo các thực thể, cảm giác chung của tôi là nếu nó được yêu cầu hoặc mong đợi bởi một mô-đun, thì nó nên được tạo như một phần của tập lệnh cài đặt.

Gần đây, về mặt dev / giai đoạn / sản xuất, chúng tôi sử dụng trang dàn dựng làm bản sao chính của cơ sở dữ liệu cho nội dung vì điều đó có nghĩa là khách hàng có thể cộng tác. Trước đây, có lẽ vấn đề lớn nhất mà chúng tôi gặp phải là điều phối mục nhập nội dung với khách hàng, đặc biệt liên quan đến việc tải lên sản phẩm.

Làm thế nào bạn nghĩ rằng ảnh chụp sẽ làm việc? Tôi nghĩ trong một thế giới lý tưởng, bạn sẽ có một công cụ cho thấy sự khác biệt giữa hai cơ sở dữ liệu về các loại cụ thể (sản phẩm, danh mục, CMS, v.v.) và cho phép bạn hợp nhất các thay đổi với nhau nhưng tôi không biết bất cứ điều gì có sẵn như cái đó.

— Paul
nguồn

1

"Liên quan đến việc cài đặt các tập lệnh và tạo các thực thể, cảm giác chung của tôi là nếu nó được yêu cầu hoặc mong đợi bởi một mô-đun, thì nó nên được tạo như một phần của tập lệnh cài đặt." Đây là điểm quan trọng nhất để xem xét và áp dụng cho cài đặt cấu hình. Thử nghiệm nhanh của tôi: khi tôi cần một nhà phát triển mới để sao chép repo và cài đặt môi trường, cần gì để hệ thống hoạt động?

— đánh dấu

Chia sẻ một trang web dàn dựng với khách hàng để hợp tác về cấu hình là lý thuyết tuyệt vời. Trong thực tế, khách hàng không cho bạn biết tất cả mọi thứ họ đã thay đổi 99% thời gian, điều này giúp bạn dễ dàng làm hỏng việc gì đó. Chúng tôi có thể cho phép khách hàng làm việc trên các công cụ như quy tắc giỏ hàng, danh mục, sản phẩm hoặc tương tự nhưng chúng tôi không để họ can thiệp vào cấu hình.

— Matthias Zeis

6

Theo tôi, việc tạo và chỉnh sửa các thuộc tính, danh mục, sản phẩm, quy tắc giá không liên quan gì đến "chiến lược triển khai" Tất cả các mặt hàng này đều khá độc đáo đối với một cửa hàng và trong hầu hết các trường hợp cần một chút phân tích và nghiên cứu thích hợp về các sản phẩm bạn sẽ bán

Nếu bạn đang tạo các cửa hàng "một kích thước phù hợp với tất cả" với cấu hình tương tự của tất cả các yếu tố bạn đề cập, bạn có thể thực hiện xuất "ảnh chụp nhanh" cơ sở dữ liệu của mình sau khi bạn đã thực hiện tất cả các thiết lập bạn cần cho mọi cửa hàng.

— Rutger
nguồn

Không, "một kích thước phù hợp với tất cả" không phải là vấn đề; Đó là tình huống tương tự mà chúng tôi, với tư cách là nhà phát triển, đã đến lúc hợp nhất mã nguồn của chúng tôi với một thành viên khác trong nhóm nhà phát triển: trong trường hợp đó, chúng tôi có các hệ thống kiểm soát nguồn làm nên điều kỳ diệu. Câu hỏi của tôi liên quan nhiều hơn đến cơ hội hợp nhất những thứ "không phải dev" như cài đặt cấu hình và các mục và cài đặt quản trị thông thường.

— Alessandro Ronchi

À, điều đó làm cho nó rõ ràng hơn

— Rutger

Giả sử chúng tôi đang tạo một trang web hoàn chỉnh mới, vì vậy không có vấn đề gì với dữ liệu cũ, v.v ... Hầu như tất cả các nhà phát triển của chúng tôi đều sử dụng cùng một cơ sở dữ liệu để phát triển. Điều đó giải quyết rất nhiều vấn đề. Đối với các trường hợp khác, tôi không có giải pháp nào tốt hơn là viết ra tất cả các bước cần thiết trong một số loại lộ trình / kịch bản và gửi lại tất cả chúng sau khi hợp nhất. Nếu chỉ có một người chịu trách nhiệm cho cài đặt quản trị "lõi magento" thì không nên thực hiện nhiều bước. Tôi đã từng tìm thấy cái này, nhưng chưa bao giờ dùng thử tinybrick.com/magento-modules/admin-tools/ mẹo

— Rutger

2

Tôi muốn thêm hai công cụ tiết kiệm thời gian tuyệt vời:

Để phát triển: PhpStorm IDE với plugin Magicento
Để triển khai: Magentify , một công thức Capistrano cho Magento

— hệ điều hành
nguồn

Cảm ơn bạn đã thông báo cho chúng tôi về Magentify, tôi đã không biết điều đó và tôi sẽ thử. Mặc dù vậy, trọng tâm của tôi là tập trung vào việc đồng bộ hóa môi trường phát triển khác nhau hơn là triển khai theo nghĩa xuất bản một cơ sở mã. Mageploy có thể được tích hợp với Magentify nhưng là một công cụ khác, được sử dụng để tự động giữ một số thay đổi cơ sở dữ liệu được căn chỉnh bất kể ID cụ thể khác nhau giữa các môi trường khác nhau. Trân trọng, Alessandro

— Alessandro Ronchi