本番用のMagento2 CIサーバー統合

回答:

1

現在、Magento 2の導入プロセスの改善に取り組んでいます。ご意見やご感想をお待ちしています。Twitterまたはメールでpingを送信してください。

今M2であなたは（あなたの環境で）次のことをするでしょう

  • コードの取得または更新（git / etc ...）
  • 作曲家のインストール
  • bin / magento setup：upgrade（またはsetup：install）
  • bin / magentoセット：モードの生成

FYIセット：モードの生産は

  • bin / magentoのセットアップ：di：compile
  • bin / magento setup：static-content：deploy

2ステップのビルドおよびデプロイプロセスに近づくために現在使用できるいくつかの他のアプローチがありますが、それらはかなり複雑です。

— チャック
ソース
チャック、より複雑な展開プロセスについて詳しく説明してもらえますか？
— チツェ2017年
これは開発中です-作成し、次のリリース（2.2）の一部としてリリースします。メインラインに追加した新しいCLIコマンドのいくつかを確認してください：app：config：dump、app：config：import、config：sensitive：set、config：set、config：show、setup：db：status。アイデアは、開発マシンにMagentoをインストールし、管理パネルで必要に応じて構成することです。app：config：dump（config.php、env.phpで終わる）を実行し、コンパイルしてstatic-assetをデプロイします。次に、コード（アセットを含む）を本番環境にコピーし（必要に応じてenv.phpファイルをコピーしてスウィズルします）、次に製品のsetup：upgradeを実行します。
— チャック
基本的には2パスのデプロイ操作です。最初のパスは開発マシンで行われ（つまり、本番のダウンタイムはありません）、2番目のパスは本番で行われます（コードのコピー+スキーマの変更がある場合は潜在的なダウンタイム（setup：upgrade））。目標は、スキーマ変更を伴う本番稼働での1分未満のダウンタイムです。
— Chuck
提案：本番環境で「composer install」を実行しないでください！Packagistまたはrepo.magento.comがダウンした場合の重大な問題を回避するために、CIプロセスの展開前の段階で行う必要があります。事前デプロイする他のmagentoコマンドを実行することもできます。代わりに事前コンパイルされたアーティファクト（パッケージ）をデプロイする場合、DBに対して「magento setup：upgrade」以外を実行する必要はありません。コードが本番環境に到達すると、キャッシュがフラッシュされます。スキーマを変更した場合でも、ダウンタイムを数ミリ秒（または数秒）に最小限に抑えます。
— Gabriel Somoza
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.