プラットフォーム・ワンのシステムの運用・保守担当のエンジニアです。
保守の仕事に関わると、 ユーザからのお問い合わせだったり、監視アラートによる検知から システムを調査することがあります。
ログとソースコードを見て、不具合を特定し改修する。 すぐできればカッコいいですが、
「本番環境に反映して別のエラーが発生して手戻りになる」
といったことが発生すると、非常にカッコ悪いです。
そういったことを防ぐにはどうすればよいか。 今回は、そこに重きをおいて、MacBookAirで開発環境を作成しました。
やりたいこと
構成は以下のとおりです。
2つ、ポイントがあります。
1) 手戻りをなくすために、本番環境と同じ場所で動作確認テストを完結させたい。
クライアントPCに本番環境と同じ環境を構築できる 仮想環境サーバーのツール( Vagrant + VirtualBoxの構成)をインストールし、 ここにソースファイルをデプロイします。
2) テスト環境に反映させる時間を短縮したい。
改修作業の一般的な流れは、
- ソースファイルの編集
- 編集完了のソースファイルのコミット
- コミットしたソースファイルをテスト環境へのデプロイ
となるかと思いますが、
自分の経験から、間違ったロジックのソースファイルをコミットしたり、 ソースファイルのテスト環境へのデプロイ漏れしたり、 といったことを発生させていたので、以下のように見直してみました。
- ソースファイルの編集
- Vagrantのrsync機能によるテスト環境へのデプロイ
- テスト環境での確認作業後、gitへのコミット
といったフローになるよう構築しました。 デプロイ作業の工数削減と間違いソースファイルのコミットを予防できるので、 手間が減らせたのかなと思っています。
実際に動かす。
最後に、上のフローを実践します。
プラットフォーム・ワンの運用するMarketOneで、 タイトル画面の背景色が青くなっていたという不具合報告を受けたとします。 （※実際に発生したら、騒ぎになりますので、画面ではmy.marketone.jpとドメインを変えてます）
ソースファイルを編集します。
ソースファイルを保存して5秒ほど待ちます。
D, [2015-05-22T10:45:58.677904 #7878] DEBUG -- : Adapter: considering TCP ... D, [2015-05-22T10:45:58.678084 #7878] DEBUG -- : Adapter: considering polling ... D, [2015-05-22T10:45:58.678194 #7878] DEBUG -- : Adapter: considering optimized backend... ==> default: Rsyncing folder: ローカルディレクトリ => 仮想環境ディレクトリ ==> default: - Exclude: [".vagrant/", "ログディレクトリ"]
コンソールに上のように表示されていれば、すでにテスト環境にも反映されたため、 ブラウザから動作確認でき、FIXの確認ができたのでコミット→本番環境デプロイ と作業します。
少しでも手戻りをなくすアイデアとして、ひとつの参考になれば幸いです。
