3

製品は継続的に開発中の CMS であり、新機能のパッチが常に展開されています。製品は複数のサーバーでホストされており、そのうちのいくつかは FTP 資格情報と db へのアクセス権しか持っておらず、他のサーバーには完全なルート アクセス権があります。現在、テスト後に新機能がリリースされるとすぐに、すべてのサーバーでファイルを手動で ftp し、SQL クエリを実行する必要があります。これは非常に時間がかかり、エラーが発生しやすく、非効率的です。より堅牢にする、誰にでも使えるようにする、または一部を自動化するにはどうすればよいですか? CMS は、PHP、MySQL、JS、HTML、および CSS に基づいています。管理部分はすべて共通です。スキンと一部のカスタム モジュールはさまざまなクライアント向けに開発されており、更新する部分は管理者だけです。

アップデート

コードを管理するために GIT を使用していますが、SQL はこの GIT 構造の一部ではありません。バージョン管理下に置くように製品マネージャー/所有者と話し合っています。

4

2 に答える 2

2

これは、パッケージ化されていないコードの大きな問題の 1 つです。

個人的には、実行時にコードを特定のフォルダーに抽出し、必要なクエリを実行する PHAR があります。

于 2012-08-06T17:44:28.663 に答える
1

私は、1 か月あたり数億の訪問者を処理する数十のサーバーにわたって Web 展開を実行してきました。

SQL 変更管理は常に野獣です。希望は、社内で独自に作成するか（私が行ったこと）、またはEMS DB Comparerのようなものを使用することだけです。

ファイルの同期を処理するには、連携するように巧妙に作成された次のような多くのツールが必要になります。

  1. 適切に分岐されたソースコードのバージョン管理 (bzr、svn など) (stable ブランチ、dev ブランチ、testing ブランチが必要)、
  2. 継続的インテグレーション サーバー、
  3. すべてのサーバーでの SFTP サポート、
  4. うまくいけば、ビルドの品質を判断するための単体テストと統合テスト、
  5. すべてのサーバーで Rsync、
  6. スクリプトをビルドします (これらは Phing で行います)。
  7. デプロイ スクリプト (Phing も同様)、
  8. ノーハウ。

一般的なプロセスでは、徹底的な調査に約 20 時間、セットアップに約 40 時間かかります。ドキュメントを作成したとき、40 以上の異なる手順が含まれていました。SQL 変更管理ユーティリティの作成には、さらに 20 ～ 30 時間かかりました。さらに 10 時間のテストを追加すると、100 ～ 120 時間のプロジェクトが表示されますが、これにより、将来の展開の失敗を大幅に節約できるだけでなく、展開時間をボタンをクリックするのにかかる時間まで短縮できます。

そのため、このプロセス全体のセットアップについて相談を行っています。通常、クライアントのネットワークにセットアップするのに約 5 時間かかります。

于 2012-08-06T17:51:02.733 に答える