version-control - バージョン管理の実践

Question

私の現在の仕事では、スーパーバイザーの慣行は、本番用の準備が整ったコードのみをチェックインすることです。ごく最近、私が関わっていたプロジェクトには、3 人の異なる開発者による作業が含まれていましたが、ファイルが重複していました。これは、一部の変更には 1 日かかるという事実にもかかわらず、手動で変更を統合することを意味していました。これが一般的な慣行であるかどうかを確認し、多くの場合、私の意見は物事の壮大な計画ではほとんど意味がないことを知って、この慣行を変更する方法についての提案を得たいと思いました.

score 4 · Accepted Answer

ソース管理システムに応じて、さまざまな方法でこの状況を処理できます。

プライベートブランチ: 移動中にコードをチェックインして作業し、適切なタイミングで前後にマージできます。

シェルフセット/パッケージ化されたチェンジセット: チェンジセットを保存し、レビューのために送信できるようにします。

これが適切な方法であるかどうかについては、事前の審査なしにメインブランチにチェックインすることは許可されていません。レビューに合格するには、コードがさまざまな自動化ツールに合格し、ピアレビュアーに受け入れられる必要があります。「生産準備完了」のいくつかの定義については、これで終わりです。したがって、私たちはあなたがしていることと同じことをします。ただし、プライベートブランチを使用して、進行中もチェックインを実行できるようにし、他のチェックインが干渉する必要がないようにします。

本番対応が統合環境でテストされていることを意味する場合、ステージングブランチまたは同様のものが必要になる可能性があるように思えます。

score 2 · Accepted Answer

VSS から、より信頼性が高く機能豊富なものに切り替えることから始めます。ソース管理を切り替えるように会社を説得する方法を参照してください。

次に、既知の適切なプラクティスを適用します。

頻繁にチェックインする
マージを簡素化するために、他のユーザーの変更を頻繁に取得する
高速単体テストを使用して、各変更が最小基準を満たしていることを確認します
チェックインされたコードが常にビルドされ、常にテストに合格することを要求します。

この時点では「本番環境の準備が整っていません」: 展開する前にテストと修正を行うにはまだ数週間必要です。その時間を短縮することは、あなたにとっても顧客にとっても素晴らしいことなので、次のことに投資してください。

高品質の自動受け入れテスト。

score 2 · Accepted Answer

チェックインされたコードは単体テストを行う必要がありますが、私にとって「本番環境に対応」とは、統合とシステムテストが完了していることを意味します。コードがフリーズするまでそれを行うことはできないため、チェックインするたびにそれを行う方法がわかりません.

score 1 · Accepted Answer

変更が完了してテストされた後に、「本番準備ができていないコード」をチェックインできるレポのテストブランチを用意することは良い考えではないでしょうか?

メイントランクには、ビルドを壊して単体テストに合格しないコードをチェックインしてはいけませんが、ブランチにはこれらすべての制限を設ける必要はありません。

score 0 · Accepted Answer

私が特に気に入っているアプローチは、デポに異なるライフサイクルバージョンを用意することです。つまり、たとえば、開発者が作業中のコードをチェックインするコードの開発バージョンを用意します。次に、コードにベータ版の修正を追加できるベータ版を作成できます。そして製品版。

このアプローチには明らかなオーバーヘッドがあります。たとえば、ローカルマシンのワークスペースが大きくなったり、コードをある段階から次の段階に移動するための移行プロセスが必要になったりします (つまり、移行に伴う統合テストを行う際のコードのフリーズ)、およびプロジェクトの複雑さによっては、設定、環境変数、レジストリエントリなどを変更するツールが必要になる場合があります。
これらはすべて、設定は面倒ですが、1 回だけで済みます。すべての設定が完了したら、コードのさまざまな段階での作業が簡単になります。

score 0 · Accepted Answer

私は個人的にはこれを承認しません。なぜなら、経験の浅い開発者が問題のコードを見つけて (作業中のコードを確認することによって)、これが最善の方法である場合があり、「早期に頻繁にチェックイン」すると、以前に行った変更にロールバックできるからです。（開発中）以前に行ったいくつかの変更が実際にはより良いアイデアであると判断した場合。

score 0 · Accepted Answer

私たちが使用しているバージョン管理、VSS と組み合わせて、分岐を学習する時間がないのではないかと思います。毎晩チェックインして開発を支援し、「Going Dark」を回避するというアイデアが本当に気に入っています。彼がトランクに抵抗しているのを見ることができますが、おそらく開発用 SS を構築し、コードが本番用の準備ができたら、それを本番用 SS に移動します。

score 0 · Accepted Answer

私が見た慣行から、生産品質という用語は、人々が木のてっぺんを壊すことを恐れていることを確認するために「おびえさせるもの」として使用されています。正直に言って悪いことではありません。

ベストプラクティスは、ツリーの最上部にある別個の (つまり、別個の) 機能コンポーネントのみをマージすることです。同じソースファイルへのデルタにかなりの重複がある場合、これは、プロジェクト管理のどこかが崩壊したことを示している可能性があり、それらの開発者は変更を統合ブランチに移動する前に別の統合ブランチにマージする必要があったことを示していると思います。メインラインソース。個々の開発者が自分たちのものを単体テストしたと言っているのは無関係です。なぜなら、彼らがテストしたものが変わったからです!

メインラインのコードラインで統合の問題を解決しようとすると、必然的に他の無関係な提出物が停滞します。

score 0 · Accepted Answer

集中型のバージョン管理システム (Subversion など) で作業していると仮定し、「トランク」(最新の適切に機能するコードが存在する場所) の概念があると仮定します。

「機能ブランチ」/「実験的ブランチ」で新機能に取り組んでいる場合は、まだ完成していないコードをコミットしてもかまいません。(機能が完了したら、正常に動作する結果を「トランク」にコミットします。)

しかし、「トランク」または「リリースブランチ」にコンパイルされていない/明らかに機能しないコードをコミットしても、人気コンテストに勝つことはできません。

Pragmatic Programmersには、 Subversion を使用した Pragmatic Version Controlという本があり、ブランチに関するアドバイスのセクションが含まれています。

score 0 · Accepted Answer

早めにチェックインし、頻繁にチェックインする主な理由は 2 つあります。

1 - コードの統合が容易になる可能性がある

2 - コンピューターが爆発した場合に備えて、数週間の作業が無駄になることはありません

score 0 · Accepted Answer

@bpapa

ワークフォルダをサーバーに毎晩バックアップすることで、1 日以上の作業が失われるのを防ぐことができます。

@tonyo

コーディングを終えた翌日に要件ドキュメントが完成したことを見てみましょう。それは私たちのプロジェクト管理について教えてくれますか?

当店は小さなお店ですので、変えるのは簡単だと思われるかもしれませんが、昔ながらのやり方に固執している方もいます。

version-control - バージョン管理の実践

11 に答える 11

Related

Reference