8

私は、Joomla や Drupal などのシステムを使用して、多くの CMS ベースのプロジェクトに取り組んでいる開発チームの一員です。

私たちの開発プロセスでは、コードの変更はすべて Git 内で管理されています。スプリントの最後に、パッチを介してライブ サイトに適用できるDIFFを作成します。

問題は、ほとんどの場合、変更に含まれていることです。

  • データベース スキーマの変更
  • データベース データの変更
  • ソースコードの変更
  • バイナリ ファイルの変更 (イメージなど)

Git Diff は、ソース コードの変更を美しく処理します。バイナリ ファイルは、ファイルが変更されたという事実への参照を除いて、差分に含まれていません。

データベース スキーマの変更とデータベース データの変更はめちゃくちゃです。

これらすべての変更を 1 つのパッチで展開するために使用できる、統合されたパッチ システムのようなものが存在するかどうか、私はさまよっていました。

問題は、「これらすべての変更を 1 回で展開できるシステムはあるのか?」ということです。

理想的には、このシステムはパッチのような予行演習を実行できますが、4 つのデータ型すべてに対して実行できます。

編集：あなたが提供したフィードバックをありがとう、それはこの分野での私の研究の出発点でした.

これが私がこれまでに見つけたものです：

  1. プロジェクトへの変更はリリースではなく反復的に行われるため、Linux パッケージ システムを使用して PHP ベースのアプリケーションを展開することは困難です。

  2. dbconfig を使用して変更をプロジェクトにデプロイすることは可能ですが、問題は mysql db diff (スキーマとデータ) を生成することです

  3. PHPベースのアプリケーションの展開に本当に欠けているのは、サーバーにインストールされ、パッチを展開するためのインターフェースとなる展開マネージャーです。

このトピックについて Google Wave を開始し、その結果、多くの情報が得られました。誰かがこの波を読むことに興味を持っている場合は、私に知らせてください。私はあなたを追加します。

4

4 に答える 4

2

アプリケーションのインストールとアップグレードの処理には、debian パッケージング システムを使用します。(.deb パッケージ)

背景 : J2EE + Flex アプリケーションを作成しています。VPN 経由で出荷および管理されます。だから、あなたからそう遠くない。

バージョンの新規インストールと別のバージョンへのアップグレードは、人形 (システム管理タスクを自動化するためのシステム: 彼は私たちの .deb をインストールします) を介して行われます。

.deb には

  1. コンパイルされたソースコード
  2. データベースのスキーマ ( [db-config][1] で処理)
  3. バイナリのもの
  4. 必要な他のすべてのアプリケーション (mysql、tomcat ...) を介して apt をインストールする方法

= 新規インストール用のすべてのもの

バージョンから別のバージョンに移動するための情報も追加します

  1. データベースをアップグレードするためのスクリプト (各バージョン用)
  2. 新しいバイナリ
  3. マシンの起動時に起動する新しいもの (例: 数週間前に activeMQ サーバーを追加しました)

=> .deb が正しく作成されたら、1 回の操作でシームレスにインストールまたはアップグレードできます。（プロンプトなしで自動的に作成されます）。

リリースごとに 1 つの .deb があり、各 .deb にはバージョン番号と署名があります。私たちの .deb のいずれかを選択して、実際のバージョンから彼が保持しているバージョン番号への新規インストールまたはアップグレードを行うことができます。

.deb は継続的インテグレーション システムにあります。(新しいバージョンをリリースしようとしているかのように、1 時間ごとに .deb をビルドします)

利点は何ですか?

  • 自信を持って自動的にインストール/アップグレードします。
  • バージョンをロールバックする
  • run dry はネイティブでサポートされています

あなたの正確なケースでは

* Database Schema Changes
* Database Data Changes
* Source Code changes
* Binary file changes (like images)

データベース => 移行スクリプトを作成する必要があります。バージョンごとに 1 つ。(例: 1.2-update.sql 1.3-update.sql )

ソースコードとバイナリ => それらを追加します。魔女バージョンでは、コピー/使用する必要があります。

編集：ソースコードについてはわかりません。コンパイルされたコードでそれを行っています...

開始するためのいくつかのリンク:

https://wiki.ubuntu.com/PackagingGuide/Complete

http://www.debian.org/doc/manuals/maint-guide/index.fr.html#contents (フランス語)

[1]: http://pwet.fr/man/linux/formats/dbconfig dbconfig

[1]: http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html debian

于 2009-11-27T17:00:48.847 に答える
1

I don't think you'll find a fail-safe mechanism.

I recommend that, when possible, you take into account compatibility with the current published source when making schema/data changes.

This way you can make a v. simple tool that runs database scripts committed to a particular svn location (you don't want diff on database changes, as if you need further modifications you need different statements).

With the above done, you can have a simple command that runs the database changes, then the binary & source code changes.

For database there is also the option of schema&data comparisons tools, these could be used to compare environments & make sure there isn't anything unexpected missing in the change scripts - could also generate the change scripts, but as I said you really want to make sure it won't break current source.

于 2009-11-27T16:22:42.420 に答える
0

git commit オブジェクトをローカル ファイルに保存してから、それらを他のリポジトリ/ブランチにインポートする必要があります。

于 2009-12-01T11:12:51.767 に答える
0

簡単に移行を行うためのツールを作成できます。これは、Peoplesoft の Patch Upgrade Assistant に似たものです。

これは基本的に、「アップグレード テンプレート」を読み取り、タスクを実行するスタンドアロンの実行可能ファイルです。アップグレード テンプレートは、アップグレード タスクまたは「手順」を宣言的に記述します。手順は、コピー (クラスやその他のバイナリなどのプリコンパイル済みオブジェクトをバックアップまたは移動するため)、データベース (スキーマ要素を変更するため)、SQL スクリプト (現在のデータをロードまたは変換するため) のいずれかです。ステップには、可能な述語ロジックがいくつかあります。これであれば、これを実行し、そうでなければスキップして次へ進みます。

テンプレートは通常、XML ファイルです。また、手動アクションの手順を含む手動ステップも提供します。各ステップでは、回復可能かどうかも指定します。また、ステップが成功したかどうかも検証します。

非常に一般的なこの要件に対応するオープン ソース プロジェクトを作成できる可能性があります。

于 2009-11-27T17:39:29.483 に答える