「バージョン管理、drush_make、Aegirを使用したDrupalのデプロイとワークフロー」について、mig5.netからこの記事を読みました。ここで説明するワークフローの効率に感銘を受け、これを本当に実装したいと思っています。何度も読みましたが、はっきりしないことが1つあります。
Webサイトの開発中に、変更を次のビルドにどのように取り入れますか？追加のモジュールが必要だとわかったとき、（たとえばcontrib）モジュールがgitで制御されていないときに、次のビルドでこれをどのように入手できますか？モジュールやライブラリなどを追加するたびに.makeファイルを編集する必要がありますか？
前もって感謝します。
回答:
はい。短い答えは、Drush makeファイルを更新して、新しいプラットフォーム（ビルド）に含めたいモジュールの新しいバージョンを指すようにすることです。
drush makeファイルには、プラットフォームビルドに含める各モジュールのバージョンを含めます。たとえば、ビューは次のようになります。
projects[views][subdir] = "contrib"
projects[views][version] = "3.4"新しいバージョンのViewsモジュールに更新したい場合は、makeファイルを次のように更新します。
projects[views][subdir] = "contrib"
projects[views][version] = "3.5"次に、この更新されたdrush makeファイルを使用して、Aegirで新しいプラットフォームを構築します。次に、サイトを新しいプラットフォームに移行すると、Aegirが更新を行います。
これはかなり洗練されたワークフローです。私はすべてのDrushメイクファイルをビルドと呼ばれるリポジトリに保存しているので、プロジェクトの各ビルドの記録を取得できます。お役に立てば幸いです。
ボブは私をそれに打ちのめしました:)しかし、これとあなたが私に送ったあなたの電子メールへの応答で、はい、確かにこれは正しい手順です。Drushメイクファイルをアプリケーションの「青写真」として扱います。
手動で開発に取り掛かる/ライブサイトのクローンを作成し、モジュールを手動で「drush up」または「drush dl」して、すべてが期待どおりに機能することをテストします。
次に、その新しいモジュール/更新バージョンをmakefileに組み込み、makefileが更新されるたびに新しいプラットフォームを構築し、「移行」タスクを使用してアプリケーションをターゲットプラットフォームに「アップグレード」します。
アップグレード中に問題が発生した場合（たとえば、移行中にデータベースにスキーマ更新を適用するために発生するdrush updatedb中に）、Aegirは、ほとんどの場合、以前のプラットフォームに自動的にロールバックします。これがこのようなシステムの魅力です。 。