web-dev-qa-db-ja.com

ストーリー間の依存関係を減らし、QAでテストする必要があるブランチ（GIT）を減らしますか？

バックグラウンド

私たちは8人の開発者と1つのQA（テスター）のチームを抱えており、チケット間の依存関係に苦労しており、多くのマージの頭痛の種や次の作業が始まるのを待っている人々を引き起こしています。

現在のGITフローモデル（ブランチ）：

Release 
 |  > Epic (Feature Branch) 
 |     |  > Ticket : This is where the dev does their work and QA test on
 |     |     |       then we move to the epic branch once passed.

私たちの会社は、Web API（.Net、C＃）を使用してAPIを作成しています。また、MVCには主にjqueryを使用したAnuglarサイトと古い管理サイトがあります。

問題

最近の多くのプロジェクトでは、挿入、更新、削除、および取得用のAPIを作成する必要がありました。通常、「挿入」チケットを最初にコーディングし、他のチケットがそれに依存するようにします。これは、他のAPIが必要とする/使用するコントローラー、DBテーブル、クラスのコーディングなどのためです。

ただし、「更新」では、更新対象がDBに存在するかどうかを確認する必要があります。したがって、これは「get」に依存しているため、3層の分岐になります。

...
 |   > Insert
 |      |  > Update 
 |      |     |   >   Get.

より多くの叙事詩が関係している場合、これはさらに悪化する可能性があります。これにより、マージに関する多くの問題が発生したり、QAと開発者が必要とするブランチが混乱したりします。

人々はこれをどのように削減しますか？ペアプログラミング？空のスタブメソッドを作成しますか？

私たちが抱えている大きな問題は、人材の採用に苦労しているため、QAリソースが不足していることです。多くのチケットがQAパイルに積み重なるだけで、チケットブランチの競合が修正され続けます。

私は新しいgitフローを作成することを考えていました：

Release 
 |   > Epic (Feature Branch) 
 |      |    > Epic (Dev)
 |      |       |   > Ticket

したがって、この新しいEpic（Dev）ブランチを使用して、チケットがコード化されると、このブランチに直接マージし、次に、そのブランチのQAのテストを行い、合格したら、それをEpic（機能ブランチ）に移動します。

期待されるメリット：

  • QAはブランチを切り替え続ける必要はありません
  • 個々のチケットだけでなく、フルフローをテストできます。

これにより、私が望むように、競合を減らすことができますか？誰かがこれが私たちの現在の設定よりも優れていると思いますか？誰かより良い提案がありますか？

注：現時点では、qaテスト環境を使用できません（これ私のコントロールの外です）

c#agilegitdependenciesjira
1
user3209938

すばやく簡単にマージするためのルールは次のとおりです。できるだけ早く変更をマスターブランチに取り込みます。

役に立たないもの

  • 寿命の長い枝がたくさんある
  • 機能ブランチからブランチを分岐する
  • 変更をマージする前に、広範なQA作業が必要

役立つこと

  • 開発者が定期的に互いに話し合い、競合する変更を加えないようにする
  • 作業を最大で数日で完了する小さなアイテムに分解する
  • チームで共同作業をできるだけ少なくする
  • 既存の機能を壊さないようになったらすぐに小さな変更をマージする
  • 機能が切り替わり、不完全な機能が無効になります
  • 手動QAではなく、主に自動テストを通じてマスターブランチへのマージを保護する
  • 機能に関する作業の早い段階でQAを行う
  • 機能のトグルが削除されるか、デフォルトで「オン」に切り替えられる前に、手動QA作業に集中する

別のブランチから分岐することが問題になる理由

長期間有効な機能ブランチを最新の状態に保つには、通常、マスターをその機能ブランチにマージする必要があります。ほとんどの場合、これは機能をリベースすることによって行われます。ただし、サブ機能ブランチは基本機能と同期しなくなり、同様にマージする必要があります。これにより、特に機能のリベースによりサブ機能での単純なマージが不可能になるため、マージ作業が増幅される可能性があります。ただし、頻繁にマージしないと、機能とサブ機能がマスターにマージされるときに、最後にマージが困難になります。

