自己紹介

どうも、常時混乱状態の水谷です。

毎日モンスターエナジー片手に奮闘しています。

主に、Android開発を担当していますが、そのほかGolangを勉強していたり、PHPがちょっとだけできるので、サーバーサイドの実装をしていたりします。

 

今日は、React NativeとかGoとか、いったい俺は何を覚えたらいいのかで、混乱しています。

 

この記事について

この記事は、いまだにFTPで本番反映していたり、本番反映が苦手な方や、CI導入をしようとしている方のための記事です。

これは、各々がそれぞれFTPでデプロイするというクレイジーな環境を、Githubのmergeボタン一発で、自動デプロイされるクールな環境に変えようと奮闘したお話です。

 

なぜやるか

開発者の環境を整えることで、モチベーションが下がる要因を少しでも減らすことが目的です。

開発者のモチベーションが下がることは、そのままサービスの質の低下にもつながっていきます。

いま現在、このあたりを整備していない会社は、あまりないと思っていますが、やっていなければ、必ずやるべきです。

これからやろうという方がいらっしゃった時に、参考になればと思います。

 

FTPデプロイの恐怖

それは、みずたにが サーバーを まかされて すうかげつたった あるひのことだった。
＊「おきなさい。おきなさい。わたしのかわいい みずたにや……。きょうは おまえが はじめてほんばんへ デプロイするひだったでしょう。さあ わたしについていらっしゃい。」

ということで、本番環境へのデプロイの日がやってきました。 この日までに、本番へ反映しないと行けないソースコードや、設定ファイルなどをチェックし、リストを作成しておきました。

そして、いざ本番反映……。

 

まおうFTPデプロイが あわわれた！
まおうFTPデプロイは メ○パニを となえた！
みずたには こんらんしてしまった！
まおうFTPデプロイは なかまをよんだ！
ハンエイシテナカッターAが あらわれた！
ハンエイシテナカッターBが あらわれた！
キャッシュノワーナが あらわれた！
グレイスフールが あらわれた！

 

………

 

　

こういうことってあるよね？

ある・・・よね・・・？（汗）

うん、あるんですよ。 人はみな未熟なんです。環境がダメだと、人はみんなダメになるんですよ！

こういうことにならないために、開発環境やデプロイ環境は、しっかり整備しないとダメなんです。

 

開発環境

まずは、現状の確認です。 現状、開発環境はこうなってます。

 

現在の環境

開発環境

　- 本番環境（ユーザーが実際に使用する環境）

　- テスト環境（開発時にテストするための環境）

　- ソースコード管理

　- BitbucketによるGit管理

 

反映方法

　- FTPによるアップロード

　- アップロード後、手動でキャッシュクリア

 

開発環境の見直し

FTPアップロードは、とても簡単ですし、本番へ反映するのも、超お手軽です。

もし、小規模な案件で、かつ一人で開発してるなら、これでもいいですかもしれません。

しかし、複数人で開発をしていると、これは高確率で破綻します。

 

破綻の理由

1. テスト環境がひとつしかないことで、

　・誰かがあげたコードのおかげで、自分のコードがうまく動いているかもしれない。

　・誰かがあげたコードのせいで、自分のコードがうまく動かないかもしれない。

2. 本番と同等のテスト環境がないことで、

　・本番で発生してしまうバグを発見できない。

3. FTPで手動アップロードしていることで、

　・なにか変なコードを間違ってあげてしまうかもしれない

　・反映すべきコードをあげ忘れてしまう

　・戻そうと思った時、正しく戻せないかもしれない

 

特に恐ろしいのは、１ですね。

移行漏れもなく、テストも完璧だったのに、本番にあげたら、バグってしまった！

という事態がどうしても避けられなくなってしまいます。

こうなると、体力と精神力はものすごく削られ、モチベが下がり続けます。

よし、早急に見直そう！

 

これらの解決策として、まず個別の開発環境と、ステージング環境を用意することにしました。

 

個別の開発環境について

個人の開発環境は、主に１を解決するために用意します。

自分しか触っていないはずの環境を用意することで、そのほかのファクターに左右されない状態を作り出します。

そのほか、個別の開発環境を用意することで、開発者個人の気持ちを楽にすることができます。

自分しか触ってないし、最悪、その環境が壊れても、他の開発者に迷惑がかからないですからね……。

 

ステージング環境について

これは、２を解決するために用意します。

見ているデータベースも、ソースコードも、これから反映させようとしているコード以外は、本番と同等の環境になります。

 

FTPアップロードは甘い罠

もうひとつの問題点は、FTPによるアップロードです。

これは、すごく簡単で気軽にできますが、反映するためのソースコードの管理や、なにか問題が発生した場合に、前の状態に戻すのが、非常に大変です。

本番反映するだけで、反映を行う人の精神力は0になり、その日はもう戦えなくなることもありえます。

これも思い切って解決していきましょう。

本番反映に過度に恐怖をおぼえる方は、おそらくここが原因なのではないかなと思います。

 

これについては、CIと自動デプロイツールを導入することで、解決したいと思います。

 

CIツール

継続的インテグレーション……なんか、かっこいいね。

テストとかコンパイルとかそういうものを、継続的に自動実行することで、早期に問題を発見するためのツール。

Jenkinsとか、TravisCI、CircleCIなどがあります。

今回は、CircleCIを採用します。

なぜなら、Circleって言葉が好きだから！

完全にそれだけの理由です。

CircleCIはGithubをフックして起動されるので、Bitbucketからは、さよならすることになりますね。

 

自動デプロイツール

Capistranoを採用します。

理由としては、正直興味本位です。とある勉強会で紹介されていて、便利そうだと感じたので導入してみることにしました。

良い環境作りを成し遂げるには、モチベーションも大事です。

とりあえず導入するまでの難易度の低さと、開発環境ごとに設定を分けて書けるという、わかりやすさが決め手でした。

 

まとめ

今日言いたかったことは、 開発者のモチベーションが下がりそうなことは、自動化しよう！ ということです。

最後に、今日書いたことのまとめとして、目標とする環境を書いておきます。

 

理想とする環境

開発環境

　- 各個人の開発環境（単体テスト用）

　- テスト環境（統合テスト用）

　- ステージング環境（本番環境とほぼ同じ環境）

　- 本番環境（ユーザーが実際に使用する環境）

 

ソースコード管理

　- BitbucketによるGit管理

　- GitHubによるGit管理

 

反映方法

　- FTPによるアップロード

　- アップロード後、手動でキャッシュクリア

　- CircleCI + Capistrano + GitHubでMerge一発デプロイ

 

今回の戦績

次回からは、各ツールの設定方法や、使い方について、順を追って紹介していこうと思います。

次回は、GitHubのワークフローについて書いていこうと思います。

 

それでは、また！