問題タブ [continuous-delivery]

複数のVMに展開されているWCFサービスがいくつかあります。VMは内部のみのネットワークの一部であり、ドメインに参加していません。時々、バイナリを最新バージョンに更新する必要があります。そのために、.batスクリプトがあります。現在、各VMで手動で更新をトリガーし、TeamCityからのボタンクリックで配信を自動化したいと考えています。

PowerShell（TeamCityからのリモートジョブ）からスクリプトを実行しようとしましたが、セキュリティの問題を構成するのが少し面倒だったので、それを削除して手動更新に戻りました。後で、基本契約に新しいメソッドを追加することを考えていました。

WCFサービスは、別のプロセス（たとえば、cmd.exeを介して）でファイルを呼び出し、そのホストをシャットダウンします。batファイルは更新を実行し、WCFホストを再開します。

これは良いアプローチですか？WCFサービスを継続的に提供するためのより良いソリューションはありますか？

VCS での並行開発/分岐は、ビルド アーティファクト リポジトリのセットアップと QA へのリリースにどのように影響しますか?

私たちの会社では、並行開発作業のために VCS を分岐していますが、どの分岐がどの順序で出荷されるかについての警告はほとんどありません。

バージョン番号付けのために、ビルドがどのブランチから来たかを QA に示すためにブランチ識別子を配置したいと思います。トランクからのビルドには、ブランチ識別子のない「通常の」バージョン番号があります。

当初は、ブランチごとに 1 つのビルド アーティファクト リポジトリと、トランク用のメイン リポジトリを 1 つ持つことを考えていました。

しかし、バージョン番号付けにブランチが含まれている場合、製品のバージョン番号は間違っています (ブランチからビルドおよびリリースしている場合)。

これを回避する方法は、トランクからのみ解放することですか?

また、ブランチからのビルドではなく、トランクからの QA チーム ビルドの出荷をどの時点から開始する必要がありますか?

私の現在の考えは、経営陣を説得して、開発チームをリリース順序 (リリースから 1 週間後など) に割り当ててもらい、ブランチをトランクにマージすることです。その後、QA はブランチ ビルドではなくトランク ビルドの取得を開始し、ブランチがマージされた開発チームは、ブランチではなくトランクのバグを直接修正します。

* アップデート *

より具体的には、VCS には SVN を使用し、リポジトリには Artifactory を使用しています。依存関係の管理に Ivy を使用しています。

リポジトリ レイアウトに関する Artifactory のヘルプ ( Repository Layouts ) を参照してください。

これと Maven と Ivy のデフォルト レイアウトは、これがより一般的であることを示唆しています。

これは Ivy を使用するための典型的なリポジトリ レイアウトですか? これには、Ivy のブランチ機能を使用して、ビルド時に依存関係をレポ内の正しいブランチ フォルダーに解決する必要があると思いますか?

* 更新 2 *

これが私の現在の Artifactory 構造です。

1. ビルド時に Ivy を特定のリポジトリに向けるにはどうすればよいですか? リリースの場合、リリース リポジトリからバイナリをプルするだけで済みます。スナップショット ビルドの場合、バイナリがスナップショット リポジトリに表示される場合はバイナリをプルできます。バイナリが見つからない場合は、リリース リポジトリからプルできます。リポジトリをチェーンする方法は理解していますが、リポジトリを切り替える方法がわかりません。

IvySettings.xml ファイルには次のものがあります。

..しかし、デフォルトは必要ありません。Ivy resolve コマンドを呼び出すときに、解決するリゾルバーのチェーンを指定したいと思います。このようなもの：

これは、解決する必要があるリポジトリを切り替える間違った方法ですか?

パブリッシュ タスクには、同様の方法で完全に機能する「リゾルバー」属性があります。

また、私の特定の例では、複数の Artifactory スナップショット リポジトリに対応する複数の SVN ブランチがある場合があります。どのリポジトリに解決するかをパラメータ化できますか? または、すべてのブランチのスナップショットを 1 つのレポに配置し、Ivy ブランチ機能を使用するより正しい方法はありますか?

他に役立つ情報が必要な場合はお知らせください。

さまざまなリポジトリ レイアウトを調べていますが、フォルダー統合リビジョンとファイル統合リビジョンの違いがわかりました。

これらは同じリビジョン番号 (ファイルやフォルダーに配置されているだけ) ですか、それとも別のものですか?

両方が言及されているリンクは次のとおりです。リポジトリレイアウト

継続的インテグレーションの概念が私のチームに統合されました。

Devという名前の統合ブランチがあるとします。

そこから、特定の現在のプロジェクトごとに 1 つずつ、3 つのブランチが派生します。

• プロジェクトA
• プロジェクトB
• プロジェクトC

まず、Teamcity は専用サーバーで構成され、その目標は次のとおりです。

Dev を含む各ブランチのバージョン管理されたソースから単体テストと統合テストをコンパイルして起動します

