タグ付けされた質問 「release-management」

私の会社（3年前のWeb業界の新興企業）では、製品チームに「これは危機的なパッチになりました！」と頻繁に問題があります。（皆ではありませんか？） これは、自己完結したエンジニアリングスタッフの生産性（および士気）に影響を与えます。経営陣は、これらの同日リクエストの頻度を減らす方法について考えることに時間を費やし、毎週リリースするソリューションを考え出しました。（以前は2週間に1回行っていましたが、通常は数日ほどずれていました。） 13人の開発者と6人のローカル/ 9人のオフショアテスターがいます。理論的には、他の開発者のいずれかから特定の専門知識を実際に必要とする作業が発生しない限り、4人の開発者（およびすべてのテスター）だけが偶数番号のリリースで作業します。各サイクルには、2日間の開発作業と2日間のQA作業が含まれます（さらに1日間のスコーピング/トリアージ/ ...）。 私の質問は： （a）このリリース期間の長さを経験した人はいますか？ （b）このようなリリースサイクルが試みられていることを誰かが聞いたことがありますか？ （c）（a）または（b）の場合、地球上でどのように機能させますか？（避けるべき落とし穴なども歓迎します。） （d）この取り組みが失敗した場合、どのように損害を最小限に抑えることができますか？

12 agile  quality  release-management 

私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？

12 agile  version-control  development-process  branching  release-management 

新しいプロジェクトの新しい開発チームから始め、ソースリポジトリ（Microsoft Team Foundation Server 2010など）の分岐戦略を定義する必要があります。私たちは...するべきかどうかという難しい議論にぶつかりました... A。実稼働ビルドを行うリリースブランチが1つあり、実際に何かがリリースされたときにラベルを付ける または B。本番環境への新しいリリースごとに新しいリリースブランチを作成します（例：バージョン1、2、3など...） オプションAは非常に簡単に思えますが、これが長期的に問題を引き起こすかどうかはわかりません。オプションBは、時間の経過とともに積み重なる1回限りの長寿命ブランチを作成するだけのようです。 私たちが決めるのを助けることができる経験はありますか？具体的には、いずれか1つの選択肢のどこに問題があるのか​​を聞きたいと思っています。TFSおよび/またはリリース管理の意味に関連する特定の経験を提供してください。

11 version-control  team-foundation-server  release-management  branching 

私たちは、相互に依存し合う多くのアプリとWebサービス（一部のパブリック向け製品、一部の内部およびプライベート「バックエンド」の一部）を持っています。これらの各コンポーネントには、4つの環境（特定の目的に役立つサーバー/ノードのクラスター）があります。 非生産 DEV-CIがプッシュ変更を構築する統合開発環境。エンジニアがローカルで再現できないバグを見つけるのに役立ちます QA -分離されたQA /テスト環境 DEMO -ビジネス関係者のための安定したUAT環境 製造 LIVE -私たちのライブ/制作環境 コードの昇格は次のようになります：（LOCAL開発者のマシン）=> DEV=> QA=> DEMO=> LIVE。 と呼ばれるmyappRESTful Webサービスによってサポートされるアプリケーションがありmyws、それ自体がと呼ばれるDBによってサポートされているとしmydbます。 現在、これらの依存関係の中で私が「オーケストレーション」プロモーションと呼ぶものmyapp-devがmyws-devありますmydb-dev。が使用するポイント。同様に、myapp-qaがmyws-qaを使用することを指すmydb-qa。同じのためにDEMOとLIVE。 これの問題は、たとえばにmyapp変更を加えるたびにmyws、mydbにも変更を加える必要があることです。しかし、各DEV環境は依存関係の環境を指しているため、DEVこれらの変更をすべて同時にスケジュールしてロールアウトする必要があります。さらに、1つのビルドが不安定になったり壊れたりすると、他の上流コンポーネントがダウンすることがよくあります。たとえば、開発者がを変更するときに何かを壊した場合、通常mydb-dev、myws-devおよびmyapp-devクラスターも不安定になります。 これを解決するために、私は「サイロ化された」プロモーション戦略と呼ぶものの提案をまとめます。すべてのコンポーネント間の依存関係はこのガイドラインに従います。 上流の依存DEMO関係は、すべての非実稼働環境（DEV、QAおよびDEMO）の下流の依存関係の環境に依存します。そして 上流の依存LIVE関係は、本番環境の下流の依存関係の環境に依存します この規則を使用myapp-devするとmyws-demo、実際にはをポイントし、を使用しますmydb-demo。同様に、およびmyapp-qaも指します。myws-demomydb-demo 私は見つけることができることをここに利点があるビルドの安定化：それははるかに少ない可能性が高いということであるDEMOコードはにそれを作ることができないので、特定のコンポーネントのための環境が不安定になるDEMOの両方の厳格なテストなしDEVとQA。 この方法で見つけられる唯一の欠点DEMOは、特定のコンポーネントで問題が発生した場合、すべての上流の依存関係のすべての非本番環境が突然破壊されることです。しかし、DEVとで実行されたテストのために、これが非常にまれに発生するはずであることに反対しQAます。 これはしていまし解決して、この問題とその解決策が既に（私が画策/サイロ化呼び出しています何のほかに）それらに名前を持っている場合、私は驚かないだろう多くの開発者（ずっと賢く自分よりも経験）という問題です。だから私は尋ねます：サイロ化されたプロモーション戦略のメリットはどんな短所よりも重要ですか、そして私がここで見落としているかもしれない短所は何ですか？

