私は、コードの損失と本番展開の問題を最小限に抑えるために、Subversion プロセスと展開を再構築する計画段階にあります。私たちの現在のシステムは、ライブをプッシュする前にランダムなサーバーでサブドメイン名を作成してテストするだけで構成されています。
現在の計画について提案や意見を聞き、このシステムを改善する方法についてフィードバックやアイデアを得たいと思っていました。
詳細:
- 小さな開発チーム。
- 開発とステージングは同じマシン上に存在します。
- 製品バージョンは他のサーバーに存在します。
- およそ 30 のプロジェクトが Web 関連 (Web サイト、Web アプリケーション、Web サービス) です。
- 約 30 のプロジェクトは、デスクトップ アプリケーション、DLL、コンポーネント、bat ファイルなどです。
- VPN アクセス経由でのみアクセス可能な Dev サブドメイン名。
- Web のステージング サブドメインはパブリックにアクセスできます。exe ステージングは、VPN からのみアクセスできます。
- 各プロジェクトには、開発およびステージング サブドメインとリポジトリがあります。Dev バージョンは、ステージング トランクのブランチです。
- プライマリ dev リポジトリ: dev.domain.com (たとえば、一般的な名前を使用)。
- プライマリ ステージング リポジトリ: staging.domain.com (たとえば、一般的な名前を使用)。
展開:
プロジェクトの開発バージョンは、ステージング トランクのブランチです。ステージングは、特定のプロジェクトのリポジトリを保持します。その後、ファイルを手動で本番環境にコピーするか、デプロイ スクリプトを実行します。
例: 開発者は、projectname.projecttype.dev.domain.com (site1.web.dev.domain.com) から取得したローカル コピーを使用します。変更はローカル バージョンに加えられ、テストのためにプロジェクトの開発ブランチにマージされます。すべてのテストが完了すると、ブランチはプロジェクト トランクにマージされます。プロジェクト トランクがすべてのテストに合格すると、プロジェクトが公開されます。
Subversion リポジトリ構造: *注意: ファイル構造はドメイン名の構造と一致します。*
開発ブランチ: ローカル開発環境へのチェックアウトは常にこのサーバーで行われます。
dev.domain.com
web.dev.domain.com
site1.web.dev.domain.com
site2.web.dev.domain.com
exe.dev.domain.com
app1.exe.dev.domain.com
app2.exe.dev.domain.com
ステージング トランク: 開発者が触れたことはありません。ファイルは、ブランチを特定のプロジェクトのトランクにマージすることによってのみ更新されます。ライブにプッシュする前にインストールをテストします。本番環境には対応していますが、顧客はアクセスできないと想定する必要があります。
staging.domain.com
web.staging.domain.com
site1.web.staging.domain.com
site2.web.staging.domain.com
exe.staging.domain.com
app1.exe.staging.domain.com
app2.exe.staging.domain.com
これはどのように見えますか？不足している、または失う予定の機能はありますか? 彼らは私が使用すべきより良いシステムですか？