# 去年やったこと
## インフラ周辺
- @ハナセルはHerokuを使用
- いさりび、Becoma、TelepathはGoogle Kubernetes Engine(GKE)を使用、DBはCloudSQLでMySQLを使用
- Becomaはプッシュ通知用にFireBaseも使用

### 開発環境周り
- デプロイ・開発環境用にDockerfileとDocker-composeファイルを用意
- 開発環境はできるだけ全体で統一することを強く推奨
- 使用する言語が一緒なら極力統一する
- [Dockerfile例](https://github.com/beaconFUN/Isaribi-server/blob/master/Dockerfile)
- [Docker-compose例](https://github.com/beaconFUN/Isaribi-server/blob/master/Docker-compose.yml)
### kubernetes周り
- Kubernetesを使った理由は昨年度のリーダの趣味(インフラできる人がリーダしか居なかった)
- kubernetes採用の理由：ロードバランシング、セルフヒーリング、ローリングアップデート等の機能、Dockerコンテナをそのまま本番に適切に持っていくことができる点
- kubernetes経験者が居ないなら、無理してkuberneteを使う必要はない
- PBLの規模なら、HerokuやGAEなどのPaaS、EC2やGCEでも十分です
- インフラの経験者は少ないと思うので、出来る人がちゃんと責任を持って作り込むことが重要
- サーバサイドにインフラを意識させないように自動化を徹底する
- [kubernetesのマニフェスト](https://github.com/beaconFUN/Isaribi-server/blob/master/kube/deploy%2Bservice.yml)

#### アプリコンテナとCloudSQLの接続
- 直接CloudSQLに接続するのはセキュリティ的に不可能
- Pod内にCloudSQLにつなぐためのプロキシコンテナを用意
#### 永続ストレージの取り扱い
- Pod内のアプリコンテナにGCEの永続ストレージをマウント
- 本当はGCSなどのオブジェクトストレージを使ったほうが良い
#### 継続的デリバリー（CD)
- 開発時間の都合でCI(継続的インテグレーション)が通ってマスターにマージされた際に、CI側でデプロイの雑構成
- 本当はSpinnakerなどのCDツールを使うべき
- [コンテナビルド用のシェルスクリプト](https://github.com/beaconFUN/Isaribi-server/blob/master/build_container.sh)
- [CD用のシェルスクリプト](https://github.com/beaconFUN/Isaribi-server/blob/master/deploy.sh)
## ドキュメント整備
### プルリクエストガイドライン
- [実際のドキュメント](https://github.com/beaconFUN/beaconFUN2018_documents/blob/master/documents/pullrequest.md)
- 2018年のビーコンプロジェクトはGitHubプルリクエストベースの開発を行っていました
- とはいえ、プルリクエストの書き方に慣れていない人が多かったので、共通の書き方やチェックリストを用意
#### 主な観点
- 小さくまとめる
- 一つのことだけをする
- 一行の長さを考える
- ビルドできるコードをのみを含める
- すべてのテストが通ること

### コードレビューガイドライン
- [実際のドキュメント](https://github.com/beaconFUN/beaconFUN2018_documents/blob/master/documents/codereview_gide.md)
- プルリクエストをマージするには、CIがパスしていること、コードレビューをパスしていること
- コードレビューやチーム内などの同じ技術領域の人で行った
- 例：サーバサイドのコードレビューはサーバサイドの人がする
- 最低１人、余裕があれば二人以上のレビューをもらう
- [実際のプルリクエスト例](https://github.com/beaconFUN/Isaribi-server/pull/39)
#### 主な観点
- 仕様と実装はあっている
- 無意味なロジックがない
- DRYを守っている
- テストが適切に書かれている
- メソッド名、変数名などが適切
- コーディングルールを守れている
- メソッドからは予想できない副作用が含まれていない
## CI(継続的インテグレーション)
- TravisCIとSiderを使用
- GitHubにプッシュされると自動で実行

### TravisCI
- 単体テスト・結合テストを実行
- プルリクエストをマージするにはCIが通っていることを必須化(サーバサイド)
- テスト以外にも、RubocopなどのLinterによって静的コード解析
- 単体テスト・結合テストが通っても、長すぎるコードや言語の作法に則っていないものはCIが落ちるようにしている
- マスターにマージされた際は、Kubernetesクラスタへのデプロイも実行
- [Travisの設定例](https://github.com/beaconFUN/Isaribi-server/blob/master/.travis.yml)
### Sider
- Siderで命名ミスや脆弱性診断を実行