10 continuous-integration  release-management  dependency-management  environment 

現在、バージョン管理システムを悪用して使用しています...大規模なリリースバイナリ（4 GB以上）を格納するFTPとほぼ同じです。 私たちは、統合とリリースのプロセスを損なう一方で、ますます多くのITリソースを進化させ、引き継いでいるこの恐ろしい慣行から離れることを目指しています。 これに対する解決策は、P2Pファイル共有を使用してこれらのリリースイメージ/バイナリを配布し、ファイルサーバーといくつかの主要なユーザーマシンをシードとして混合することです。 だから私の質問は2つの部分に分かれます： リリースイメージ/バイナリを配布するためにイントラネットでBitTorrentを設定する手段をとった人はいますか？そうでない場合、このアイデアについてどう思いますか（実際にはBTWを採掘したわけではありませんが、すばらしいと思います）。 BitTorrentトラッカーのパブリッシングを処理するためのオープンソースのWebベースのソフトウェアはありますか？それで、新しいリリースがある場合、それを検索してシードとヒルに関してその可用性を表示できますか？（...あなたは私が何を言っているのか知っています） 編集：イントラネットはグローバルです（例：米国、中国、ドイツ、メキシコ）。通常のFTPでも機能しますが、費用対効果はそれほど高くありません。

10 release-management  software-distribution  p2p 

スプリント中にリリースする頻度。スプリントの最後、または機能の準備ができるたびに。そして、バグ修正リリースをどのように処理しますか？

10 scrum  release-management 

私のチームはGit Stable Mainlineブランチモデルを使用しており、最初のリリースブランチを作成しようとしています。これまで読んだことから、リリースブランチはマスターブランチからサイロ化されており、完全にマスターにマージされることはないようです。代わりに、リリースブランチで修正が行われた場合、通常はマスターブランチにチェリーピックされます。現在のリリースを次のリリースの開発から完全に分離したまま、現在のリリースの準備と同時にマスターで次の機能セットを開発できるようにしたいので、これは私にとって意味があります。 これらのリリースブランチはどのくらいの期間保持する必要がありますか？それらを完全にマスターに戻す必要がある場合はありますか？

9 git  release-management 

AとBという2つのアプリケーションがあります。これらのアプリケーションの現在のバージョンは7.xです（7.1を実行している顧客もいれば、7.2を実行している顧客もいます）。両方のアプリケーションは、次のように同じ共通フレームワーク（これをCと呼びます）を使用します。 +---+ +---+ | A | | B | +---------+ | C | +---------+ 重要な新規顧客がいるため、AとBの機能を1つの大きなアプリケーションにしたいと考えています。AとBを1つのアプリケーションにマージすることは不可能なので、今はAの機能をBに統合しようとしています。これまでのところ良好ですが、いくつかの問題が発生し始めています。 まず、Bの基本機能のみを使用する顧客は、追加されたAのすべての新機能に関心がない（そして、追加のオーバーヘッドが発生する）。彼らは、新しいWindowsバージョンをサポートしてバージョンBをアップグレードしたいだけで、C（共通フレームワーク）に追加されたすべての優れた機能も望んでいるだけです。 次に、現在アプリケーションAを使用している顧客は、アプリケーションBに直接移動したくありませんが、A + Bの機能を組み合わせることで、長期的には役立ちます。アップグレードを簡単にするために、彼らはAを使い続けたいと思っています。 3番目に、Bで行っているすべての開発は、Bのモジュールのパフォーマンスを向上させるために共通層CEgに影響を与える可能性があるため、Cのモジュールをリファクタリングする必要がありますが、CはAでも使用されているため、もっと多くの仕事をする必要があります。さらに、Aは古い、あまり構造化されていないアプリケーションであり、Cのすべての変更はAをより不安定にする可能性があります。 問題はどのように進めるかです。私は現在、7.xリリースでBを分割することを考えています（必要に応じて、ここでいくつかのマイナーな開発とリリース7.3、7.4を今後数年で行うことができます）、および8.xリリース（すべての新機能が含まれます）。 。共通層の問題を解決するために、Cを古いC（7.x）と新しいC（8.x）に分割することもできます。これにより、次の結果が得られます。 +-------+ +-------+ +-------+ | A 7.x | | B 7.x | | B 8.x | +-----------------+ +-------+ | C 7.x | | C 8.x | +-----------------+ +-------+ アプリケーションAはもう進化せず、7.xバージョンの共通レイヤーCに固執します。 …

8 versioning  release-management 

CVCSではなくDVCSを使用するという選択は、実際にはリリースサイクルの短縮につながりますか？もしそうなら、何がソフトウェアリリースサイクルをより短くするのですか、そしてこれに対する議論は何ですか？ プルリクエストに関連していますか？パッチの簡単な提出がここで役割を果たしますか？ 人的要因に関連していますか？CVCSを使用するプロジェクトチームは、リリーススケジュールに対してより保守的に機能しますか？ 他の要因はありますか？

8 dvcs  release-management  cvcs