私は継続的インテグレーションシステムをセットアップしましたが、それは約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システムを使用して行われるのですか、それとも手動で行われるのですか?
リリース時に分岐します。パッチを適用するということは、リリースに戻って更新することを意味するので、パッチをリリースする場合、それは避けられないと思います。また、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 ...
他にどのようなオプションが表示されるのか興味があります。
以下を使用します:(メインラインで開発)->フェーズ1テスト->フェーズ2テスト->(メインラインからのブランチ)->フェーズ3テスト-> RTM->ブランチのパッチ
各ビルドは事後にタグ付けされます。ゴールドビルドには、より伝統的なタグが付いています。開発は、フェーズ3のテスト中に、メインラインの次のリリースで作業を開始します。
タグから構築します。ビルドジョブはパラメーター化されているため(パラメーターはタグの名前です)、作成する必要があるのは1回だけです。