Kiểm soát phiên bản để phát triển mô-đun

Tôi tự hỏi liệu có bất kỳ quy ước tốt nào không, theo như kiểm soát phiên bản, để phát triển một mô-đun mà bạn đang sử dụng cả trong một phiên bản Magento duy nhất và cũng muốn phát hành dưới dạng mô-đun cộng đồng.

Ban đầu, những gì tôi đã cố gắng làm là sử dụng modman để quản lý mô-đun bên ngoài kho lưu trữ đối tượng Magento chính của tôi. Nhưng điều đó đã kết thúc vấn đề ở nhiều cấp độ. Có một kho lưu trữ duy nhất mà bạn có thể dễ dàng cài đặt vào các môi trường khác nhau hoặc quay trở lại sản xuất là vô cùng hữu ích, và tôi thậm chí có thể nói đã trở thành một phần cần thiết trong quy trình làm việc của tôi.

Những gì tôi đang làm hiện đang phát triển nó bên trong kho lưu trữ trang web của tôi và đang có kế hoạch sớm chia nó thành một kho lưu trữ riêng biệt. Tại thời điểm đó, những gì tôi có thể sẽ làm là:

• Xây dựng trong môi trường cục bộ của tôi trong kho lưu trữ mô-đun cá nhân bằng cách sử dụng modman
• Sao chép các thay đổi vào kho lưu trữ trang web khi tôi sẵn sàng triển khai mã

Hy vọng có một cách tốt hơn?

Chúng tôi có một vài mô-đun nơi chúng tôi đã thực hiện điều này và về cơ bản chúng tôi đã làm là:

• Thiết lập repo Git cho mô-đun.
• Triển khai mô-đun này vào cơ sở mã của trang sản xuất và cam kết mọi thứ bao gồm:
  • liên kết mềm được tạo bởi modman
  • thư mục .modman chứa kho mô-đun nhân bản
• Sử dụng modman để "triển khai" nó vào các phiên bản khác và / hoặc môi trường dev để phát triển và thử nghiệm.

Làm theo cách này giúp bạn có được sự linh hoạt cần thiết cho việc phát triển mô-đun, phiên bản mã trên trang web đơn và nếu bạn thay đổi mô-đun trong cơ sở mã cơ sở một trang, bạn có thể đưa những thứ đó trở lại kho lưu trữ mô-đun kể từ đó repo là có trong thư mục .modman.

CẬP NHẬT: Khi ban đầu tôi viết bài này, tôi đã không tính đến câu trả lời của mình rằng Git không cho phép các mô-đun (phụ) được cam kết với một kho lưu trữ, trong trường hợp đó là "cam kết mọi thứ" cần một số chi tiết!

Ngẫu nhiên, điều này là do tôi đã thực hiện việc này thường xuyên hơn bằng cách sử dụng modman để triển khai các mô-đun trong Git repos thành một cơ sở mã sản xuất được lưu trữ bởi SVN và Subversion không ngăn cản việc đưa toàn bộ cây Git vào VCS.

Vậy là đi đây

1. Nếu bạn đang sử dụng SVN để lưu mã của trang sản xuất, bạn sẽ không gặp vấn đề gì vì Subversion (thực tế) không có khái niệm về các mô-đun phụ. Nó không phiền đâu.

2. Nếu bạn đang sử dụng Git cho mã của trang sản xuất, bạn sẽ phải sử dụng các mô-đun phụ để "cam kết mọi thứ" với kho lưu trữ mã của trang. Sau khi sử dụng modman để sao chép một cái gì đó như thế này:

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   Bạn cũng sẽ muốn thêm nó dưới dạng một mô-đun phụ như vậy:

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   Một khi bạn đã làm điều này, bạn sẽ có thể thêm thư mục .modman và tệp .gitmodules vào chỉ mục và cam kết nó.

   Sau khi nhân bản kho lưu trữ đang sử dụng các mô-đun này được cài đặt qua modman, chỉ cần khởi động lại các mô đun con và cập nhật:

   git submodule init
   git submodule update

PS Bây giờ tôi sử dụng Git toàn thời gian cho tất cả các dự án mới, vì vậy hy vọng việc giám sát này sẽ không xảy ra lần nữa. Xin lỗi các bạn. ;)

