#232 聞くだけCircleCI入門

2024/3/20 ·

  • エンジニアが扱う技術にも大人っぽいとか子供っぽいあると思うんですよ技術に?はい大人っぽいはまだわかるが子供っぽい子供っぽいはないかないやそういうこと子供っぽいはないかあーでもなんか渋みの違いとかない?渋みはあるんですか?なんかはいなんかネクストJSって言われるとちょっとキラキラしてる感じするんですよはいわかるですわかるです若い若い若いはい若いよねはい今回はそんな中でも



  • ちょっとこれは大人なんじゃないかなっていうエンジニアとして大人になるための色気が出てきてます色気が出てるアダルティなコンテンツを紹介していこうかなと思ってますほう僕の中でアダルティなエンジニアというのはですね自分でCI、CDのパイプラインが組めるっていうのは結構あると思うんですよしかもこれねめっちゃこう老練な感じじゃなくてどっちかっていうとナイスミドルぐらいの感じなんだよねうんうんうんうんうん



  • ナイスミドルこれちょっと僕らごめんなさい伝わんなかったんですけどナイスミドルはだいたい40代のイケてるおじさんって感じだよね全然思ってんのと違った違ったまあでもわかりますけどなるほどなるほどCICDそんなエンジニア界のナイスミドルだと思ってるんですけど今回僕はですね



  • web デイビープレスプラスというシリーズの技表者から出てるやつですね サークル ci 実践入門という本を読みましてむずそうちょっと自分のあのブログシステムに ci cd 組み込みたいなと思って スゴイ読んだんですよブログは結局その後作ってないんですけどはいこの後作りますはいスペが終わったら はいってことで今回は



  • 軽くそもそもCICDってなんとなくイメージはもしかしたらつくかもしれないじゅんぺいちなみにどんなイメージあります?僕は結構使ってる方なのかなっていう気はしてて例えばGitHub Actionsですね僕は主になのでローカルからプッシュしたら自動で検証環境が立ち上がってテストもある程度まで実行してくれて



  • みたいな感じですかね素晴らしいでも君はもう駆け出しじゃないから駆け出しに向けてそんな説明をしていこうと思いますまだギリ駆け出しですよギリ駆け出した?はいということで今回はCICDとはまず何ぞやCICDとは何ぞやという話からなんですけれどもこちらコンティニュアスインテグレーションスラッシュコンティニュアス2つ説があるんですけどえ、そうなの?デプロイメントもしくはデリバリーまあそうなんだなんかめっちゃ昔の



  • エピソードで僕がデプロイって間違えた記憶があったんですけどその諸説あるんですねありますちなみにこの本だとデプロイメントをしてましたそうなんですねはい



  • でじゃあそれぞれどこまでがじゃあCIなのどこまでがCDなのっていうなんか区切りもあるらしくてですねこの文はコンティニュアスインテグレーション継続的インテグレーションはコードに変更があるたびにテストを回しますよっていうそれがCICDが継続的にデプロイをしますよ



  • でこれデリバリーとデプロイメント実はどっちも世の中に用語があってすごい微妙に違うらしいんですけどコンティニュアスデリバリーは継続的にデプロイできるようにするそうなんだコンティニュアスデプロイメントは継続的に自動でデプロイする



  • へーだからデプロイしてるかデプロイできるような状態にしてるかが違うらしいなるほどデリバリー能が渡してる感強いですけどそうなんですね勉強になりました個人的には本当にどっちでもいいなって思ってしまった読んでてそうですねあとなんか継続的デリバリーの方はですねなんかそもそも世の中に結構意味が2つあるというかダブルスタンダードという状態になってるとほうダブルスタンダードって使い方合ってるかなあの



  • どういう詳細聞いたら判断しますシンプルに2個意味があるさっきの講義のCDはビジネスの中で継続的に機能を追加してて価値を発揮していきますよみたいなうんうんうん競技のCDがさっきの継続的にデプロイできるような状態にしますよっていうことらしいうんうんうんうんIs this double standard?



  • maybe maybe ok ok まあざっくりと概要はそんな感じですねはいでこれ登場した背景なんですけどもこれはですねデブオプスという考え方がねすごい関係ありますはいはいはいデブオプスめっちゃ僕この単語の意味わかりにくいなと思ってたんですよはいはいはいでわかりにくい理由は多分



  • 今の現場がもうそんなにしっかり分離してないからだと思うんです 分離してる現場がなんか多くない印象があるというかそうなんですねからなのかなって思ってて そうかもしれないですねそれだとこのDevOpsは開発チームと運用チームが協力しようねっていう文化のことなんですよで僕の中の開発チームと運用チームの区切りが曖昧だったっていうのが多分ね 一番理解できなかった



  • 正体だなと思ったんですけど開発チームってどんどん機能追加してバンバンデプロイしたいとそうすることによってバリュー発揮できるわけじゃないですか一方運用チームって安定的にアプリケーションを動かしたいっていうモチベーションがあるんでデプロイなるべく少ない方が



  • 価値になるんですよ自分たちのってなった時にこの2つのチームが分かれてるとそもそも最終的にやりたいことが相反してるしここで開発チームと運用チームのイメージって開発チームは機能を作りますと運用チームはそれを実際本番にリリースしたりとか日々の安定稼働みたいなところのイメージなんでちょっと個人的にはインフラチームっぽいなって思いました



  • そうかもしれないですね僕がエンジニアになりたての7年前から8年前からがDevOps流行ってるぐらいなので僕が最初にやってたのはそれこそ本当に開発と運用が分かれてた形で僕は開発チームだったんですけど開発してソースコードができて



  • それを開発チームで試験してリリースするんですけどリリースは運用チームにリリースするんですね運用チームはいろんな開発チームからソースコードとかシステム受け取って本番の環境にデプロイしてそのデプロイした本番環境じゃないなステージング環境かステージング環境でデプロイしてそこでまた試験やって性能検証とかやって問題なかったら商用でリリースする



  • みたいな役割の分け方だったんですねなのでさっき言ってたステージングにデプロイしたりとかそこで実際に試験回してみるとかそういう役割はまさしくこのCICDに当たる部分になってきてるなっていう風なのが僕の感覚ですねなるほどね



  • ちょっとインフラっぽいっちゃインフラっぽいけどテストとかその辺の運用に関する部分もいろいろやってるみたいなイメージかちょっとインフラっていうと狭すぎるのかそうですそうですシステム全体が動くことも責任を持ってるみたいなだから運用っていうとリリースした後っぽい印象を受けますけど別にそうじゃなくてリリースする前のところもやってたやって



  • やってますね僕のところもインフラじゃない運用側がでも僕のいるところはDevOpsカーではあってまた別で運用があってその運用のために



  • 運用はあんまりでもやっぱりコードとか叩けないんですが一応今後の思想としては例えばテラフォームとかを叩いて最初の環境構築とかもできるようにさせたいみたいなところあとはそういう風に構築した後の運用部分でデプロイするたびにテストをするとかところも運用が



  • 一部やっていて一部僕のデブオプス化もやったりしているみたいな感じですかねなるほどそういう開発チームと運用チームがですねもともとは別々のチームで動いてたんですごいやりにくさが発生してたというかまずそのデプロイの回数減らしたい増やしたい問題ありますし



  • あとそのデプロイした後にデプロイするのは運用チームじゃないですか問題発生した時にじゃあなんで問題発生したのかって気づけるのって多分開発者が一番気づけると思うんですよ作った本人がってなった時にじゃあでももうそっちのチームの人帰っちゃいましたってなったらもうダメじゃないですかロールバックしなきゃってなってそのままちょっと次の日まで待ってデプロイしてってなるとちょっとめんどくさいよねっていうところでその強調作った人がリリースできたら一番スムーズよね



  • っていう時に自動化したらいいんじゃないかとっていう時にこのCICDツールっていうのが出てくるとニーズが生まれたというわけでございますねこれをやることによって開発チームと運用チームが一体となって世の中に価値を届け続けることができる



  • そんな基盤を作っていけますよっていうツールになりますと実際いろんなツールが実はありまして代表的なもので言うと今回読んだ本のメインのやつでもあるサークルCI多分これが一番使われてるのかなどうなんでしょうねなんかちょっと今勢力と違いそうな気もするけど



  • 有名どころで言うとサークルCIトラビスCIっていうねこの界隈の草分け的存在らしいです草分け的存在がちょっと日本語難くて分かんないです創始者みたい開拓者みたいトンデンヘトンデンヘ北海道民だなCICDのCICD界のトンデンヘ笑



  • あんま馴染みないよトンデン兵にピンとは来ないかもしれないわかりますけどねそんなにトンデン兵身近じゃないんだ身近じゃない同民ですそれは結構身近だったからねジェンキンス日本人の人が作ったツールでよくね僕最初ジェンキンスおじさんってすごい勘違いしてたんですけどジェンキンスっておじさんじゃないですかアイコンが僕あのアイコンのことをジェンキンスおじさんって呼んでると思ってたんですね



  • え、違うんですか?違うらしくてはいジェンキンスって結構いろんなカスタマイズできてはいジェンキンスそもそもむずいんですよ結構あーそうなんですねはいで



  • ジェンキンスを社内でめっちゃカスタマイズし続けるとですねそのジェンキンスを運用するための専任のおじさんが作られないといけなくてそのジェンキンス専用おじさんをジェンキンスおじさんって言ってたらしいそうなんだずっと俺ねアイコンのことだと思っててねいや僕もそう僕もそうなんだっていうティップスいっぱいジェンキンスおじさんいるってことですね豆知識で



  • あとAWSのコードシリーズはいうんこの辺はまあAWSと相性がいいっていうところでAWS環境だと結構使われることが多いですねうんうんあとはさっきじゅんぺいの口からも出たGitHub Actionsはいこれ多分出たの結構最近だと思うんですよ3年前とかかなそうなんですか僕エンジニアになってからなんか登場したなってイメージなのでへー



  • なんですけどGitHubがそもそも使ってる人多いし結構広まってるなーっていう感覚がありますねGitHub ActionsもこんなツールがありますよとでCICDってさっき順平も言った通り自動でビルドとかテストして自動でデプロイしてみたいな



  • っていうことに対してCICDっていうのはちょっとあまりにも浅すぎるかなってそれを読む前は思ってたんですよ読んだ結果マジでそれ以上でも以下でもなかったなって思いましたいろいろスキャンして例えば脆弱性発見する処理加えたりとかそういう高度なこともできるんですけどやってることは本当にそれしかないなと思っててマジで本質はコードをプッシュしたらテスト…



  • テストを回してとかプッシュしたらデプロイされるとかプルリクエストをマージしたらデプロイされるみたいなところを自動化してるだけだなっていう感覚でしたね実際のワークフローのところも説明しちゃおうかなワークフロー



  • このCICDツール今回はサークルCIの本読んだんですけど大枠は多分どのツール使っても変わらないのかなとは思うのでまず実際どういう風なステップを踏んでビルドされていくかという



  • ちょっと待って先にサークルCIの特徴だけ説明しておこうかなツールこういうのがありますよと中でもサークルCIって他と比べてどういう特徴があるのっていう感じでちょっと他と比べてない説もあるんですけど一つはDockerが使えますコンテナを使って



  • 環境をすぐに作ってその環境でビルドするみたいなイメージですね他のはできないのが多いんですかいや他もできますねとりあえず書いてあった情報を言ってるけど多分これ他にもありますね次も多分他にもあるんですけど多様なプログラミング言語に対応してますとおそらくイメージできる言語はほぼできるんじゃないかなあと重量課金制になってますねサークルCIは



  • どういう課金なんでしょうねクレジットっていう概念がありまして例えば2万クレジットゲットしましたとビルド時間に応じてそのクレジット消耗していくみたいな



  • 時間なんですね時間だけではない例えばビルド遅くなってきたなって時にビルドするためのマシンを強くすることもできるんですよそうするとクレジットの消費量増えるみたいななのでマシンの強さ×時間プラスオプションやってるかやってないかみたいな



  • 感じで重量課金制となってます無料プランもあっておそらく個人でやる分には無料で使えるんじゃないかなっていうぐらいたくさん無料の枠がありましたあとこれは完全に感覚の問題なんですけど僕GitHub Actionsも使ってみたりしたことあるんですよただなんかサークルCIなんか早いなって思いましたねタスク1の早いなって思いましたこれは個人的な感覚ですで



  • あとねオーブスっていうなんかねテンプレートみたいなやつがあるんですよサークルCIって例えばこういう作業したいけどそのためにはこのコマンドいっぱい打たなきゃいけないっていう状況あるじゃないですかそういう世の中に一般的によくある状況をもう一個のオーブスっていうのにまとめてくれててそのオーブスの中にあるメソッドみたいなやつを呼ぶともうそれだけで自動で勝手にボーンってできるみたいなのもあって



  • なので結構難しいこととかも短い処理でかけたりとか例えばどんなリュードであったとか覚えてるのありますか例えばAWSのECSにデプロイするためのオーブとかありますね



  • 特定のサービスに簡単にデプロイできちゃうみたいなじゃあそれにオーブはメソッドみたいなものだと考えると引き継ぎに必要な情報を渡してそれを呼び出すだけでできちゃうみたいなそう



  • 本来だったら多分コマンドでやるとしたらマジでAWS CLI入ってるイメージ使って認証やったりとかいろんなコマンド打ってって打ってってパラメータ渡してとかいろいろやると思うんですけどそれがオーブスのメソッドに変数とか引数渡すだけでできちゃうと



  • 複雑なやつも簡単にできそうだなっていうありがたい感じがあったんで個人的には結構使い勝手というか使いやすいなって思いましたね実際じゃあどういう作業をやってるのっていうので僕これマジで具体的なところは分かんなかったしコンテナ使うっていうのがイメージついてなかったんですよ



  • なんですけど完全につきましたイメージがまずマシン上でビルドするってなった時にやっぱりどうしても言語とか必要じゃないですか例えばJavaのやつやるってなったらJavaのランタイムは要らないかビルド用のおそらくOpenJDKとかそういうの必要になるのかな懐かしいはい



  • とかPythonだったらそもそもPython自体入れなきゃいけないしアプリケーションやるってなったらPipインストールみたいな感じで依存関係も解決していかなきゃいけないじゃないですかそういうのをやるためのコンテナをまず作りますとでそのコンテナ作ったら次テスト回しますよねその中で



  • で結構フェーズごとにコンテナ実は作りまくってるんですよこれ テストフェーズはじゃあそこでもそのコンテナおしまいってなって次ビルドフェーズはいまあちょっとね



  • PythonとかビルドないよねないですWebアプリケーションだったらNPMだからJSのビルドとかするかな結構うんうんうんとかってやるってなったら今度はJSのコンテナ必要じゃないですかそしたらさっきテスト回したソースコードを次別のコンテナの中にマウントしてうんうんうんそこで次はビルドを行いますうんうん



  • そしたらビルドした後のソースコードが出現しますよねだいたいこのビルドの成果物のことをアーティファクトって言うんですよこの界隈



  • 言うかもしれないGitHub Actionsも多分言うからおそらく共通に近しいのかなと思ってますあるアーティファクトなんでアーティファクトって言うんだろう多分めっちゃかっこいいからだと思う大事ですよねかっこいいアーティファクトかっこいいアーティファクトかっこいいからねかっこいいもんなビルドの成果物いわゆるアーティファクトかっこいいが出てくるんで次はそれをデプロイしますよで



  • デプロイオンはまだコンテナ作ってその中にアーティファクトとかソースコード必要だったらソースコードを



  • いらないか普通に考えたらそのアーティファクトをマウントして本番環境に行ってらっしゃいって送り出すタスクを実行するみたいな感じで基本的にはコンテナを作って成果物を出してその成果物を次のコンテナに渡して成果物を出して次のコンテナに渡して最終的にはデプロイするみたいなこういう流れでなってんだっていうのはすごい思いましたねこういう流れになってんだね



  • って思いましたなんか一個のコンテナ作ってその中でごちゃーって全部やるわけではなくなんか一度ステップごとにやってましたねなるほどそうかコンテナ作ってサークルCIはそうなんですねサークルCIはそうやっててでGitHub Actionsも多分コンテナ使ってるイメージあるわあの流れはコンテナなんか



  • ギターアクションが動いてるときってくるくるって回っててなんか一個のプロセスの塊がこう何ですかブランチ状にこう生えていったりしていて順番にこうプロセスを達成していくみたいな感じなんですそれが一つのコンテナごとにやってるみたいなイメージなんですかねあれはねそうとは限らないと思うじゃあちょっとサークルCIのちょっと用語の方に入るんですけど一個一個のコマンドのことをですね



  • ステップと言いますと 樋口:うんうんうん 深井:コマンドでいいのに? 樋口:コマンドでいいのに 深井:ステップって言うんですね 樋口:そう これもかっこいいからです 深井:かっこいい もうかっこいいですね 深井:いやーコマンドもかっこいいですけどね 樋口:コマンドもまあかっこいいか 確かに コマンドちょっとなんか 深井:慣れすぎちゃった気がする 樋口:あれだね 渋めだよねちょっと 深井:あーまあまあ確かに 樋口:うん 床屋みたいな 深井:真面目そう 樋口:わかる 深井:床屋? 樋口:わかりますよ俺 床屋わかります 深井:床屋ぐらいの感じですね 樋口:わかります



  • そのステップをまとめているのがジョブですねこのジョブがビルドとかテストとかデプロイっていう流度でまとめられているようなイメージがあるんですねそれをちゃんとこういう順番で実行しますよっていう流れを組んでいるのがワークフローじゅんぺいがさっき言ってたのは



  • ジョブな気がしましたジョブはいであればコンテナ分けてる可能性ありますただ同じコンテナでやってる可能性ももしかしたらあるかなとは思うはいはいはい話の整理的にコンテナはジョブごとに立つんですかジョブごとに立ってました立ててましたこの本だとっていうことなんですねちょっと見てみよう後でどうなってんのかうん



  • いいね確かにって感じかなサークルCI結構内容自体はシンプルであとはこういうワークフローを動かすための設定ファイルというのをですね.circleciっていうディレクトリをアプリケーション内に作って設定ファイルをYAMLで書いておいておくっていう感じですね



  • あとはちょっとそのGitHubとかとの連携もできてGitHubと連携するともうサークルCI上に自分の許可したリポジトリ全部出るんですよなんでそのリポジトリに対してプッシュさえしてかつその.circleciの中に設定ファイルがあればもう動かし始めれちゃうっていうなんで動かすのも結構手軽でね



  • まあGitHub使ってるからGitHub Actions使わなきゃいけないっていうわけでは全然ないないっすねなんでそこは個人的にはサークルCIの方がGitHub Actionsよりもなんか分かりやすいなって思ったデバッグとかもしやすいですねちょっとGitHub Actionsの使い方知れてないだけかもしれないけどなんかエラー出た時の対処大変だなって思ったんですよ僕CICD触る時なんですけどサークルCIとかだと



  • 失敗したコンテナにSSHで接続して原因調べたりとかもできるんでそれはめちゃくちゃ便利すごいよねそれはめっちゃ便利なんかGitHub Actionでもしかしたらできるかもしれないけど僕がそれ作ってた時は知識なさすぎてもうそのステップの中にねデバッグ用のエコーのコマンドみたいなやつとかLSとかCDとか今どこにいいんだろうみたいなPWDとかやってうんうん



  • でもう一回ワークフロー回してチェックしてここが間違ってたのかってなって直すっていう面倒くさいかもしれないそれは面倒くさそうですねできるのかなヒッパーバックションズもコンテナかどうかがちょっと分かってないからあれなんですけどまあでもそのテスト回してるのは僕はUIの方のテスト回してるんで結構それだと



  • アーティファクトとかにビデオとしてもスクショとしてもテストダメだったら残ってるんですよデータがここがダメでしたってなんでちょっと細かく結構追っていけたりするなるほどそれ多分アプリケーション自体のデバッグじゃないですかどっちかっていうとそのワークフローを組むときのデバッグが大変だったなっていう確かにそうだ今のそうだな



  • はいはいはいはいっていう感じだったのでサークルCIね面白いですねなるほどなんか僕もちょっとコード系とは違いますけどAWSのSUMっていうCICD系のクラウドフォーメーションみたいなもんいじってた時にのりさんのさっき言ってたパイプラインの中で何か起きた時に何だかわからんっていう



  • クセあったんで今の話きっとサークルCI確かに僕も使い方分かってないだけかもしれないですけどね機能としてはあったかもみたいななるほどねっていうのでサークルCI



  • 使って多分これあと深掘りするってなったら例えばこれビルドって速さ超大事なんで遅いとやっぱり開発者が体験良くないんで結構速さとかこだわってるんですよなんでそのキャッシュ戦略みたいな感じで何をキャッシュするかみたいな戦略書かれてたりとかでもね読んだ感じそれが全てなんじゃないかぐらいの内容で理解できたから不安になりましたね読んだ後に



  • 結構ハードル高くないと思うすんなり入ってくる内容だったですねなのでぜひ自分のプロジェクトに組んでみたいとかまずは個人で触ってみるのがいいのかなとは思いましたねでも無料で使えるっていうのはでかいなと



  • そうですねなんか今の現場入ってそのギター幅アクションズが結構使われてるのでなんかCICDってパッと聞くとめっちゃかっこいいですけどなんかもうすごそうじゃないですかだから無理そうだなって思ってたんですけどギター幅アクションズのコードとかを見てみるとヤムルですねなんか意外と別に読めるのは普通になんかあ



  • こんな感じなんだっていうので結構CICD系のコードって意外と読みやすいんだなっていう気がしてます確かにあれ多分難しいポイントってGitHub Actionを使うことじゃなくてどうやったらデプロイできるかを知ってなきゃいけないところですよそうそうですねCICDのコード自体は読めるというかその流れを知ってれば読めるしかけるしここでログインが必要なんだとかIWSだったら



  • そこら辺もサイクルCIだったらモジュール化してあるというか用意されてるされてますねされてるものであれば簡単にできちゃうっていうところでぜひちょっと皆さん使ってみてくださいというツールでございましたありがとうございましたしかし儲かりそうなサービスですね本当にサークルCIと思って時間課金じゃないですかなんで多分システムがすごい機能が増えたりとか



  • してくると試験とかデプロイに時間かかるようになってくるじゃないですかそうするとお金がかかるとなおかつもう入れちゃってて複雑なソフトウェアなんてそれを使うのやめることなんてできないんで確かにどんどん儲かるいいサービスだなって



  • 思いましたね作りますか素晴らしいリプレイスできないものは作りますかヒマプロCICDすごいヒマプロCICDこれ半端ないマシンスペックとか必要になりそうだよねユーザーごとに多分コンテナ立ててるんでしょうねそうですね本当にデータセンターみたいなAWSでいうEC2みたいなそういうのがあるんでしょうねボーンっていう何かとんでもないのがあると思うありがとうございます流行り



  • 言葉のうちの一つなんで そうですね押さえておこうっていうところですねでちょっとこの本はね もう何年前だろうねこれこれソフトウェアデザインで当たった本なんですけど あーそうですねもう4年前の本になってしまっているのでちょっとUIとか使用感は違いましたね あーはいはいはいでもまあおよそ大枠は変わってないうんうんうんまあ現場でやるのもだってその辺ですもんね多分めっちゃ凝ったことしないはずだから うん



  • あとはあれですねなんかこれ導入するのも多分プロジェクトの最初でしょうねそれはある本当にもう今ある巨大なソースコードでかつテストないですみたいな時にね終わるそれのプロジェクトを立てる必要があるそうだよねそんなの許されないんであんまりねデプロイだけはいけるかでもさすがにデプロイはもともとされてるかだいたい



  • いやー場所におりますよマジで?場所におります手作業ある?あります全然見たことありまして作ったことありますよそうなんだ手順書マジかはいまあない方がいいですよもちろんそうだよねはいっていうのではいありがとうございましたありがとうございましたありがとうございましたエンディングトークとかもなしで大丈夫ですか?大丈夫かないいですか?どうぞえっとまあこの前の回になるのかどうなのかちょっと怪しいですけどステータスコードの話をしたと思うんですけどはい



  • ステータスコード開発者ツールとかでどんな種類があるよとかどんな見れるよって話のエピソードがあるんですが頑張って前に編集して出しておきますね開発者ツールでエラーの時って何番って出てかつ英語でなんとかかんとかエラーみたいなあれやべえ何ケースって言うんですかスネークケースの全部英語大文字のやつ



  • 定数とかで使う時の表現があるじゃないですかコンスタント係数コンスタント係数コンスタント定数コンスタント係数っていう全部大文字コンスタントケースっていうイメージあるけどコンスタントケースか定数で使うからってことねそのコンスタント係数プラスステータスコードみたいなで返ってくる時があって最近あったのがコンスタントケース何とかかんとかエラーで



  • 200で返ってくるんですよねこれたまにあるんですかエラーなのに200で返ってくるっていうのが最近頭に来てたんですけどそれあれじゃないたまにAPIとかでさ基本レスポンス200で返してその中で独自のエラーコードみたいなやつ定義してるケースないですかもっと言うとなんだっけな



  • 間違ってたら申し訳ないんですけどAPIゲートAWSの何も設定しないと全部に役立ったりしないっけ?気のせいかな?ちょっと待ってねサービス特定まあなんか難しかったんだよなそれ結局サーバー側のサーバー側?API側のログ



  • なんて言うんだろうあれちょっと深めのログなんて言うんだろうな問い合わせてそのAPIを作ったところに問い合わせて聞いたら408が返ってきてますって言われてでも実際会社ツールとかで見るとこっちは200ですしあとはAzureなんですけどAzureのサーバーのログストリームログを見ても200で返ってきている



  • みたいなところで特別なログを見る設定みたいなのをしておかないとその408は見れなかったんですよねただブラウザの方とかには200で返ってきててみたいな状況でマジでデバッグ難かったなっていうのでこういうのよくあるのかなと思って結局特別な方法だったら見れたってこと?見れましたログ用の診断設定みたいのをAzureだとあって



  • それを設定しておくことでその取得したログの中でクエリみたいなのを実行して検索して408を見つけるみたいなじゃあステータスコードで返ってきてたっていうよりはログの中身が408だったから見つけれたイメージなのかな



  • 深井:そうですね そうなりますね 最終的にはヤンヤン:ちなみに僕がさっき言いかけたAPIゲートの話はちょっと勘違いでラムダでした深井:ラムダなんだヤンヤン:ラムダがエラーでもなんでも200返すんでってことだと深井:なるほどねヤンヤン:そうですね ちょっと事例案のかなと思って気になったところでした深井:じゃあもしかしたらラムダでAPI叩いててそれがラムダに戻ってきてラムダから200で返ってそのレスポンスの中に408が入ってたみたいなヤンヤン:そうそうそう深井:ことが起きうるのかヤンヤン:そうそうそう



  • ラムダなのかAzure Functionsなのかなんかわかんないですけどねなるほどたしかにたぶんこの200はなんでこうなってるとかは詳しいわけじゃないんですけどたしかラムダは動いたよっていう200たしかにそうだなラムダの先でやり取りしたやつとは408だったけどだから内容は408入れといてラムダ自体は成功してるから200うん



  • ただあれですよベストプラクティス的にはラムダでちゃんとステータスコード入れてレスポンスするのがベストプラクティスなんですけど何もしないと200なんでそういうとこに引っかかったのかもしくは知らない何か408だと結局タイムアウトエラーだったんですよサーバー側のでそれは何でしょう多分向こうのサーバーが例えば混んでるときネットワークが混んでるときとかに



  • タイムアウトになっちゃうぽくて最終的には見つけたのがでそれをまあどうにかうちでハンドリングして対処するみたいな感じでやったんですけど難かったなーっていうそういうのあるんだーと思ってそれは難かったね難いパターンやんいいななんか仕事してるわちゃんと確かに



  • そうですね いやもう最終的にはこのヘルプでやってもらっちゃった感じなんですけどちょっと無理っすっつっていい壁にぶち当たっていいねそんなふざけんなっていう話でしたなんでステータスコード200なんやねんっていう同じ引っかかりがある可能性もあるんでね似てる人も言うて結構まあまあいるんでね確かにねこの前のあれだってなってる人いるかもしれない



  • 明日になるかもしれないしね そうそうそうそしたらね あっこれ聞いたやつだ 可能性ありますからねヒマプロでやったやつだ カサカサ



  • かっこよ参考になったらいいですねありがとうございますでは締めちゃいますねハッシュタグひまじんプログラマーでSNSのXでフィードバック募集してますので何でもかんでもお気軽にお願いいたします我が家にはこんなアーティファクトあるよとかねお願いしますそれもなんか違う意味ですけどね本来の意味のアーティファクト



  • あとはポッドキャストの説明欄からGoogleフォームで番組の要望質問お便りお待ちしてますのでお気軽にお願いいたしますこんなツールも紹介してほしいとこあったらお願いしますのりさんが紹介します頑張ります各種ポッドキャストプラットフォームでのフォロー高評価お待ちしてますので何卒お願いいたしますお待ちしておりますではまた次回バイバイ



  • さあ皆さん次の商品は目玉商品ですこちらめちゃくちゃでかいエンターキーわー大きいこれがあるとストレス発散生産性アップ快適な睡眠もえ枕にしちゃうんですかこちらの商品はお値段など1024円わー2の10乗



  • そして今番組終了1時間以内にGoogleフォームよりお便りを送った方はちっちゃいスペースキーも付いてきますポケットに入れて持ち運べますね番組の高評価フォローもすると会員割引なんと90%オフほぼただ今すぐご応募

0:00 36:16

#232 聞くだけCircleCI入門