開発ツールってソフトウェア開発の現場以外に展開できないんだろうか（Git編）

IT

あぶすとらくと

  • Gitが伝わらなかったので、自分が使ってるツールについてきちんと説明できるか試したくなった。
  • 長くなったので今回はバージョン管理（Git）について。

Gitが伝わらなかった

  • 転職理由を、非エンジニア圏の人について説明する機会があった。
  • その中で、開発環境がレガシーなの嫌なんすよー、という説明をする時に、Gitとは何で、SVNだと何故嫌なの？と説明するのにえらく苦労した。
    • 今考えると、別に細かく説明するんじゃなく、「書類作るなら、毛筆より鉛筆が楽だし、鉛筆よりシャーペン/ボールペンが楽でしょ？」って言えばよかった。
  • 振り返ると、ソフトウェア開発の現場においては、「複数の人間が適切にコミュニケーションを取り、ひとつの創作物を作成する」為のサポートツールが沢山利用されている。
  • こういうツールのひとつひとつについて、自分はきちんと説明できるだろうか。
    • 特に、IT業界に詳しくない人に対して、説明できるだろうか。
  • レガシーなツールは嫌いだと思っているが、嫌いな理由を明瞭に説明できるだろうか。
  • そんなことを思いながら、ソフトウェアを開発する時にどういうツールを作るのか、を吐き出してみる。
    • N番煎じかもしれないし、当たり前すぎるかもしれないけど、重複を恐れてアウトプットしないのは単なる怠惰だろう。
      • 検索汚染等、実害が出るようなら消せばいい。

Gitをコード管理以外で使う

  • N番煎じついでだが、Gitについては小説の作品管理に使ってみてはという記事を見つけた。

www.10kgtr.net

  • オンプレ環境を確保できるならGitLabでもいいと思う。

色々なツール

バージョン管理

  • ソフトウェア開発だと複数人が同時にひとつの製品について作業をしている。
    • 複数人でひとつの本を、担当する章を分けて執筆しているような状態。
  • この時、以下のような課題が発生する。
    • 「いつ、誰が、どのような変更を加えたか？」を追跡したい。
      • 以下のような状況を解決する為、変更を追跡する機能が欲しい。
        • 後から成果物を確認した時に、その内容が理解できなかった場合、誰に聞けばいいのか。
        • 何らかの問題が発生した場合、いつまでは問題ないのか。
    • 「どうやって統合するか？」
      • 章ごとに完全に分業しているならそれでいいが、例えばノンブルを修正すると全ページに影響がおよぶ。
      • どうやってひとつの本として統合すればいいのか？
        • また、何と何を統合したのかは、追跡可能性の問題から把握したい。
    • 「過去のある時点で、どういう状態だったか？」を把握したい。
      • 本で言うなら、第N版。
        • 何らかの指摘があって、突然3日前の状態に戻さなきゃいけなくなったら、どうしたらいい？

  • 大雑把にまとめると以下の要素になる。

    • 変更の履歴管理
    • 変更の追跡
    • 複数の作業成果の統合
      • これらのうち、「変更の履歴管理」を行うものがバージョン管理ツールになる。
      • 変更の追跡、複数の作業成果の統合については、ほぼ必ずバージョン管理についてると思うが、定義上必須ではない。

  • バージョン管理ツールとして、最近の開発現場でよく使われているのがGit。 Git

  • すごく大雑把に言うと、以下のような流れで作業する。

    1. 作業対象のコピーを、作業する人が全員、自分の手元に持ってくる。
    2. 各人が作業する。何か変更を加えるたび、変更を加えた箇所、日時、人物、変更した理由をメモする。
    3. 作業が終わったら、変更を大本の本体に統合する。
      • 大抵の場合、統合する前に他の人に「こんな変更加えたけど本体に反映していい？」というレビューを挟んだり、自動的に校正ツールにかけたりする。
    4. 統合するときに、他の人と同じ箇所に修正していると、その箇所が競合（conflict）として現れるから、問題なくなるよう再修正する。
  • 大抵は「Git」の仕組みにGUIをくっつけた「GitHub」とか「GitLab」とかを使うんじゃないかなぁ。
    • うちの開発現場ではGitLabを使っている。
    • プラットフォームとして存在するGitHubを使ってもいいし、プライベートに使う為の環境としてGitLabを使ってもいい。

  • ソースコード（プログラミングの成果物）だけじゃなくて、仕様書とかマニュアル等もバージョン管理の対象にする場合がある。

  • 強み

    • 上述の各機能はもちろん持っている。
    • 本体に統合するときに「リクエスト」を発行し、権限を持ってる人がそれを承認する、という形で統合するので、レビューを挟みやすい。
      • 権限設定で、特定の人しか本体にマージできない等の設定も出来る。
    • 統合する前に静的解析（校正ツール）や、試験を自動的に実行させる為の仕組みを持っている。

  • 限界

    • 基本的に文字列情報の比較にしか使えない。
      • 差分を抽出する時は文字列を比較して出している模様なので、マルチメディアファイル等は、「違うファイルがある」というレベルでしか抽出できない。
        • 画面で見比べることはできるけど、画像の何処と何処が違う、とかはできない。
          • 出来るプラグイン作れないかな・・・もうあるかな・・・。
      • 同じ理屈で.docとか、.xlsのファイルも比較できない。
        • ファイルをメモ帳で開いてみて、人が理解できる形で開けるものしか差分は取り出せないと思えば大体合ってる。
    • 何処に環境構築するのか。
      • GitHubなら無料で使い始められるけど、プライベートリポジトリは作れない。
        • 著作権絡みそうな作品管理には向かないのかも？
      • GitLabも無料だけど環境を何処に組むのか。誰の手元にも余剰なPCがあるわけではない。
        • EC2とかクラウドに展開してもいいけど、クラウド利用料がどれぐらいになるかは使ってみて、かなぁ。

  • 複数の作業者が、テキストベースに置き換えられるひとつのものに対して作業するのであれば、使う余地があるんじゃなかろうか。

    • 後、他の人が成果物をアップロードした際に通知を飛ばすことも出来るので、進捗管理との組み合わせも容易かも。