環境構築

[tomo-kn]

4 で決めたことを参考に、CircleCIで自動デプロイできるところまで構築する。

コミットメッセージのルールは #3、サービスの概要などは #1 を参照。

[tomo-kn]

docker-compose up -dでrailsのserverが正常に立ち上がるまで：https://zenn.dev/tmasuyama1114/articles/4ed199ce0478e7 主にこの記事を参考（First commit）

[tomo-kn]

CircleCIで自動テストするところまでは完了した。下の記事で言う「6.開発環境構築」までは終了したと判断し、いよいよ「7.プログラミングの実装」に移る。 webアプリ開発の手順まとめ！準備やアプリ設計プログラミングの学び方 駆け出しエンジニアのオリジナルアプリ開発備忘録 webサイト構築の流れを知り、プロジェクトを効率的に進めよう（後編）

サーバー構築や自動デプロイは後回しにする。ただし、独自ドメイン（hayakuchi-championship.com）だけは早いもの勝ちなので、お名前.comで先に取得しておく。 <第32回>番外編：ドメイン取得はどのタイミングで行うの？ ドメイン取得後は、なるべく早くサイトを公開しよう！

[tomo-kn]

Twitterで「個人開発　ステージング」「ステージング環境　ない」で調べたところ、自分と同じようにステージングを作るか悩んでいる人が大勢いた。意見がはっきり二分しているのも面白い。 結論、本気で運用していくならステージングはあったほうがいいし、転職活動用と割り切るなら別に本番環境のみでOK。

もちろんこのサービスは本格的に運用していきたいのだが、↓の記事を参考に良いステージング環境を作るとすると、インフラの費用がかなりかさむ。 「コストがかさむこと」「機能追加やバグ修正などの運用を楽にかつ安全にすること」この2つを天秤にかけて、優先度をつけるべし。 ステージング環境とは結局なんなのか。

↓↓↓ 結論、ステージングはコスト面を考慮し、用意しないこととする。 ステージング環境でばっちり検証したけど、本番で沼った話（Handii）：スタートアップ開発しくじり先生（6） 毎日何度も本番環境にデプロイをしている話

[tomo-kn]

また、自動デプロイについてだが、やはり完遂することにする。 アプリケーションがシンプルなうちからこまめにデプロイして「どの改修のタイミングでデプロイが失敗するようになったか」を分かりやすくしておくことが、問題解決の時間を短くする上では有効な戦略と判断。 Dockerを使うからそういうことは少ないだろうとは思いつつも、極力リスクヘッジをしていきたい。 勝又健太さんTwitter CI/CD のベストプラクティス 胃が痛いビッグバンリリースはもう嫌なので、デプロイを日常にする

他に考えられるメリット・デメリットは以下の通り。 <メリット>

• 早いうちから本番環境への自動デプロイを回すことができる
• 独自ドメインを取られる心配がない
• デプロイでエラーが出たときに対処しやすい
• 実装に集中できる

<デメリット>

• お金が余計にかかる
• 何らかの脆弱性があった場合、セキュリティリスクがある
• あまりにもサイトの質が低い状態が続くと、Googleに良くないアプリと判断されかねない

改めて、#4 と#3 を参考に、「hello world」を自動デプロイするところまで一気に持っていこう。

[tomo-kn]

メモ：AWS のECRにdockerイメージをpushするときは、powershellから $ wsl -u root でrootユーザーとしてログインし、操作を行う。 （volumeでマウントされたファイルのパーミッションはWindowsでは変更できないから）

[tomo-kn]

メモ：ECRのライフサイクルポリシーを「expire | imageCountMoreThan (3) | any」に設定。 最新3つのリポジトリを保管し、それより古いリポジトリは自動で削除される。https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/LifecyclePolicies.html

[tomo-kn]

メモ：サービスを本格的に運用するまでは、コストを極力抑えるために、ECSサービスの必要タスク数を0に設定しておく。 mainブランチにマージしてCircleCIのCI/CDが走ったときだけ、ちゃんと本番環境にアップできているかを確認するために、タスク数を1に更新。 確認が終了したら、また0に戻しておく。