Weitere ähnliche Inhalte
Ähnlich wie プログラマ三大美徳を実現するデプロイフローを目指して (20)
Kürzlich hochgeladen (20)
プログラマ三大美徳を実現するデプロイフローを目指して
- 7. リリース関係のステップ
● PRマージ
● release ブランチの作成
● 必要に応じて修正やリリースフラグ変更
● release タグの作成
● dev環境デプロイ
● 本番デプロイ
○ DB migrate
○ memcached の cache clear
○ その他最適化(view cache, route cache)
○ Elasticsearch の index 更新
- 8. 弊社で自動化されている部分
● PRマージ(approveされたら自動)
● release ブランチの作成(コマンド一発、pushまで)
● 必要に応じて修正やリリースフラグ変更(手動でPR)
● release タグの作成(コマンド一発、pushまで)
● dev環境デプロイ(pushされたら勝手にデプロイ)
● 本番デプロイ
○ circle CIからワンクリック
○ DB migrate(自動)
○ memcached の cache clear(自動)
○ その他最適化(view cache, route cache) (自動)
○ Elasticsearch の index 更新 (自動)
- 18. 2018年8月
● 鈴木(私)が2人目エンジニアとして入社
● develop ブランチをそのままデプロイ
○ eb deploy macloud-dev
○ eb とは AWS ElasticBeanstalk というEC2やLB、オートスケールの管理などやってくれる
● AWS ElasitcBeanstalkコンソールから本番に手動デプロイ
● 検索サーバのindex更新は手動
● 環境設定は手動
● PMなし。デプロイはエンジニアがやりたい時にやる
● DB migrate, cache clearは手動
○ 次ページで詳しく
こ
こ
- 19. 「DB migrate, cache clearは手動」 の詳細
● (雑に)サーバ1台の場合のeb deploy の内部的ステップ
1. zipでS3にコードが上がる
2. コードがサーバ内に配置される
3. 即座にLB経由でアクセスがくる
● 2のタイミングで急いで手動でコマンド
○ php artisan migrate
○ php artisan cache:clear
● 実行遅れると
○ DBの状態が古いのでコードと食い違いエラー
● 詳細はこちら
○ https://tech.macloud.jp/entry/2020/01/08/121733
- 21. 2019年05月
● 津崎(@zackey2)さん入社。エンジニア3人目
● git flow を手動で運用開始
● しばらく運用定まらず、定式化されるまでマニュアル運用
導入目的
● developブランチ からリリース(①)
● 無関係な②をコミットしてから問題が発覚!!
● 修正(③)を develop に入れてリリースせざるをえない
● ②もしれっと本番デプロイされてしまう
● hotfix を導入したい!
こ
こ
- 25. トラブル
● migrate & cache:clear しているはず
● でも、WebサーバでDB古いような不整合のエラー
何が起こった?
● リリース時にサーバー二台に対してデプロイ
● キャッシュクリアは各サーバで行われる
● リリース中のユーザアクセスで、古いサーバによりキャッシュが再作成
● 新しいサーバで参照してエラー
- 26. 解決策
● Laravel の CACHE_PREFIX を使用
● コミットハッシュを入れて、新旧バージョンでキャッシュを仮想的に分離
● やったね!🎉
- 31. reletan script とは?
● めんどくさいリリースブランチ作成とタグ作成を半自動化
● local repository を最新に
● git flow コマンド自体の設定
● 前回タグからの差分PRリスト抽出
● ブランチ作成やタグ作成をリモートに自動反映
- 33. 同 2020年08月
● 大きな機能のリリースが増えてきた
● feature フラグを使用することで、フラグをオフにしてどんどんコードを本番に入れる
● ※feature ブランチとして独自進化ブランチは
やらない
○ マージする時のコンフリクト解消つら過ぎ
この手法の課題
● 環境変数はまだAWS ElasticBeanstalkのコンソールから管理していた
(手動)
● dev, prod で同じ値を設定するが、オペミスが発生しやすい
解決策
● 環境変数もコードで管理🎉
● .env.visible と .env.secret を分離して運用負荷は重くならないように
● CircleCIでデプロイ前に.envにまとめて巻き込むように
- 35. 自動マージ仕組み
● CircleCIで PRのURLは ${CIRCLE_PULL_REQUEST}
● Github API の URLに変換
● マージ可能状態 meageable_state を取得
● 判定OKなら Github API の merge エンドポイントを叩く
○ 参考: https://docs.github.com/en/rest/reference/repos#merge-a-branch
- 41. 2019年11月
workerサーバについて
● before: メール送信のジョブ実行をWeb経由で実行
○ CloudWatch Event -> lambda -> Globalに露出しているElasticBeanstalkでジョブ受付
○ ジョブ処理を順次行うため、一斉メール送信などで処理がつまる = 他の通知が止まる
○ ジョブ実行トリガーが Global(トリガだけなのでリスクは低いが、セキュリティ問題)
● after: workerサーバを新設し、ジョブ処理をお任せ
○ Webサーバからジョブを積み、 Workerで並列で処理
○ 処理がつまる問題の低減
○ 負荷も分散
Worker サーバが増えたがCircleCIでデプロイ自動化されているので安心
- 42. 今後の課題
● worker と web が直列でデプロイされ、時間がかかる
○ Webのコードが先にデプロイされると、古い Workerで実行され、コードが食い違うとエラーになる
(多分)
○ 対策案:
■ ちょっとだけ時間差で workerが先に始まる
■ IDを引き渡すだけのジョブにすることで問題を緩和
● デプロイフロー以外の確認や社内共有が手動が多い
○ dev入った後のPMやそれぞれのエンジニアの確認
○ リリース後の、リリースリストを slack で共有