モジュール開発のバージョン管理

バージョン管理に関する限り、単一のMagentoインスタンスで使用し、コミュニティモジュールとしてリリースしたいモジュールを開発するための良い慣習があるかどうか疑問に思っています。

最初にやろうとしたことは、modmanを使用してメインのMagentoインスタンスリポジトリの外部でモジュールを管理することでした。しかし、それは最終的に複数のレベルで問題になりました。異なる環境に簡単にインストールしたり、本番環境にロールバックしたりできる単一のリポジトリを持つことは非常に便利であり、ワークフローの必要な部分になったとさえ言えます。

現在私がやっていることは、サイトリポジトリ内で開発することで、すぐに別のリポジトリに分割することを計画しています。その時点で、私がしそうなことは次のとおりです。

• modmanを使用して、個々のモジュールリポジトリ内のローカル環境でビルドします
• コードを展開する準備ができたら、変更をサイトリポジトリにコピーする

もっと良い方法がありますか？

これを行ったモジュールがいくつかあり、基本的には次のことを行いました。

• モジュールのGitリポジトリをセットアップします。
• このモジュールを実稼働サイトのコードベースにデプロイし、以下を含むすべてをコミットします。
  • modmanによって作成されたソフトリンク
  • クローン化されたモジュールリポジトリを格納する.modmanディレクトリ
• modmanを使用して、開発およびテスト用に他のバージョンや開発環境に「展開」します。

このようにすると、モジュール開発に必要な柔軟性が得られ、単一サイトのコードもバージョン管理されます。また、単一サイトのコードベースでモジュールに変更を加えた場合、モジュールリポジトリに直接コミットできます。リポジトリは.modmanディレクトリにあります。

更新： 私が最初にこれを書いたとき、Gitは（サブ）モジュールをリポジトリにコミットすることを許可していないという私の答えを考慮に入れませんでした。その場合、「すべてをコミットする」種類の精緻化が必要です！

ちなみに、これはmodmanを使用してGitリポジトリに格納されているモジュールをSVNに格納されている製品コードベースに展開する頻度が高くなっているためです。

だからここに行く...

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

PS私は現在、すべての新しいプロジェクトでGitをフルタイムで使用しているので、この見落としが二度と起こらないことを願っています。ごめんなさい ;）

現在の慣例では、次のサポートを提供しているようです。

• Composer- http://getcomposer.org/
• Modman- https://github.com/colinmollenhour/modman
• Githubリポジトリ

ディレクトリ構造に関しては、最低限必要であり、できればモジュールはコミュニティコードプールにインストールされます。

最低限必要なディレクトリ構造は次のとおりです。

.
└── 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の答えがより適切です。mod / dev / deployのサポートはコンセンサスのようです。

まだ自分で試していない場合でも、そのためには作曲家を使用することをお勧めします。

依存関係を含むバージョン管理

composer.lockファイルをリポジトリに保存することにより、すべてのモジュールのバージョンを修正し、VCS（、）を使用して常に特定のバージョン（ブランチ、タグ、または古いバージョン）を復元できます。git checkoutsvn ..composer.phar install

欠点

発生する問題は、デプロイメントが複数のソース（GitHubなど）に簡単に依存して、複数の障害点を作成する可能性があることです。

したがって、これらのモジュールを格納するキャッシュまたはプロキシが必要になるため、常にデプロイできます。

サティスはこの目的に役立つようです（https://github.com/researchgate/brokerを参照）と私の質問/programming//q/16211671/288568

カレン、

たぶん私はあなたのワークフローを正しく捉えていなかったかもしれませんが、あなたはローカルでmagentoリポジトリで開発し、modmanリポジトリに分離しているように聞こえました。IDEで./modman/modulesname/CONTENTSを編集し、開発に使用するのと同じワークフローでモジュールリポジトリにコードを個別にプッシュしないのはなぜですか。modmanを使用して実稼働環境にデプロイできます。CLIから.modman / modulesname /フォルダー内の個々のリポジトリと対話するか、バージョン管理ソースをIDEに追加します。ただし、実際には.basedirを使用してリポジトリリンクパスをwebrootはより良くプレイされるでしょう。

また、多くの人が使用していないように思えるmodmanの素晴らしい機能もあります。bashスクリプトは、.modmanリポジトリ内の.basedirファイルを解釈します。ファイルが存在しない場合、modmanは.modmanフォルダーと同じレベルでmodmanファイル内のシンボリックルールを適用します... .basedirファイルが存在する場合、内容は、.modmanパスから1つ下のMagentoコードの最上位にあるサブフォルダーを記述します。つまり、「BaseMagento1.9.1.0」などのフォルダーですべての基本Magentoバージョンを実行できます'BaseMagento1.14.2.0'およびmodmanはこれらを含むフォルダーを初期化します。.basedirファイルを.modmanパスに追加すると、内容を簡単に変更できます。これはバージョンテストに適しています。