酒と開発の日々

飲酒大好き駆け出しエンジニアのブログ

自社のVCSをSVNからGitHubへの入れ替えを提案した話

みなさん、おはこんばんにちは。ぐーどらです。

既にTwitterで呟いたのでご存知の方も多いと思いますが、GitHub使用許可が社長から出ました。OK出たときは入社後イチでテンション上がりました。

今回はどうやって経営層を説得したのか、そして導入後のタスクの整理を書いていきたいと思います。

ぐーどらのつらたみシリーズはこちら↓

説得するにあたり

デプロイ時に大変時間がかかっている問題があり、その要素は主に3点ありました。

  • ソースコードの全差分確認をデプロイ直前に行う
  • SCPソフトによる手動アップロード
  • データベーススキーマ変更も手作業

どう考えても辛い(2回目)

上記のような状態だったので、GitHubを入れるだけで大分デプロイ前に作業が集中することが無くなるのでは?という予想が立っていました。

  • プルリクエストの通知をSlackに出すことにより、差分確認を通常業務中に分散可能
  • ソースコードの反映はアップロードではなく、git pullのみのため、人為作業の取り間違えポイントはブランチの選択程度になる
  • ブランチのマージ履歴を追えば、管理している機能が本番環境とステージング環境のどちらに反映されているいないが視覚的にわかる
  • CIツールが使え、テストコード自動実行と自動デプロイが出来るため開発スピードが上がる

データベーススキーマの課題は残りますが、導入するだけでも上記のようなメリットがあり、正直これだけでも説得出来るのでは?と思っていました。

現実は甘くなかった

GitHubを提案したところ、下記のような課題もあがってきました。

  • Gitを自社で運用して来なかったため、ブランチの運用方法がわからない
  • ブランチ毎へのマージやコミットの権限設定は出来るのか

提案当初に用意していたブランチ運用モデルはGit flowだったのですが「機能毎の部分的なリリースが難しい」という問題が浮上し、Git-flowは諦めることに。

そこで次に提案したのがGit feature flowです。

ブランチモデルはgit feature flow、gitクライアントにSourceTreeを使うことでどの機能がどのブランチにマージされているのか、漏れていないのかが視覚的に確認できるようになります。

運用モデルとSourceTreeを引っさげて社内でミーティングを組みました。布陣はCTOを説得する布陣。

  • CTO(GitHub否定派)
  • 自分(多分社内でGitHub一番入れたい人)
  • PM(頭が良く、チケットの切り方が抜群な人。以前からGitHubにしたかった)
  • SIerさん(ぐーどらより1ヶ月後に入社。CTOの手動デプロイを手伝っている被害者)

禄に使えもしないPowerPointで図説しながら、git feature flowなら現状より相当便利&管理ができるようになる旨を訴えました。

結果ミーティングが終わり、CTOから社長へ打診いただいたようです。

「社長がコードをホスティングするのは駄目だと言っていたので、ローカルのGitになります」

(´・ω・`)

(´;ω;`)ブワッ

「なのでGitHub Enterpriseになりそうです。高いけど」

……

…………………

( Д ) ゚ ゚

というわけで前向きに検討いただけるようになりました。良かった。(まあ今日仕事に行ったら、移行作業のイの字も出てこなかったので不安は残りますが…)

次の課題点

環境の更新作業で人の手が残っている部分として、次に着手すべきはデータベース更新かと思っています。本番環境に手作業でupdateなんて誰も叩きたくないですもん…

ということで、先週金曜日に参加してきたYYPHPで欲張って聞いてきたマイグレーションツールの導入を目指します。(今日ジャブを打ったらとことん打ち返されました…泣きたい)

あとは前々から考えていたCIツールですね。GitHubEnterpriseなので、ローカルにインストールしないとだめと言われそうなので、GitLab CIでほぼ確定な気がしています。

というわけで自分が見やすいように自分のタスクを纏めます。

  • 引き続きcodeceptionのテストコードを書く
  • 新しくアサインされたRPAプロジェクトの技術取得
  • GitHubもしくはGitLabへの移行誘導(運用が面倒くさいという部分は強調する)
  • 移行後CIツールを入れ、テスト自動実行化&Slack通知出来るようにする
  • マイグレーションツール導入のための布石を打つ(不可ならmigrationテーブル作成案を提案)

それにしても手作業が多すぎる。今日もデプロイ作業が手作業故に、本番環境で権限関係のエラーが顧客から連絡入ってしまったんだけどなあ…IaC化して構築も人の手をなるべく介さないようにしていけたらと切に思います。少しずつ体制を変えていけたら転職のネタにもできるようになると思うので、引き続き頑張りたいですね。

本日のオチ

SIerさんは前職でCOBOLを書いていたそうなのですが、その人からデプロイに関して一言。

「デプロイは前職より酷い」