2

私は、一部のチームが既に機能分岐を使用して継続的デリバリーを達成しようとしているのに、機能切り替えを使用する理由を理解しようとしています。チームが継続的デリバリーを達成したいと考えており、機能の切り替えまたは機能の分岐の助けを借りてそれを行うことができるとしましょう。

機能の切り替えには、実装可能ないわゆる「リリース切り替え」があり、チームはより迅速にリリースできます。機能の準備ができておらず、マスター ブランチのみを使用している場合は、それを切り替えてコードをリリースできます。

機能分岐についてもほぼ同じ話です。ここでは、たとえば、開発中の 3 つの機能を使用でき、そのうちの 1 つは既に完了しています。次に、会社はチームが本番環境にデプロイすることを望んでいます。彼らはその機能だけを選び、それをマージしてリリースします。

一部のチームが開発時に両方のアプローチを使用しているのを見てきました。この分野での経験がある人は、それについて何か教えてもらえますか?

ご理解いただければ幸いです。

4

1 に答える 1

1

機能ブランチと機能トグルが共存する理由をいくつか見てきました。

  • フィーチャー ブランチを使用するのに何の努力も必要ないため (どのアプローチにも必要なプロセスの説明は別として)、チームはそれらから始める可能性が高くなります。最終的に、チームはフィーチャー トグルが良いアイデアであることに気付き、それを実装しますが、その頃にはすでにフィーチャー ブランチに慣れているため、両方のメカニズムを使い続けています。
  • それらを使用するための方法とプロセスを配置した後でも、フィーチャー トグルはブランチよりも使用するのに多くの労力がかかります。変更ごとにコードを記述する必要がありますが、これは必ずしも簡単なことではありません。そして、それらが目的を果たしたときにそれらを削除する必要があります。これは些細なことのように見えますが、一部の開発者が困惑していることは明らかです。
  • ブランチには、私が考えることができる本当に潜在的な利点が 1 つあります。それは、ブランチがマージされるまでは、チームの他のメンバーの邪魔にならないことです。自分の作品を他の人に見せる準備ができていないと思う場合は、それが必要になるかもしれません。
于 2016-05-08T17:49:20.060 に答える