タグ付けされた質問 「version-control」

コンピュータファイルとして保存されているドキュメントやその他の情報に対する変更の管理に使用します。

4
dev-> stage-> productionから移行(CMI)構成に推奨されるワークフローは何ですか?
数か月前にdrupalcampがあり、誰かが新しい設定(CMI)システムを使用した展開の管理について質問しました。考えられる理想的なワークフローの1つは、構成をバージョン管理に保持し、チームメンバー間で構成を移行できるようにすることです。 部屋で私たちが理解できた最高の部分は(部分的にはDrupalConポートランドでのプレゼンテーションに基づいて)でした: アクティブな設定ディレクトリを無視するようバージョン管理に指示します。 すべての構成をステージングディレクトリにコピーし、バージョン管理にコミットします。 また、settings.phpを使用して、2つの環境間でアクティブ/ステージングディレクトリをリバースします。ただし、あるサーバーから次のサーバーへの展開ワークフローを把握することは複雑でありながら実行可能ですが、複数のローカル環境(つまり、複数の開発者)からdev(または相互)への推奨されるワークフローは何ですか?同じまたは類似の環境を共有している場合、あるチームメイトのマシンでの変更はどのように反映されますか?

1
サイトをバージョン管理し、継続的統合環境をセットアップする必要があります
私は、(開発者ごとに)バージョン管理を必要としないほど小さく始まったDrupal 6xプロジェクトの起業家ですが、今ではそれなしには方法がないと確信しています。JIRAに関する豊富なドキュメントがあり、すべてを網羅した適切に記述されたユーザーストーリーを備えています。私はこれをどのように行うことができるかについて少し読んで、次の計画を思いつきました- モジュールを使用してデータベースからサイトコードを分離する 状況 特徴 強い腕 プロファイラー SVNリポジトリにコードを配置し、ステージングサイトを作成します EC2実稼働サーバーでステージングサーバーのミラーを作成します Seleniumテストを作成し、Saucelabsを使用してクラウド上で実行します Elastic Bambooを使用してJIRA Studioでビルドワークフローを作成し、自動更新を実行します Drush Makeを使用してプロファイルを更新およびインストールする 実稼働サーバーで更新を実行します(方法はわかりません) まず、コンポーネント(ビュー、コンテンツタイプ、モジュールなど)を含む約50の「機能」のリストを作成しました。サイトには約12個のカスタムモジュールとWebサービスが含まれており、カスタムコード(ほとんどの場合、アップグレード可能なビューまたはモジュールに変換したい)を含むコンテンツタイプの「アプリケーション」のインスタンスが10個あるため、これは間違いなく困難です。良い点は、サイトがまだ運用されていないため、リスクがまだ限られていることです。 誰かが似たようなことをした経験はありますか?どのような落とし穴や制限に遭遇するでしょうか?上記の計画を改善/修正するための提案、またはそこにいる専門家が私に持っているかもしれない洞察やアドバイスをいただければ幸いです。