Có vẻ như quy ước hiện tại là cung cấp hỗ trợ cho:

• Nhà soạn nhạc - http://getcomposer.org/
• Modman - https://github.com/colinmollenhour/modman
• Github repo

Theo cấu trúc thư mục, mô-đun tối thiểu và tốt nhất là mô-đun được cài đặt trong nhóm mã Cộng đồng.

Một cấu trúc thư mục được đề xuất tối thiểu sẽ là:

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

Tùy chọn / tốt đẹp để có:

• Trang đích Github với một mô tả, một số ảnh chụp màn hình và một số tính năng gạch đầu dòng.
• Liên kết với một cửa hàng demo được cài đặt cũng sẽ rất tốt
• Tổng quan về screencast / hai phút về sản phẩm của bạn

Chỉnh sửa: Tôi có thể đã hiểu lầm.

Sử dụng kết hợp modman / gitignore có thể giữ cho mô-đun của bạn tách rời khỏi môi trường thử nghiệm của bạn. Sử dụng cấu trúc thư mục ở trên, bạn chỉ có thể cho phép rõ ràng các tệp của mô-đun được cam kết / cài đặt vào repo của mình. Trong trường hợp này, câu trả lời của David được áp dụng nhiều hơn. Modman hỗ trợ cho dev / triển khai dường như là sự đồng thuận.

Ngay cả khi chưa thử nó, tôi vẫn khuyên bạn nên sử dụng trình soạn nhạc cho điều đó.

Phiên bản bao gồm cả phụ thuộc

Bằng cách giữ composer.locktệp trong kho lưu trữ, bạn sửa các phiên bản của tất cả các mô-đun và luôn có thể khôi phục một phiên bản cụ thể (nhánh, thẻ hoặc phiên bản cũ hơn) bằng cách sử dụng VCS ( git checkout, svn ..) của bạn composer.phar install.

Hạn chế

Một vấn đề phát sinh là việc triển khai của bạn có thể dễ dàng phụ thuộc vào nhiều nguồn (ví dụ GitHub) tạo ra nhiều điểm thất bại.

Vì vậy, chúng tôi sẽ cần một số loại bộ đệm hoặc proxy lưu trữ các mô-đun đó để chúng tôi luôn có thể triển khai.

Satis dường như có thể phục vụ mục đích này (xem https://github.com/researchgate/broker ) và câu hỏi của tôi /programming//q/16211671/288568

Kalen,

Có thể tôi không hoàn toàn nắm bắt được quy trình làm việc của bạn, nhưng có vẻ như bạn đang phát triển trong một repo magento cục bộ, sau đó tách thành một repo modman. Tại sao không chỉ chỉnh sửa ./modman/modulesname/CONTENT trong IDE của bạn và đẩy mã vào mô đun repo một cách độc lập trong cùng một luồng công việc bạn sử dụng để phát triển. bạn có thể sử dụng modman để triển khai vào sản xuất, bạn có thể tương tác với repo riêng lẻ trong thư mục .modman / modulename / từ cli hoặc bằng cách thêm một nguồn phiên bản vào IDE của bạn, mặc dù thực sự sử dụng .basingir để tránh các đường dẫn liên kết kho lưu trữ của bạn ra khỏi webroot sẽ chơi tốt hơn.

Ngoài ra còn có một tính năng rất hay của modman mà nhiều người dường như không sử dụng. Tập lệnh bash diễn giải tệp .basingir trong kho .modman, nếu tệp không tồn tại modman sẽ áp dụng quy tắc symlink trong tệp modman ở cùng cấp với thư mục .modman ... nếu tệp .basingir tồn tại, nội dung mô tả một thư mục con là cấp cao nhất của mã Magento của bạn xuống từ đường dẫn .modman ... nói cách khác, bạn có thể chạy (và tôi làm) tất cả các phiên bản Magento cơ bản trong các thư mục như 'BaseMagento1.9.1.0' 'BaseMagento1.14.2.0' và modman khởi tạo thư mục chứa những thứ này. Thêm tệp .basingir vào đường dẫn .modman và bạn có thể thay đổi nội dung một cách dễ dàng. Điều này hoạt động tốt để thử nghiệm phiên bản.