次に、もちろん、UAT を実行できるように、各プロジェクト ブランチ (A、B、および C) を複製された運用環境でテストする必要があります。

しかし、どの頻度で展開すればよいのでしょうか? ソースコードが変わるたびに？

それぞれをマージした後 (次の製品リリースの現実に対応)、または 3 つのプロジェクトを個別にマージした後、3 つのプロジェクトの混合を含む Dev のみを展開する必要がありますか?

Dev がデプロイされている場合、Dev で将来変更される可能性があることを考慮してはなりません。確かに、プロジェクト Dと呼ばれる新しいプロジェクトが開始される可能性がありますが、それは次のリリースの一部であってはなりません。そのため、Dev を統合 (UAT) に使用することは、デプロイヤーがプロジェクト D のコンテンツを非自発的に統合する可能性があり、環境が次のリリースの現実を明らかにしない可能性があるため、リスクがあります。

その他の解決策: Dev ではなく 3 つのプロジェクトを独立して使用しているため、3 つの複製された運用環境が並行して存在する必要がありますか?

はいの場合、統合環境の動作が頻繁に変更される可能性があるため、UAT は信頼できません...

UAT の継続的な展開の概念は、私には明確ではありません...

ビルドパイプラインの一部としてJenkinsビルドサーバーからリモートJBossAS7.1.1サーバーに自動的にデプロイする作業を行っており、antから呼び出す小さなjarファイルがあります（これに基づいています）。

私の質問は、アプリケーションがすでにインストールされているかどうかを確認するにはどうすればよいですか？アプリケーションがすでにデプロイされている場合、デプロイプランの実行は失敗します（スローされた例外をキャッチできますが、それは素晴らしいことではありません）。

私はjsfのアプリケーションを使用しており、Herokuへの継続的デリバリーを行っています。私はJSFとHerokuの両方に不慣れです。可能かどうかはわかりませんが、アプリケーションでマイナーな更新を実行し、Herokuにデプロイできるようにし、セッションスコープの管理Beanでセッションを存続させたいと考えています。web.xmlで状態保存をクライアントに設定しましたが、アプリケーションをHerokuにデプロイすると、管理Beanのすべての値が初期値にリセットされます。誰かがこれを修正する方法を知っていますか？ありがとうございました

UrbanCode uDeploy、Noliosoft ZeroTouch、および XebiaLabs Deployit に匹敵する継続的デプロイ ツールは何ですか? アプリをデプロイしようとしている環境は、マルチ OS (Linux、Windows Server)、さまざまな種類のミドルウェア (Websphere、Weblogic、Jboss、Tomcat、Apache、IIS、BizTalk)、さまざまなデータベース (Oracle、MySQL、MSSQL) です。さまざまな種類のアプリケーション パッケージ (.war、.jar、.conf、.xml、.zip、.exe、.msi) が含まれます。また、Maven リポジトリの代わりにファイルシステムからプルしています (ただし、将来的には Maven と統合する必要があります)。Maven-cargo デプロイメント プロセスを構築しましたが、デプロイメント エンジニアはメトリック収集機能を備えた GUI ベースのツールを望んでいます。Webistrano の展開を試みましたが、.NET、IIS、および .msi の展開を正しく機能させることができません (これらのプラットフォーム向けではないことはわかっています)。Red Hat JON を使用していますが、Windows への展開はできません。SCCM? グルー？オクトパスデプロイ? クワティ？

「Git vs SVN」というテーマについて多くの引用を見てきましたが、通常、答えは次のとおりです。

1. どこでもコミットできます
2. スペースを節約
3. 分岐高速

...

しかし、ここで、Continuous Delivery に適しているかどうかについて議論したいと思いますか? Git は私たちに頻繁に分岐することを奨励しているように思えますが、それはメインラインに頻繁にマージし、フィーチャーではなくリリース時に分岐することを提唱する継続的デリバリーの概念に反しています。

では、Continous Delivery、Git、または SVN のバージョン管理システムを選択するときに、少し戸惑いますか?

あなたの意見は何ですか？

継続的な展開では、サーバーを徐々にアップグレードすることがあります。たとえば、すべてが問題ないと確信するまで、20 のうち 2 つが新しいコードを使用します。新しいコードがデータベース スキーマの移行を必要とする場合、たとえばフィールド電話がテーブル電話になった場合はどうなるでしょうか。20台のサーバーすべてをアップグレードしない限り、何かが壊れるでしょう。

私が取り組んでいるシステムには、SQLServerのストアドプロシージャにほとんどすべてのロジックが含まれています。開発慣行を改善する一環として、機能フラグ（別名トグル）を使用して継続的デリバリーモデルに移行し、本番環境で機能を有効にします。

ストアドプロシージャを記述して、フラグを効率的にチェックし、プロシージャが呼び出されるたびに構成テーブルをハンマーで処理してデータベースに負荷をかけないようにするにはどうすればよいですか？