모듈 개발을위한 버전 관리

단일 Magento 인스턴스에서 모두 사용하고 커뮤니티 모듈로 릴리스하려는 모듈을 개발하기 위해 버전 제어에 관한 좋은 규칙이 있는지 궁금합니다.

처음에 내가 시도한 것은 modman을 사용하여 메인 Magento 인스턴스 저장소 외부의 모듈을 관리하는 것이 었습니다. 그러나 그것은 여러 수준에서 문제가되었습니다. 다른 환경에 쉽게 설치하거나 프로덕션 환경으로 롤백 할 수있는 단일 리포지토리를 갖는 것이 매우 유용하며 워크 플로의 필수 부분이되었습니다.

내가 현재하고있는 일은 내 사이트 저장소 내에서 개발 중이며 곧 별도의 저장소로 분리 할 계획입니다. 그 시점에서 내가 할 일은 다음과 같습니다.

• modman을 사용하여 개별 모듈 저장소 내의 로컬 환경에서 빌드
• 코드를 배포 할 준비가되면 변경 사항을 사이트 리포지토리에 복사

더 좋은 방법이 있기를 바라고 있습니까?

이 작업을 수행 한 몇 가지 모듈이 있으며 본질적으로 수행 한 작업은 다음과 같습니다.

• 모듈에 대한 Git 저장소를 설정하십시오.
• 이 모듈을 프로덕션 사이트의 코드베이스에 배치하고 다음을 포함한 모든 것을 커밋하십시오.
  • modman이 만든 소프트 링크
  • 복제 된 모듈 저장소를 저장하는 .modman 디렉토리
• modman을 사용하여 개발 및 테스트를 위해 다른 버전 및 / 또는 개발 환경에 "배포"하십시오.

이 방법을 사용하면 모듈 개발에 필요한 유연성을 확보하고 단일 사이트의 코드도 버전 화하며 단일 사이트 코드베이스에서 모듈을 변경하면 모듈 저장소에 직접 커밋 할 수 있습니다. repo는 .modman 디렉토리에 있습니다.

업데이트 : 처음에 이것을 썼을 때 나는 Git이 (서브) 모듈을 저장소에 커밋 할 수 없다는 것을 내 대답으로 고려하지 못했습니다.이 경우 "모든 것을 커밋"하는 데 약간의 정교함이 필요합니다!

덧붙여서, 이것은 modman을 사용하여 Git 저장소에 저장된 모듈을 SVN에 저장된 프로덕션 코드베이스에 배포하기 위해 더 자주 수행했기 때문입니다 ... Subversion에는 전체 Git 트리를 VCS에 커밋하는 것을 막는 스크럽이 없습니다.

여기로갑니다…

1. SVN을 사용하여 프로덕션 사이트의 코드를 저장하는 경우 Subversion에 하위 모듈 개념이 없기 때문에 문제가 없습니다. 상관 없어요

2. 프로덕션 사이트의 코드에 Git을 사용하는 경우 하위 모듈을 사용하여 사이트의 코드 리포지토리에 "모든 것을 커밋"해야합니다. modman을 사용하여 다음과 같이 복제 한 후 :

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

   또한 다음과 같이 하위 모듈로 추가하고 싶을 것입니다.

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

   이 작업을 완료하면 .modman 디렉토리 및 .gitmodules 파일을 색인에 추가하고 커밋 할 수 있어야합니다.

   modman을 통해 설치된 이러한 모듈을 사용하는 저장소를 복제 한 후에는 하위 모듈을 초기화하고 업데이트하십시오.

   git submodule init
   git submodule update

추신 : 나는 이제 모든 새로운 프로젝트에서 Git 풀 타임을 사용 하므로이 감독이 다시는 일어나지 않기를 바랍니다. 미안해 ;)

현재의 협약은 다음을 지원하는 것 같습니다.

• 작곡가-http: //getcomposer.org/
• Modman- https: //github.com/colinmollenhour/modman
• 깃 허브 레포

디렉토리 구조에 있어서는 최소한이며 모듈은 커뮤니티 코드 풀에 설치되는 것이 가장 좋습니다.

최소 권장 디렉토리 구조는 다음과 같습니다.

.
└── 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

선택 사항 / 좋아하기 :

• 설명, 스크린 샷 및 글 머리 기호 기능이있는 Github 랜딩 페이지
• 설치된 데모 저장소로 연결해도 좋습니다.
• 제품의 스크린 캐스트 / 2 분 개요

편집 : 오해했을 수도 있습니다.

modman / gitignore 조합을 사용하면 테스트 환경에서 모듈을 분리 할 수 ​​있습니다. 위의 폴더 구조를 사용하면 모듈 파일 만 리포지토리에 커밋 / 설치할 수 있습니다. 이 경우 David의 대답이 더 적합합니다. dev / deploy에 대한 Modman의 지원은 합의 된 것으로 보입니다.

아직 직접 시도하지는 않았지만 작곡가 를 사용하는 것이 좋습니다 .

종속성을 포함한 버전 관리

유지함으로써 composer.lock저장소에 파일을, 당신은 모든 모듈의 버전을 수정하고 있습니다 항상 당신의 VCS (사용하여 특정 버전 (지점, 태그 또는 이전 버전)을 복원 git checkout, svn ..다음) 등을 composer.phar install.

단점

발생하는 문제는 배포가 여러 지점 (예 : GitHub)에 쉽게 의존하여 여러 지점에서 오류를 발생시킬 수 있다는 것입니다.

따라서 이러한 모듈을 저장하는 캐시 또는 프록시가 필요하므로 항상 배포 할 수 있습니다.

Satis는이 목적 ( https://github.com/researchgate/broker 참조 )과 내 질문 /programming//q/16211671/288568 을 제공 할 수있는 것 같습니다

칼렌,

어쩌면 나는 워크 플로우를 제대로 잡지 못했지만 마 젠토 저장소에서 로컬로 개발 한 다음 modman 저장소로 분리하는 것처럼 들렸습니다. IDE에서 ./modman/modulesname/CONTENTS를 편집하고 개발에 사용하는 것과 동일한 작업 흐름에서 독립적으로 코드를 모듈 저장소에 푸시하지 마십시오. modman을 사용하여 프로덕션 환경에 배포하거나 cli의 .modman / modulesname / 폴더에있는 개별 리포지토리와 상호 작용하거나 IDE에 버전 관리 소스를 추가하여 실제로 .basedir을 사용하여 저장소에 연결된 경로를 유지 webroot가 더 잘 재생됩니다.

많은 사람들이 사용하지 않는 것 같은 modman의 멋진 기능도 있습니다. bash 스크립트는 파일이 존재하지 않으면 .modman 저장소의 .basedir 파일을 해석합니다. modman이 modman 파일과 동일한 레벨에서 modman 파일의 symlink 규칙을 적용합니다 ... .basedir 파일이 존재하는 경우 내용은 Magento 코드의 최상위 레벨 인 .modman 경로에서 하위 폴더를 설명합니다. 즉, 'BaseMagento1.9.1.0'과 같은 폴더에서 모든 기본 Magento 버전을 실행할 수 있습니다. 'BaseMagento1.14.2.0'및 modman은 이들을 포함하는 폴더를 초기화합니다. .basedir 파일을 .modman 경로에 추가하면 내용을 쉽게 변경할 수 있습니다. 이것은 버전 테스트에 효과적입니다.