web-dev-qa-db-ja.com

小規模なチームで複数のアプリケーションを継続的に配信するためにコードとビルドを構築するにはどうすればよいですか？

背景：

ソフトウェア以外の企業の内部アプリケーションをサポートする（そして新しいアプリケーションを構築する）3〜5人の開発者。私はTFSを使用していますが、それは私の質問にはそれほど重要ではないと思います。

展開パイプラインを開発し、継続的な統合/展開手法を採用できるようにしたいと考えています。

ソースツリーは次のようになります。単一のTFSチームプロジェクトを使用します。

$/MAIN/src/
$/MAIN/src/ApplicationA/VSSOlution.sln
$/MAIN/src/ApplicationA/ApplicationAProject1.csproj
$/MAIN/src/ApplicationA/ApplicationAProject2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/ApplicationC
$/MAIN/src/SharedInfrastructureA
$/MAIN/src/SharedInfrastructureB

マイゴール（かなり典型的なプロモーションパイプライン）

  1. 特定のアプリケーションにコード変更が加えられたとき、そのアプリケーションをビルドして、その変更をDEVサーバーに自動デプロイできるようにしたいと考えています。

    • 共有インフラストラクチャコンポーネントへの依存関係を構築する必要がある場合もあります。
    • 多くの場合、データベーススクリプトや変更もいくつかあります

  2. 開発者のテストに合格した場合、エンドユーザーが新しい機能を確認するSTAGINGサーバーに、手動でトリガーされた自動ビルドのビルドを導入したいと考えています。

  3. エンドユーザーによって承認されたら、手動でトリガーした本番環境への自動デプロイを行います

質問：

マルチアプリケーション環境で継続的デプロイメント手法を最もよく採用するにはどうすればよいですか？私が見るアドバイスの多くは単一のアプリケーション固有のものですが、それはどのようにして複数のアプリケーションに最適に適用されますか？

  • 手順1では、アプリケーションごとに個別のチームビルドをセットアップするだけですか？

  • 最新のビルドを新しい環境にプロモートするステップ2と3を達成するための最良のアプローチは何ですか？

  • 私はこれがウェブアプリでうまく機能するのを見てきましたが、データベースの変更はどうですか

version-controlcontinuous-integrationteam-foundation-servercontinuous-deliverymsbuild
7
kingdango

Jenkins CIは、あなたが望むものを達成するのに役立つはずだと思います。

  • Jenkinsの事前/事後ビルドアクションプラグインを使用して、異なるアプリケーション間の依存関係を管理することもできます。
  • Build Pipeline plugin はパイプラインの管理に役立ちます。最新のプラグインでは「再試行」が可能で、必要に応じて以前のビルドにすばやく戻すことができます。
  • 私自身はTFSを使用していませんが、Jenkinsには TFSプラグイン があるようです。

データベースの移行については、DBのバージョン管理を行う必要があります。これにより、移行スクリプトを展開と共に展開できます。

Jenkins + Build Pipelineは長い間、私にとってはうまく機能しています。これらは主に中小規模の複雑なWebアプリケーションでした。小さなiOSとAndroidアプリでも試してみました。

2
leenasn

Teamcityやjenkinsなどの多くのCIシステムは、バージョン管理システムを監視し、チェックインが検出されたときにビルドを開始するように設定できます。 CIシステムによって開始されるイベントのシーケンスは、次のようになります。

  1. ビルドがエラーなしで完了すると、単体テストが実行されます。
  2. 単体テストが失敗せずに完了した場合、ビルドはステージングにデプロイされます
  3. ステージングサーバーの展開が成功すると、統合テストが実行されます（この段階で、ユーザーはステージングサーバーに接続し、システムが機能していることを確認できます）
  4. 統合テストがすべて成功した場合、ビルドは「適切なビルド」領域にコピーされます
  5. 人は自由に「良いビルド」を展開できます

データベースの変更に関しては、展開プロセス中にデータのバックアップをステージングサーバーに復元してから、データベースの移行プロセスを開始できます。統合テストでは、移行の問題をキャッチし、ステージングへの展開に問題があることを警告します。これにより、「適切なビルド」領域へのコピーが許可されなくなります。

2
Nathan Pilling

私が数年前に働いていた会社で、TFS 2008があり、ビルドラベルとWFワークフローを介してデプロイメントを処理しました。ビルドラベルが変更されると、トリガーがアプリケーションを環境にデプロイしましたデータベースの変更は、データベースプロジェクトにチェックインされた変更スクリプトを通じて処理されました。

これを最初から行う場合は、TFSを拡張するのではなく、TeamCityまたは別の専用CIソリューションを検討します。そうは言っても、TFSを使ったストーリーは、TFSを使って試すことができるほどに改善されたのかもしれません。

0
neontapir