こちらのツイートの通り、同僚の@canoefishingがいま開発中のプロジェクトのディレクトリ構成を褒めてくれたのでスケルトンコードにして晒してみます。 少しでも誰かの参考になれば幸いです。 何かを参考にしたわけでなく、わたし自身の経験に基づいたものなのでもっといい方法があれば教えてください。
前提
いま開発中のコードが元になっているため、下記のようなWebアプリを想定しています。 ただし、srcの中身以外は少し変えるだけで汎用的に使えると思います。
- PythonのFlaskで構築するWebアプリ
- 設定切り替えはFlaskに依存
- 主にAPIサーバーを想定
- Blueprintsを使っているので多少のUI開発くらいならいける
- constraints.txtを利用
- 利用したいライブラリとその依存ライブラリを明確に区別しておきたいのでconstraints.txtを利用
- Dockerを利用
- わたし個人ではDockerを使わないプロジェクトはもうほぼない
プロジェクト構成
百聞は一見にしかず。
スケルトンコードはrhoboro/webapp_skeletonに置いています。
さっそくgit clone git@github.com:rhoboro/webapp_skeleton.git
をしてみてください。
cloneできたら、 make test
を実行してみましょう。
テストが動くはずです。
その他のコマンドに関してはすべてREADME.mdに書いてあります。
後から用意するのは大変だと経験上学んでいるので環境ごとの設定ファイル切り替え、テスト実行環境、CIの設定ファイル、Dockerfile、Makefileあたりを最初に用意するんだけどそれ見た @canoefishing が褒めてくれたので今日はハッピーだった
上記ツイートより。
それではプロジェクト構成の概要を説明へ。
構成の概要
-
- 都度docker ...と打つのが面倒なのでショートカットとして用意
- 用意しているコマンドは4つ
- dev: 開発用設定で起動
- production: 本番用設定で起動
- constraints: constraints.txtを出力
- test: テストはpytestを利用し、Linterはflake8を利用
- すべてはDockerコンテナ上で実行
- 本番でも同じように利用したいのでソースコードはマウントでなくCOPY
-
環境ごとの設定ファイル切り替え
- 上にも記載した通りFlaskの機能を利用し、src/config/に格納
- src/config/default.pyを基本設定とする
- app.config.from_env("APP_CONFIG_FILE")で基本設定を上書き
- src/config/development.pyで開発用設定に
- src/config/production.pyで本番用設定に
- make devで開発用を起動、make productionで本番用設定で起動
-
ライブラリの依存関係管理
- 直接必要なライブラリのみをrequirements.txtに記載
- make constraintsで依存ライブラリのバージョンを記載したconstraints.txtを出力
- constraints.txtの使い方はDockerfileを参照
- テストでのみ必要なものはrequirements_dev.txtに記載し、本番環境には入れない
-
テスト実行環境
テスト環境はあとから追加しようと思うと超大変
。最初に用意するのが大切- unittestをベースにし、src/tests/に格納
- 標準に合わせておくほうが何かと楽
- 通信を行うテストが増え重くなってきたのでpytestを導入した
- make testですべてのテストを実行
- make test MARK=hogeで@pytest.mark.hogeデコレータをつけたテストのみを実行
-
CI環境もあとから追加しようと思うとちょっと大変
。最初に用意するのが大切- うちは大体どのプロジェクトもCircle CIを利用しています
- 今回のスケルトンコードはまだデプロイの必要がないためテストのみ
- わたしが関わっているプロジェクトはほぼ全てmasterへのマージで自動デプロイされるようにしています
- 開発はdevelopブランチで行い、stagingブランチへのマージでステージング環境に自動デプロイ
-
- Dockerfileの書き方に慣れておくのが大事
- (プロジェクト開始直後の簡単なWebアプリ環境なら)慣れてたらすぐ書ける
- 開発時から利用しておくと吉
- 本番でもできるだけGKE(k8s)を使いコンテナで
- GCEやEC2でもDockerで動かせるようにしておくとデプロイが段違いで楽になる
- 開発時にDBが必要になったらdocker-composeで
- 他の人にも触ってもらいやすくなる
- 自分以外にテストや動作確認をしてもらうために都度環境構築を頑張ってもらうのは酷
- Dockerfileの書き方に慣れておくのが大事
-
その他普段から気をつけている点
- README.mdを必ず書く
- ソースコードは一段下げ、プロジェクトのトップディレクトリには置かない
- Dockerfileでまるっとディレクトリを指定したい
- ドキュメントをしっかりと残す
- GitHubのwikiに集約
- 明日の自分は他人
- 自分自身を含めプロジェクトメンバーはいつ変わるかわからない
- 環境構築系の質問はとても時間を食う。双方にとって時間の無駄でしかない
- いつPCが壊れてもいいようにしておく
- *rc系のファイルも自分のリポジトリにコミットしておく
- ここまでのことができていればいつ開発用PCが壊れても怖くない
- OSのメジャーアップデートはクリーンインストールで練習台にする笑
いけてない点
-
ホスト上では依存関係の解決ができないので警告が出る
- 警告を消すためだけにホストマシンでの実行方法でvenv環境を用意している
-
デプロイ系のスクリプトが出てきたらどうするか問題
- デプロイスクリプトはアプリと一緒に管理したい
- masterへのコミットで自動デプロイしたいため
- GKEの利用等でアプリと同階層でNginxイメージを用意する場合などはソースをさらに1段下げる必要がありそう
- デプロイスクリプトはアプリと一緒に管理したい
まとめ
下記を必ず
用意しましょう。早ければ早いほど導入は楽になります
- テスト環境
- CI環境
- Dockerfile
- 自分の設定ファイル(*rc系等)を格納しておくリポジトリ