web-dev-qa-db-ja.com

ソフトウェアのリリース/継続的インテグレーションの使用-ほとんどの企業は何を使用しているようですか？

私は継続的インテグレーションシステムをセットアップしましたが、それは約1年前から機能しています。ようやく同じものを使ってリリースしたいところまで来ました。 CIシステムの前は、使用されていたプロセスは次のとおりでした。

(Develop) -> Ready for release -> Create a branch -> (Build -> Fix bugs as QA finds them) Loop -> Final build -> Tag

(Develop) -> Ready for release -> (build -> fix bugs) Loop -> Tag



Our CI setup:
1 server for development (DEV)
1 server for qa/release (QA)

2つ目はCIに完全に統合されています。ソフトウェアをリリースする準備ができたときにブランチを作成しましたが、その後ブランチが変更されることはありません。つまり、CIジョブを変更しなくてもビルドを再現できます。将来の開発はHEADで行われ、メンテナンスリリースでさえ、完全に新しいブランチと完全に新しいジョブを取得します。これらはCIシステムに永久に残り、その後いくつかあります。

最初の方法は適応が難しいです。ブランチが変更された場合、タグを使用してビルドしない限り、ビルドを再現できません[CIサーバー上のジョブはQA/RELEASEにブランチを使用し、HEAD開発ビルドに]]。

ただし、タグを使用してビルドする場合は、タグからビルドする新しいCIジョブを作成するか（サーバーの変更ログを失う）、既存のジョブを変更する（元のジョブ構成を失う）必要があります。

私はこれが複雑に聞こえることを知っています、そして必要ならば、私は状況をよりよく説明するために書き直し/編集します。しかし、私の質問：

[もしあれば]継続的インテグレーションシステムを使用してソフトウェアをリリースするために、あなたの会社はどのようなプロセスを使用していますか。 CIシステムを使用して行われるのですか、それとも手動で行われるのですか？

version-controlbusiness-process
7
Sagar

リリース時に分岐します。パッチを適用するということは、リリースに戻って更新することを意味するので、パッチをリリースする場合、それは避けられないと思います。また、RTMプロセス中もコーディングを続ける傾向があります。つまり、出荷されたリリースは、建物を離れる前に古くなっています。一部のユーザーはバージョンをスキップするため、現在2つのアクティブなバージョンがあります。フィールドに加えて、現在取り組んでいる新しいバージョンがあります。したがって、1.0、1.1、2.0、2.1、2.2、まもなく3.0が使用されます（そして、それらすべてのサポートコールを受け取ります）。パッチ/バージョンマトリックスのテストは、 QAはかなり忙しいです。

私たちのプロセスは次のようなものです。

(develop) -> branch to QA -> RTM -> ship -> patch branch ...
          -> keep developing in trunk -> merge patches ...

他にどのようなオプションが表示されるのか興味があります。

2
Мסž

以下を使用します:(メインラインで開発）->フェーズ1テスト->フェーズ2テスト->（メインラインからのブランチ）->フェーズ3テスト-> RTM->ブランチのパッチ

各ビルドは事後にタグ付けされます。ゴールドビルドには、より伝統的なタグが付いています。開発は、フェーズ3のテスト中に、メインラインの次のリリースで作業を開始します。

1
Arcege

タグから構築します。ビルドジョブはパラメーター化されているため（パラメーターはタグの名前です）、作成する必要があるのは1回だけです。

1
Jeff Knecht