3

私たちは Octopus Deploy の評価を完了し、1 つのプロジェクトでの経験に非常に満足しています。現在、Octopus Deploy の使用を複数のプロジェクトに拡張しています。このステップにより、Octopus エクスペリエンスに新しい次元がもたらされます。したがって、次のアサーションを検証する必要があります。

  1. 各環境 (DEV、STAGE、PROD など) のインスタンスを 1 つだけ持つことは素晴らしいことですが、単一の環境には同時リリースの制約があります。特定のプロジェクトのリリースは、同じロールを共有するすべてのマシンにデプロイされるため、実稼働環境は複数のマシンで構成されていますが、そのうちのいくつかは異なるリリース バージョンを実行する必要があります。その場合、Prod 環境だけを使用することはできません。PROD_OSLO や PROD_BERGEN などのいくつかのグループに分割して、新しいバージョンのみを実稼働環境でリリースできるようにする必要があります。オスロで。

  2. マシンの役割はすべてのプロジェクトで共有されるため、マシンが STAGE 環境で Web サーバーの役割を持っている場合、任意のプロジェクトの任意のリリースの Web アプリケーションがこのマシンにデプロイされます。これは、異なるプロジェクトがそれぞれの STAGE 環境に異なるマシンを使用する必要がある場合、異なる役割 (proj1-web-server と proj2-web-server) を作成するか、STAGE 環境を 2 つに分割する (STAGE_PROJ1 と STAGE_PROJ2) ことで実現できることを意味します。 . これらの代替案のいずれかに利点があるかどうか疑問に思います。

何かを見落としたり誤解したりして、上記の結論が間違っている場合は、詳しく説明してください。

4

1 に答える 1

3

Octopus を使用して私の会社で展開システムを実装しましたが、あなたの懸念のほとんどは私たちと共有されています。

最初の点に関しては、まさにそれを行います。CI、QA、Pre-Productionを定義し、Production Alpha、Production Beta、およびFull Productionの 3 つの別個の製品デプロイメントを作成しました。アルファ版とベータ版には、完全な製品の個別のサブセットが含まれています。

プロジェクトを異なる物理サーバーに分離することに関しては、複数の役割を実装しました。あなたが持っているように、「IIS」または「SQL Server」としてタグ付けするマシンから離れました。私たちの役割はより細かく、マシンが提供する特定の機能を説明しています。

たとえば、データベース サーバーの 1 つに "DB-Sales-Reports" というタグを付け、別のデータベース サーバーに "DB-Sales-Engine" というタグを付けることができます。機能的には、これはあなたが提案したものと同じですが、タグの意味に意味的な意味を課します。

理想的には、「M の役割のいずれか」の現在の動作ではなく、「展開ステップがターゲットとする M の役割のすべて」を満たすマシンを展開ステップがターゲットにできるようにするためのサポートです。展開ステップのターゲット」

于 2014-01-28T21:02:32.797 に答える