Magento 1：モジュール開発ワークフローの改善（Modman、composer、git）

これは私がかなり長い間念頭に置いていたものですが、それを行うための正しい方法を見つけることができません。

基本的に、6つの異なるWebサイトで作業しており、すべてMagento CE 1.9.2+を実行しています

それらのWebサイトでは、私と一緒に作業しているチームが開発した拡張機能（ここでは50以上の拡張機能を使用しています）を使用しており、それらの拡張機能のコードはBitbucketに保存されています。そのため、これらの拡張機能を管理しているのは私だけではありません。私たちは3人の拡張機能に取り組んでいます。

現時点で、これらの拡張機能の1つに機能を追加したりバグを修正したい場合のワークフローは次のとおりです。

Modman経由でWebサイトの1つに拡張機能の最新バージョンをインストールします
バグの修正/機能の追加/テスト
すべての拡張機能を含むローカルフォルダーに変更を手動でコピーする
この拡張フォルダーからGITを介してコミットし、Bitbucketにプッシュします（モジュールごとに1つのBitbucketリポジトリ）
その後、モジュールの新しいバージョンをModman経由でインストールできます

重要な注意：ここでは、シンボリックリンクなしでmodmanをハードコピーで使用しています。

私の最大の問題は太字で強調されています：問題の大きな原因であるため、この手順をスキップできるようにしたいです（いくつかのファイルは時々忘れられ、間違ったコピー/貼り付け、人間の行動が含まれます）。

したがって、この手動のコピー/貼り付け手順を取り除くために、どのようにワークフローを改善できますか？ここで提案を受け付けています。

— デジタルピアニズムのラファエル
ソース

Submodulesgitの機能を試しましたか？

— ゴパルパテル

なぜハードコピーを使用しているのですか？シンボリックリンクを使用すると、modmanフォルダーの下にgit cloneが必要になります。次に、その場で編集して、プッシュするだけです。

— フリストンのクリストフ

@KristofatFoomanそれを明確にすべきだった。

— 開発者の

@RaphaelatDigitalPianism chrisjean.com/git-submodules-adding-using-removing-and-dating

— Gopal Patel

@RaphaelatDigitalPianismのWindowsの問題については、github.com / sitewards / modman

— デビッドマナーズ

回答:

私は非常に頻繁に次のアプローチを取りますが、これはフレームワークにとらわれません。

編集するモジュールをチェックアウトします /path/to/my/module
作業用のブランチを作成します（関連するタグなどから分岐します）。
このブランチに作業をコミットします（プッシュしないでください）。
プロジェクトで、モジュールのローカルコピーにローカルリポジトリを定義します。これは、プロジェクトがLFSからプッシュされていない変更を取り込むことができるようにするためです。
```
{
    "repositories": [
    {
        "type": "path",
        "url": "/path/to/my/module"
    }
],
```
その後、コンポーザーは特定の開発ブランチを要求できます（プロジェクトでminimum-stability許可されている場合）。
```
composer require namespace/module dev-branch-name-here
```
プロジェクトのでコミットし/path/to/my/module、composer update namespace/moduleインストールとテストを確認します。
完了したら、コミットを押しつぶしてプッシュアップします。

https://github.com/Cotya/magento-composer-installerを使用したM1モジュールでは、この方法がうまく機能することがわかりました。 modmanによって。

興味のあるリンク

デバッグ

使用composer require namespace/module dev-branch-name-here -vvvローカルに使用することができます枝を参照してください。
モジュールをインストールするプロジェクトにminimum-stability設定さdevれていることを再確認してください。
Your requirements could not be resolved to an installable set

こちらの Patrick Schwisowのコメントを読んで発見。

変更しようとしているパッケージに他のパッケージの要件がある場合、開発ブランチがそれらの要件を満たさない可能性があります（「要件をインストール可能なパッケージのセットに解決できませんでした」）。これを修正するには、他のすべてのパッケージが特定のバージョンとしてそれを見るようにインラインエイリアスを行うことができます。

つまりcomposer.json、開発中にを更新して特定のバージョンに強制することができます。

"namespace/module": "dev-branch-name-here as 1.2.3"

— ルーク・ロジャース
ソース

ここで別の興味深いアプローチ。ご意見をお

— 寄せ

これは良いものです。path再利用しないプロジェクトモジュールにはタイプリポジトリを使用し、再利用するモジュールにはgitまたはpackagist を使用する傾向があります。

— デビッドマナーズ

@DavidManners上記のフローをsatisと組み合わせて使用します。モジュールは永続的に使用されていますが、ローカルでテストして実行するまで、メインラインに何かを押し上げたくありません。したがって、上記のワークフローを使用してから、プッシュしてタグを付け、サティスがそれを取得するのを待ちます。

— ルークロジャース

@LukeRodgers、このワークフローではmodmanをまったく使用せず、すべてのモジュールファイルはmagentoファイル内に配置されますか？（拡張機能用の.modmanフォルダーはありません）。私はそれを正しく理解しましたか？

— MployBy

ちょっと@MployBy、私はmodmanを直接使用しません。ただし、Cotya / magento-composer-installerがボンネットの下で使用するかどうかはわかりません。新しいmagento1モジュールをセットアップしてからしばらく経ちました。

— ルークロジャース

ここでは、シンボリックリンクなしでmodmanとハードコピーを使用しています。

あなたの問題があります。ショップの展開に合わせてこの設定を変更できない場合は、シンボリックリンクでmodmanを使用する別のインスタンスで共有拡張機能を使用することを検討してください。

私は、AOEコンポーザーインストーラーでコンポーザーを使用して、拡張リポジトリを直接クローンします.modmanが、modmanを使用してGitからモジュールをインストールすることもできます。いずれにしても、モジュールGitリポジトリで直接作業できます。

— ファビアン・シュメングラー
ソース

私がコメントで言ったようにうん、その理由は、DEVが使用するWindowsとIIRCの一つであり、我々は彼がシンボリックリンクで使用していくつかの問題があった

— デジタルPianismでラファエルを

ああ、私はそれを見ませんでした。その

— 開発者に

ですから、ここでの私のアイデアは、Magento1でも作曲家と仕事を始めることです。独自のpackagistをお持ちの場合は、awsとgoogleクラウドが適切に配置されているため、管理するのはそれほど難しくありません。または、公開packagistを使用できます。Magento1ショップの新しいバージョンに「簡単に」アクセスできます。

これは、新しいバージョンがリリースされたときにcomposer update、コピープロセスが自動化されることを意味します。

見ていhttps://github.com/Cotya/magento-composer-installer作曲経由Magento1のために。

このアプローチを使用すると、ベンダーフォルダーの下にあるgitリポジトリを直接コピーするように設定している場合、gitリポジトリで直接作業.gitできるため、別のチェックアウトなしでリポジトリに変更をプッシュバックできます。ここでは注意が必要であることに注意してください。また、自分がどのブランチにいるのかを確認する必要があります。そうでない場合は、コードを削除できます（数回実行します）。

— デビッド・マナーズ
ソース