GitHubに再入門した

再入門というか、過去何度か挑戦しては挫折してたので、懲りずにまた挑んでみた。ってのが正しい。年度初めのNHK ラジオ語学講座みたいなものと思ってもらえれば良い。

実は、RCS / VCS（それぞれ"Revision Control System" / "Version Control System"の略。要はファイルへの変更管理をやってくれる仕組み。以後はVCS と表記する）を使ったことが殆ど無い。IT屋さんを十年以上やっていてそれはどうなの？　という意見には黙って土下座するしかないのだけど、実際のところ使わなくても仕事が回ってしまったのだからしょうがない。信じられないかもしれないが、本当にVCS に触れる機会が無かったのである。もっとも、正確には二度ほどVCS を使ったことがある。古い方から順に言うと、WinCVSを、2003年頃に半年ほど、SVN（僕が使ったのはTortoiseSVNというWindows用のGUIソフトウェアだった）を、1年ほど使用した。共にあるSIer（本社＝首都圏、職場＝首都圏、親会社＝いる、下請け＝やる、元請け＝やる、客先常駐＝やる、販社＝やる、自社サービス＝やらない）に所属していた頃である。

推敲もせずに思いつくままに書き連ねていくと、WinCVSを使った理由は、「所属していたチームが、誤ったファイルをライブラリ管理チーム（昔はいたのだ、こういう「みんなから預かったファイルを本番/試験環境に配置する、今で言うデプロイを専門にする部隊が）に渡してしまう」という、まさにVCS の導入例に出てきそうな理由だった。この時、元請けに出した再発防止策に「VCS を使ってリリースするファイルを間違えないようにします」という一文があったのだ。

そんな状況の下、大人たちの思惑が交差した結果、2000年問題による好景気の残り香にまぎれて、夜間文学部から会社に入社した役立たず（＝僕）が、チーム内の変更管理担当を拝命することになったのである。

この時は各担当者の端末からWinCVSサーバーになる端末にアクセスさせる設定やらに悩んだ（多分ネットワークかリモートアクセスの問題だったと思う。どうやって解決したかも覚えていない）りしたが、まぁなんとかCVS が動く環境が整い、利用され、そのうち忘れ去られ、使われなくなっていった。当時のSIにおいて、運用フェーズのシステムで、VCS 使わなきゃならない程の頻度での変更は発生しなかったのである。ちなみに僕がいたのは「共通チーム」という、今で言うソフトウェア寄りのインフラチームで、ミドルウェアの提供するAPI を呼び出す関数を作成し、「この関数経由でしかこのミドルウェアの機能は呼んじゃダメ」と言いながら開発チームに関数を提供するチームだった。そりゃOS / ミドルウェアの更改でもなきゃ、ソースの変更なんてないわな。実際、バグフィックスか、設定ファイルの更新くらいしかなかったと記憶している。むしろOS / ミドルウェアの設定ファイルの更新のほうが多かったし、その場合は手順の中で「本番のファイル / 本番の設定値（動的に設定が変更されている可能性を考慮） / 更新ファイル」の比較が、ファイル更新前後に組み込まれていた。

同じような形で、SVN を使った経緯について書くと、これはシステム開発ルールとして、SVN の利用が強制され、かつ、Windows端末所持者にはTortoiseSVNの利用が推奨（ここは確か強制では無かったはず。ただ、TortoiseSVNに関しては導入手順書とかが整備されていた。多分元請けの推奨環境だったのだろう）されていたからだ。この時は運用フェーズではなく、システム更改フェーズ（しかも担当会社も変わる、プラットフォームも変わる）だったので、VCS が結構役に立った。当時所属したのはやっぱりインフラチームで、管理用のシェルスクリプトをガリガリ書いていた。コンフリクト（複数人が同じファイルに変更を加えて、ファイルをどう更新したらいいかVCS が判断できなくなること）もこの時初めて経験した。とは言え、インフラチームは開発チームに比べて圧倒的に人数が少ない（開発数百人に対して、インフラは4人。うち1人はリーダー＝折衝担当、もう1人は半も浮きのヘルプなので実質2人）ので、コンフリクトが発生しても、「○○くん、このファイル更新できないんだけど、なに変えた？」「あぁ、ここいじったよ」「了解」なんてやり取りで済んだ。ここまで書いて思ったけど、ここ変更内容の確認はVCS の機能で済ませとけよ。まぁ、つまり、当時便利だったのは「ファイルの変更履歴 / 内容を確認できる」ことだったのだろう。

その後、10年に10日足りないくらいの年数の間勤めたSIerを辞め、とある大手Web屋に転職したのだが、やっぱりVCS を使用することはなかった。svn などのコマンドを叩くことはあったのだが、それはデプロイ作業の一環として叩いているだけで、ただのオペレーター、変更内容を理解しての作業では無かった。

これまでSVNを利用してこなかった理由だが、これはやはり「チーム開発経験がない」「大規模開発経験がない」ということに尽きると思う。個人で小さなスクリプトをちまちま作るだけなら、「.日時」拡張子を使うだけで十分だし、それをUSB メモリに入れるなり、VPS やブログなどに書いておくだけで十分に用は足りる。っていうか、今でもそうじゃないかと思う。

じゃぁなんで今回またGitHubに手ぇ出そうと思ったの？　と言われると、そりゃぁもう「RubyとPythonが悪い」と答えるしかない。

ChefだのAnsibleだのCapistranoだの、果てはRHELの深いところまでPythonが浸潤して、多分もう取り除けないレベルにまで来ちゃってる。こいつらを追っかけないと、ソフトウェア寄りのインフラエンジニアは死ぬ。もう小型特殊免許と電験取って、サーバー（設置）エンジニアになるしかない。「冬場はラックに除湿剤入れて搬入しないと、結露してショートしてサーバーが死ぬんだぜ」とか言ってドヤるしかない。

しかしまぁ僕はコンソールの前に座るインフラエンジニアでいたい。じゃぁRubyやPython読めるようになって、インフラ側に降りてきた開発言語と、その中身を理解するしかない。これがGitHubに手を出そうと思った理由である。

なんか本題のGit と関係ない話だけで長くなっちゃったな。続きはまた今度。実際になにしたのかを書く予定。

（ついでに「昔話」ってカテゴリー作って付けた）