BETA

えーgit?なリアクションをされた時の説明メモ

投稿日:2019-11-17
最終更新:2019-11-17

SIの人月業界でSVNからgitを導入した時に、説明がうまく伝わらず苦労しました。
その際に考えたことなどをまた説明する時に考えるのも・・なのでメモ書きとして残します。

※GitHubベースで展開していますが、クラウドへのセキュリティ問題もあり、gitbucketをローカルに構築することで一旦対応しました。

ブランチ開発に懸念を感じるSVNユーザーに対する考察

SVNでtrunkだけの開発を実施している場合、次のような疑問が生じます。
私も最初は違和感を抱いておりました。

ブランチ開発のソースをmasterにマージした際、マージにより発生しうる不具合(品質)は大丈夫であるか?

ブランチを作成して、マージしたり、プルリクエストの作成などに手間がかかるのではないか?

ブランチで開発中に各ブランチ間で共有するリソースについて、変更があった場合に追随が送れるのではないか?

マージの品質について

次のような施策により解決していくと理解しました。

  • GitHubの自動マージ機能が優秀
  • unit test codeやE2E test
  • CI
  • pullReqレビュー

GitHubのmerge機能は優秀で、マージする前にソースの競合を検知できます。
また、GitHubのWebページ上での競合内容の表示が非常に見やすいです。

マージ後はテストが必要です。
マージした後の基礎的な品質については、unitテストやE2Eテストをコード化し、マージ後の
プログラムに対して、全て実施することで、品質を概ね検証可能です。
(テストコードの有用性についてはここでは深く語りません)

CIを構築することで、GitHubでマージが発生した際に、上記のテストを自動実行することが
できます。Jenkinsやcircle ciなどを利用するのが通常ですが、工数や状況によっては、簡易なshell起動実行などでも代用はできるでしょう。

GitHubでマージが発生した場合、マージ後のプログラムに対して、外部プログラムを起動(自動テスト)を実施しNGであれば、マージしないといった操作の実現が可能です。

pullRequestによるレビューは、変更点なども視覚的に見やすく、変更のあったファイルを全てブラウザ上で確認できるため、レビュー実施機能としても優秀です。
ブラウザ上でコードの指摘を記述して履歴を残したり、差し戻しや承認などといったワークフロー管理も可能です。


今までありがちな開発に対して以下の質問をしてみます。
(リグレッションテストとブランチ開発の概念が混同していますが、合わせて考慮すべきなためまとめています)

  • SVNのマージで競合箇所を視覚的にシームレスに確認できたでしょうか?
  • SVNで発生する競合のマージは個人任せにっていませんか?
  • 個人でマージした内容の履歴は残っていて、すぐに確認できる状態にありますか?
  • trunkのコミットログに作業中のものや大枠で見たい時に不要な内容が羅列されていませんか?
  • 作業中のプログラムをサーバーに保管したい場合、trunkだけで可能でしょうか?
  • プログラムに修正があった際、リグレッションテストを自動化してきましたか?
    もし打鍵で行っているならば、その工数はどれだけ積み重なるでしょうか?
  • プログラムやDBの修正に対する影響範囲は確実に事前に検出できていましたか?
  • 開発中、他社のコンパイルエラーや不具合によって、自分の開発を中断されることはありませんか?
    それの解消にかかる時間の累積と影響する人数による工数のロストを考えていますか?
  • プログラムソースのレビューをしっかりしていますか?
  • レビューをしないで、bug-fixや運用保守時に可読性の低いプログラムにより時間を奪われていませんか?
  • レビュー記録表のような、記載、確認、検索性などどれにおいても効率の悪い資料作成に時間を奪われていませんか?
  • レビュー対象の残件などを集計や管理することに工数を奪われすぎていませんか?
  • テスト仕様書のレビューはしても実行したデータや実行結果についてレビューしていないことはありませんか?
  • エビデンスのスクリーンショットは動かない断片なので、本当に実施したか確認が取れていないことのリスクを考えていますか?

ブランチ運用の手間について

ここに関しては、慣れの問題ですが、運用ルールの手順や有識者がいる環境下では
さほど手間にならないと考えます。オペレーションコストはそこまで高くありません。
gitの基礎教養は勉強する必要があるとは思います。

役割や責務がブランチ毎に明確化され、逆に頭を悩ませる工数が減るものと考えます。

便利で有用で、世の中のデファクトスタンダードになっているものを置いておき、いつまで古いやり方で
非効率な開発を続けるのかについて考えると、説明の必要性がないと思います。

共有リソースについて

共有リソースについては、SVNのtrunkだけで開発している場合でも、同様です。
事前に影響範囲があるものは用意しておき、各ブランチで取り込んだ上で開発を進める

trunkだけで開発した場合であっても、共通的なものをコミットした場合は、全体に連絡が
必要であり、それが連絡なしに強制的に更新した人がエラーになるような状態で開発をしていた
だけではないでしょうか?

ブランチでの開発の期間が長すぎる場合、最新の共有リソースを取得し忘れたまま進んでしまう
リスクはありますが、ブランチのサイクルはそこまで長くならないような粒度で運用することで
解決を測ります。

ブランチ開発の本来の目的について

何故ブランチ開発が必要であるかの目的を忘れないようにすることです。
新規開発中であっても、本番運用後であっても、様々な修正ケースが発生します。

例えば次の状態のものをtrunkだけで管理しようとした場合、いつどの環境へどの機能をリリースし
テストするのか?といった計画に苦労したことがあるのではないでしょうか?

新規開発中/結合テスト中/単体バグ/結合バグ/総合テスト中/本番/本番障害/機能追加...etc

gitのブランチフローに合わせて開発することで、このような事態を事前に想定した開発が可能です。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

学習記録・ログ用

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!