開発

2015.12.22

デプロイクエスト第1回「考え直すべきは開発環境から」

自己紹介

122-e1437990692812.png (134.5 kB))

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

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

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

 

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

 

この記事について

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

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

 

なぜやるか

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

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

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

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

 

FTPデプロイの恐怖

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

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

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

 

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

2015-12-21_12.25.09

 

………

 

2015-12-21_12.11.21  

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

ある・・・よね・・・?(汗)

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

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

 

開発環境

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

 

現在の環境

開発環境

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

 - テスト環境(開発時にテストするための環境)

 - ソースコード管理

 - BitbucketによるGit管理

 

反映方法

 - FTPによるアップロード

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

 

開発環境の見直し

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

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

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

 

破綻の理由

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

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

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

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

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

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

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

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

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

 

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

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

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

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

よし、早急に見直そう!

 

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

 

個別の開発環境について

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

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

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

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

 

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

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

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

 

FTPアップロードは甘い罠

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

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

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

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

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

 

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

 

CIツール

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

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

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

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

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

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

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

 

自動デプロイツール

Capistranoを採用します。

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

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

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

 

まとめ

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

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

 

理想とする環境

開発環境

 - 各個人の開発環境(単体テスト用)

 - テスト環境(統合テスト用)

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

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

 

ソースコード管理

 - BitbucketによるGit管理

 - GitHubによるGit管理

 

反映方法

 - FTPによるアップロード

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

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

 

今回の戦績

2015-12-21_12.29.13

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

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

 

それでは、また!

 

Share on FacebookTweet about this on TwitterShare on Google+Share on Tumblr

この記事を書いた人

staff エンジニア:水谷健太
一覧に戻る

[ WANTED! ]

共に地方を創る仲間を、随時募集中です