継続的インテグレーションについて

上記の推奨事項の多くは継続的インテグレーションの一部です：早い段階でのマージ、自動的にテストする、マージを大したことにはしない。これは、悪いコードがマスターブランチに入る可能性があることを意味します。しかし、それはまた、不当な努力を必要とする前に、問題を早期に検出して修正できることも意味します。これは、単に互いに並んでいるだけでなく、一緒に作業するコラボレーションチームで最適に機能します。

CIは、一部のサーバーで独立して実行される自動テストスイートの恩恵を受けます。基本的な統合テストスイートでさえ、非常に価値があります。 QAがSeleniumを介して重要なテストを記録できる場合、それは比較的少ない労力で多くのテストカバレッジを提供します。テスト環境を設定するのは難しいかもしれません。一時的な対策として、開発者のマシンでCIを実行すると、開始が簡単になる場合があります（たとえば、別のサーバーをセットアップできるようになるまで、自分のPCでJenkinsインスタンスを実行していました）。

これがQAにとって意味すること

専任のQA担当者がいることは素晴らしいことです。ただし、マージのたびにサインオフする必要がある場合は、開発プロセスのボトルネックになりがちです。 （たとえば、かんばんボードを使用して、プロセス全体の作業項目のフローを追跡することを検討してください）。特に、他の開発者が使用する前に機能を完全にテストする必要がある場合は、マージの競合が増えるため、問題が発生する可能性があります。この機能は既に動作しているはずなので、これも無駄な作業になる可能性があります。

上で示唆したように、機能がデフォルトでアクティブ化される準備ができているときに、受け入れテストを実行する方が理にかなっている場合があります（コードが以前にマージされている場合でも）。特に要件を分析する場合は、QAをより早く行うことも理にかなっています。また、開発者が正式なQAサイクルを経ることなく、アドホックなアドバイスをQAに求めることができる場合、特に開発者がUXの問題について質問がある場合にも役立ちます。

展望：これからたくさんの役立つもの

プロセス（分岐モデル）の問題を特定し、それを改善しようとしています。すばらしい！継続的改善またはカイゼンは、多くの成功した開発モデルまたはプロセスフレームワークの中核部分です。途中であなたを助けることができるそこにたくさんの役に立つ資料があります。特に、アジャイルっぽい空間は、いくつかの非常に有用なこと（継続的インテグレーションなど）を探求してきました。中期的に役立つかもしれない2つの考え：

  • かんばんは、プロセス全体の作業項目の流れを視覚化し、すべてを遅くするボトルネックを検出するのに非常に優れています。かんばんはおそらくプロセスとして最適な選択ではありませんが、それについて詳しく読むことは非常に役立ちます（特に、プロセスの各段階でWIPアイテムを制限するためのアドバイス）。

  • BDDには、要件、作業項目、およびテスト間の関係に関する興味深い洞察が含まれています。特に、BDDは、テストの作成を開始する方法の質問に答えます。要件を例として表現し、テストに例を実行させ、一度に1つのシナリオ例を実装します。次に、テストによりCIを実行できます。これにより、QAは、プロセスの障害を取り除くすべての変更を承認するよりも、より価値のあるアクティビティに集中できます。 BDDに直接ジャンプするのは多すぎるかもしれませんが、例として要件を表現し始めると、簡単にマージできる小さめの作業項目を作成するのに役立つ場合があります。

1
amon

最初にアモンが言ったことを取り上げてください。

次に、「挿入」ブランチに問題がないと思われる場合、明らかにマージする前にテストしたいが、待たずに作業を続行したい場合：

あなたはcan必要な「挿入」ブランチから「更新」ブランチを更新します。 「挿入」がその親ブランチにマージされるとすぐに、親ブランチを「更新」ブランチにマージします。これは、親ブランチから直接分岐した場合と同じです。自分がしていることを注意深くメモし、行き過ぎないようにしてください。

「挿入」が親にマージする前に変更が必要な場合、親を「更新」にマージするときにこれらの変更を取得します。

0
gnasher729