3
Drushを使用したモジュールの新しい開発バージョンへの更新(バージョン管理を破壊することなく、ポイント/推奨リリースを無視)
[NBこの質問は、私の以前の質問の裏にありますが、ここでは別です。 私はDrushをずっと使ってきましたが、たびたび困惑します。現時点では、これをどのように実行するのか本当にわかりません。 シナリオ:現在、このサイトでは過去の方法で開発リリースを使用しています。それまでの間、ポイントリリースは作成されていませんが、新しいリリースは作成されています。次のようなものがあります。 Reroute Email 6.x-1.x-dev (2010-Sep-27) Recommended version: 6.x-1.0 (2008-Jul-24) Development version: 6.x-1.x-dev (2011-Feb-25) これdrush dl <module>-6.x-1.x-devにより、既存のディレクトリが最新の1.x devリリースで上書きされます。それは問題ありませんが、.svnフォルダーを破壊します。 もしそうならdrush upc <module>、それは私が望んでいないポイントリリースをダウンロードします(以下の編集を参照)が、もしそうならdrush upc <module>-6.x-1.x-dev、それは単に更新データを更新し、それから関連する行に「指定されたバージョンが既にインストールされています」と教えてくれます出力。 それでは、SVNフォルダーを破棄せずに、drushを使用して古いdevリリースを上書きし、代わりに新しいリリースを取得する方法を教えてください。 編集:実際には、この例でdrush upc <module>は、正しいバージョンをダウンロードしますが、ポイントリリースが6.x-1.0(2011-Jan-24)のように日付が付けられていれば、それが得られたはずです。誰もが明確/修正したいですか?

2
3開発環境で機能モジュールを使用する方法は?
Featuresを多用してプロジェクトに取り組んでいるとき、このアプリケーションには3人の開発者がいることがあります。 いくつかのアプローチを試しましたが、gitブランチをマージすると、お互いの機能の変更を「上書き」することが多いようです。競合がたくさんあり、機能モジュールが壊れて使用するのが苦痛になっているようです。 機能は、プロジェクトでの設定のための本当に素晴らしい時間節約であり、私はこれに取り組む方法があると確信しています。 競合や上書きのリスクを減らすワークフローまたは手順はありますか? 機能に関する手がかりは大歓迎です。

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

1
セキュリティパッチのみでDrupal 7 Coreを更新するにはどうすればよいですか?
古いDrupal 7をインストールしており、Drupal 7を最新リリースに更新したいのですが、カスタムモジュールの一部が最新の更新で破損することは事実です。 インストールしたいのは、最新のDrupal 7までのセキュリティパッチだけです。これはどのように行うことができますか、それとも多大な労力なしで可能です。また、Drupal 7コアの更新中にパッチが適用される内容をどこでどのように表示できますか?

2
パッチファイルを適用するにはどうすればよいですか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? Drupal Answersのトピックになるように質問を更新します。 5年前に閉鎖されました。 mailhandlerモジュールからパッチファイルをダウンロードしました。ダウンロード(インポート)後にpop3アカウントがメールを削除しないという問題を修正するには、変更を適用する必要があります。どうすればインストールできますか?


3
Gitリポジトリと本番Webサイトを壊さずにDrupalコアをアップグレードするためのベストプラクティスは何ですか
すべてのコードがmasterブランチにあるGitリポジトリがあり、以前はすべてのDrupalファイルを無視していたので、自分が書いた(または変更した、または変更する可能性のある)コードとコードを厳密に分離していましたDrushなどで生成できます。 Drupalをアップグレードするまで、これは良い戦略のように思えました。物事がうまくいかなかった場合にロールバックできるようにしたいこと、そしてそれを行うためにGitよりも優れたツールを使用したいと思いました。私はこれが機能ブランチに最適な状況だと思ったので、drupal-7.14ブランチを作成し、.gitignoreすべてのコードと設定ファイルを無視し、Drupalインストールの一部であるファイルのみに注意を払うようにしましたtに触れる。手動でアップグレード(ダウンロード、解凍、解凍、コピー)を行い、robots.txtや.htaccessのような境界線のケースをソートし、Drupalの.gitignoreを自分で上書きしました。500エラーから回復するために、7.14では機能したが7.15では機能しなかった設定をいくつか修正したところ、すべてが完璧に見えました。ブランチの名前を変更drupal-7.15し、途中で幸せに行こうとしていました。 誤って行ったことに気付くまで:以前はマスターブランチで追跡されていなかったが作業ディレクトリに残っていたファイルは、追跡されていないファイルではなくなったため、マスターをチェックアウトすると作業ディレクトリから削除されました! ど! drupal-7.15ブランチをマスターにマージすると、コードの分離が失われます。 おそらくブランチをサブモジュールに変換する方法がいくつかあります。それが可能だと仮定すると、それが最良の戦略かもしれません。これを行う前に、サブモジュールが「正しい」ソリューションであることを知っていましたが、以前に追跡されていないファイルにブランチを使用することの副作用に気づかなかったため、角を切ってそのルートに進むことにしました。(また、Drupalでサブモジュールを使用する際に見たすべてのアプローチは、新しいプロジェクトを開始し、Drupalがマスターブランチになることを前提としています。他の人のコードをマスターブランチにすることは望ましくありません。マスターブランチを備えたレポ。これは、アップグレードを行うだけでは不必要に複雑になるように見えました。) 私が考えていない他の解決策があるかもしれません。 可能な限り少ない欠点でこれから回復するにはどうすればよいですか? 更新:これは開発中(私のラップトップ上のLinux VM)であり、まだ実稼働には至っていません。本番環境に移行する頃には、すべてを機能モジュールでラップする予定ですが、それはまだ整っていません。 更新2:サブモジュールが機能しない場合があります。Pro Gitによると、「サブモジュールを使用すると、Gitリポジトリを別のGitリポジトリのサブディレクトリとして保持できます」。Drupalはこのような素晴らしい分離を提供しません。すべてのDrupalコードがサブディレクトリにあるのではなく、関係は多かれ少なかれ逆になっていますが、.htaccessとrobots.txtを編集している可能性があるため、コードとDrupalリポジトリが混在しているため、明確な分離はまだありません。この問題の回避策を探しています。

2
変換されたモジュールを貢献するには?
私は最近、クライアントプロジェクトの1つで、Drupal 6の貢献モジュールをDrupal 7に変換しました。この変換されたモジュールをコミュニティに貢献したいと思います。これを既存のプロジェクトページにアップロードする方法は?パッチを作成する必要がありますか、それともサンドボックスプロジェクトになりますか?

2
コード駆動型開発ワークフローで機能とインストールプロファイルのバランスをとるにはどうすればよいですか?
Drupalインストールプロファイル(Drupal 7)は非常に強力であり、モジュールでできることはほぼすべて実行できます。インストールプロファイルと機能を使用してサイトを開発し、すべてをコードに保持して、データベースをバージョン管理する必要がないようにします。 インストールプロファイルの力を考えると、機能モジュールでできることの多くは、インストールプロファイルでも実行できます。たとえば、コンテンツタイプの作成、権限の設定など。Drupalでコード駆動型開発ワークフローを使用する場合、何かがインストールプロファイルまたは機能モジュールに属するかどうかを判断するにはどうすればよいですか。

4
GitHubでDrupalプロジェクトを維持する方法
drupal.orgでいくつかのモジュールを管理しています。「だまされやすい方法」(CVSを覚えていますか?) これは望ましくない政治的な理由があるかもしれませんが、技術的な理由はありますか?一方向の同期は、githubリポジトリから対応するdrupal.orgリポジトリへの早送りを行うcronジョブと同じくらい簡単なものになると思います。 それで全部ですか?これを容易にする既存のツールはありますか?

1
drushでgit cloneを実行してモジュールのHEADバージョンをダウンロードするにはどうすればよいですか?
drupal.org gitリポジトリのモジュールのHEADバージョンを複製またはプルする方法はありますか? たとえば、私がDrupal 7を使用していて、Viewの最後のブランチが3の場合、次のようにします。 drush git-clone views 同等のものを達成するために: cd sites/all/modules/ git clone --recursive --branch 7.x-3.x http://git.drupal.org/project/views.git 理想的には、を使用しdrush git-clone views-3xて3.xブランチを明示的に複製する必要があります。 これは可能ですか、それとも夢ですか?これは開発に非常に役立ちます。

2
サイトコードをgitに保ち、コアとコントリビュートを同じリポジトリにプルするための最良の方法は何ですか?
drupalがCVSにあったとき、私は自分のサイトをgitリポジトリに置き、CVSを介してコアとコントリビュートを取得しました。2つのシステムはうまく共存し、すべての変更を追跡して、モジュールを貢献するためのパッチを作成することができました。現在gitでは、contribとcoreをダウンロードして自分のサイトのgitリポジトリにチェックインするか、サブモジュールを使用するか不明です。 これに関するベストプラクティスはまだあるのでしょうか。私のリポジトリがdrupalsルートディレクトリを独自のルートとして使用している場合、コアをサブモジュールとして使用する方法に特に困惑しています。

3
Drush Makeは.gitフォルダを削除します
drush makeとgithubでばかげた感じの後、すべての.gitフォルダー(履歴を記録するためにgitが使用され、構成、元の場所など)がdrush makeによって削除されたことがわかりました。私はメイクファイルを維持していなかったので、自分自身。 具体的には、drush makeは.gitフォルダーを削除し、-debugオプションで実行すると、それを確認できます Executing: rm -rf '/tmp/drush_make_tmp_1305733094/__git__/__build__/.git' 私のメイクファイルでは、それらの開発を追跡したいのでgit repoから4つのものをフェッチしています。そのうちの2つはカスタムコンポーネント(1つのカスタムモジュールとすべての構成を記録する1つの機能)であり、他のdrupalコアとメディアモジュールによるものです彼らが受け取る大量の修正に。それぞれの.gitフォルダーがないと全体の目的は達成できないようですが、他の人がgitでdrush makeを使用しているのに、私のクイック検索で見つからなかった方法もあると確信しています。 御時間ありがとうございます!

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.