タグ付けされた質問 「deployment」

開発サーバーにJenkinsCIをインストールして、開発ビルドとテストプロセスの自動化を開始しました。私はシェルスクリプトを介してGitプラグインといくつかのDrushコマンドでJenkinsを使用しています。 Drupal開発ワークフローでJenkinsを使用する方法を研究しているときに、PhingをDrushとJenkinsで使用することに関する投稿に出会いました。だから私はPhingを見て、シェルスクリプトを介してDrushコマンドを使用することでは不可能なことを理解できません。 Phingの使い方を学ぶことに時間を費やすことが理にかなっているかどうかを判断しようとしています。シェルスクリプトを介してPhingコマンドとDrushコマンドを組み込むことでどのようなメリットが得られるかについて、明確にしたいと思っています。 だから私の質問は、PhingをDrushとJenkinsで使用する人たちに対するものです。Drush/ Drush-MakeとPhingがどのように異なるのでしょうか。プロセスでPhingを使用することにしたのはなぜですか？ ありがとう

24 drush  deployment  jenkins 

複数のサイトに使用されるいくつかのカスタムモジュールがあります。これらは、たとえばクライアント固有であるため、提供されたモジュールとしてリリースすることはできません。提供されたモジュールなどでは機能しないという仮定を立てます。 これに対処する次の可能性について知っています。 コピーして貼り付けます。すべてのインストールでモジュールを最新の状態に保つのが明らかに難しくなります。 単一のマルチサイトインストールがありますが、これは常に可能とは限りません。 gitサブモジュールを使用しますが、それらは厄介な場合があり、更新するのを忘れがちであり、常にサポートされているわけではありません（例：Pantheon） 一般的なgitリポジトリからチェックアウトするmakeスクリプトを削除します。そのためには、サイト全体でdrush makeを使用する必要がありますが、現在は使用していません。 http://drupal.org/project/fserver。まだ試していませんが、十分に安定しているかどうかを誰かが知っていますか？プロジェクトの説明はあまり有望ではなく、7.xバージョンはありません。 他に何か良いですか？何が好きで、なぜですか？

19 version-control  deployment  drush 

一部のモジュールには、デルーチンルーチンがあります。通常、そのモジュールのデータベーステーブル、変数テーブルからの変数、およびそのモジュールによって導入されたロケールを削除します。これらのルーチンは.install、そのモジュールに存在します。 したがって、それらのモジュールが存在しないと実行できません。これが現在の手順です。私の質問は、これをより簡単に、より効果的に行うことができますか？foo_barモジュールを削除するとします。 RCSで、次の新しいリリースを準備します。 foo_barを使用または構築するすべてのcssおよびテーマオーバーライドは削除されます。 foo_barに依存するモジュールのすべてのcssおよびテーマオーバーライドは削除されます。 そのリリースを受け入れてください。運用データベースの最新のコピーを使用して、（admin / modulesからの）分散をテストします。 すべてうまくいけば、新しいコードベースを本番環境にデプロイし、foo_barとその依存関係をそこに配置します。これにより、さまざまなモジュールでアンインストールが呼び出され、データベースがクリーンアップされます。 RCS（git）で、コードが実際に削除される新しいリリースを準備します。 誤ってこれに依存していないかどうかをテストするために、それを受け入れます（一部のいモジュールまたはテーマ関数には、他のモジュールから直接ファイルが含まれます。特にCSS、JS、または画像ファイル）。 受け入れられたら、新しいリリースを実稼働環境にデプロイします。本番環境には、クリーンなデータベースとクリーンなコードベースがあります。 解決方法がわかりませんが、これには常に2つのリリースが必要です。Drupalでは、リリースにはサイトがオフラインである必要があるため、これは1つのモジュールを削除するために2回のダウンタイムを意味します。また、2つのリリース手順が必要です。これは、プロのホスティング環境では、非常に高価で、時間がかかり、イライラする可能性があります。 最初の反復でコードベースからモジュールを削除すると、アンインストールフックを実行できず、データベースに多くのリントが保持されます。いくつかのテーブルだけでなく、主に変数とロケール。モジュールをコードベースから削除しないと、コードベースが古くなった未使用のコードで成長することになります。これによりパフォーマンスのオーバーヘッドは発生しませんが、コードの維持はますます難しくなります。 これにどう対処しますか？ [編集：展開が困難な手順であるという注意を追加、多くの場合]

17 nodes  deployment 

私は「好きではないクローニング暗示ウェブサイト」ソリューションダンプデータベースを、別の環境でこのダンプをインポートします。これは、同じWebサイト（staging / prod / dev / etc）の複数のインスタンスをデプロイする現実の方法とは異なります。 D7では、通常、カスタムプロファイルを使用し、drushを使用してこれらのプロファイルからWebサイトをインストールしました（そして、後のサイト同期のために機能を使用する場合があります）。これにより、新規インストールが行われ、テストコンテンツは提供されませんでしたが、重要な設定は共有されました。たとえば、一般的なコンテンツの同期は、移行によって行われます。 同じインストールプロファイルを共有する複数のD8インスタンスを管理しようとしました。最終的な目標は、サイト構成を共有および同期することです。また、インストールごとに異なるサイトUUIDがあります。system.site uuidインストール時に設定変数を適用することに成功していません（もちろん後で値を変更できますが、これは遅すぎるようで、すべてのオブジェクトはすでに異なるUUIDで作成されているため、最初の同期は悪夢です、デフォルトのコンテンツを削除する必要がある場合や、デフォルトの言語を削除できないために同期がクラッシュする場合など）。 このUUIDを強制するために、$config['system.site']['uuid']内部に大きな値を持つ生成されたsettings.phpファイルを使用してみました（サイトのインストール後でも設定は完全に無視されました）。 また、構成インストーラーのプロファイルも確認しましたが、これは完全には理解していません。特に、このソリューションを別のインストールプロファイルと混在させる方法については理解していません。 質問は、インストールプロファイルから新しいサイトを展開する最良の方法は何ですか： 「ウェブサイトのクローン」を作成せず、サイトの作成時にSQLダンプを操作しません（クローンサイトの質問のように）。 エクスポートされた構成とコードのみを使用した、新規のクリーンインストール（開発者のコ​​ンテンツガベージなし） インストール構成のデフォルトと後の同期の両方を管理できます

15 8  configuration-management  deployment 

このテーマに役立つ既存のモジュールはあるのでしょうか。キャッシングモジュール（BoostやVarnishなど）を探しているのではなく、サイト全体（または特定のページのみ）を静的にエクスポートする方法を探しています。私のWebサーバーは非常にシンプルで軽量で、静的ファイル（html / css / js）のみを提供することを考えています-本番環境ではデータベースもPHPサーバーもインストールされません。すべてのDrupalエンジンは別のサーバー上にあり、ノードまたはビューを追加/編集/変更するたびにエクスポートが行われ、新しいhtmlファイルのセットがディレクトリ構造に作成されます。これらのファイルは、後で静的ファイルのみを提供する本番サイトにコピーされます。ファイルが存在する場合にリクエストをチェックする.htaccessなどはありません。 そのためのモジュール、またはこれがDrupalで達成できる回避策はありますか？ ありがとう

12 theming  importing-exporting  deployment 

「ユーザーインターフェイスの翻訳」/ admin / config / regional / translateで翻訳した文字列は、「構成管理」/ admin / config / development / configurationではエクスポートできません。何か不足していますか？ hook_update_Nまたはでこのプロセスを自動化したいと思いdrush cim -yます。 Drupal 8で「ユーザーインターフェイス翻訳」を自動的に展開する適切な方法は何ですか？ 私はそれをするべきhook_update_N()ですか？ mytranslations.po言語フォルダにカスタムファイルを作成する必要がありますか？ locale_translate_batch_import_files()使用されるかもしれないものがありそうです。

12 8  i18n-l10n  deployment 

どのようにして、drush makeファイルにcomposerパッケージを含めますか？ より一般的な答えが良いです。drush dlがcomposerパッケージを処理できるようにするcomposer drushモジュールはすでにありますが、すべての依存関係にシェルコマンドが必要です。 Symfony、composer、およびその他のSymfonyバンドルを将来使用することを考えると、将来、より重要になる可能性があります。

9 drush  deployment  composer  8 

共通のデータベースを指す複数の負荷分散サーバーがある状況があります。 通常の実行では、これは正常に機能し、冗長性、スケーラビリティなどを提供します。 ただし、展開は少し面倒な作業です。 私たちはさまざまな機能を使用しており、展開の自動化を試みています。現時点での展開はあまり信頼できません。 簡略化された形式では、各サーバーのデプロイスクリプトには2つの段階があります。 ファイルを更新する 機能を元に戻す（依存関係、設定変更などを管理します） 複数のサーバーを一貫性のない状態にせずに展開するためのベストプラクティスはありますか？ 手順1と2をサーバーAに展開するかどうかを確認すると、サーバーBが壊れます。両方のサーバーで手順1を試してから手順2に進むと、しばらくの間両方が壊れます。

8 deployment 

コンテンツの更新をステージングサーバーからライブサーバーに展開しようとしていますが、これを行うための適切な方法を見つけるのが困難です。新しいページ、ページの更新、場合によってはページの削除をデプロイできる必要があります。私たちのサイトでは、bookモジュールも多用しているため、現時点ではDeployモジュールは機能しません。大規模な構造の更新に機能を使用しています。したがって、私たちの懸念は、毎日のコンテンツの更新だけです。 これを実行して本のページを処理できるモジュールはありますか？

8 deployment  staging 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ Drupal Answersのトピックとなるように質問を更新してください。 2年前休業。 ステージングサーバーと運用サーバー間の展開を簡単にする必要があります。 これどうやってするの？すべての変更をデプロイする必要があるため、Githubからプルしてスクリプトを実行すると、変更が適用されます！ これのためにスクリプトやモジュールを書いた人はいますか？ Drupal 7を使用しています。

8 deployment