この番組はエンジニアの成長は楽しい学びからをもとに日々学んだことをワイワイとアウトプットしていくラジオでございますはいお願いしますということでじゅんぴーくん今日は本当にあった話をしていこうかなと思います普通のね普通の本当にあった話普通に本当にあった話をしていこうかなと思ってますかいさん休みですね今日は

カイツさんお休みですね不在でこう言うといつも嘘を言ってるみたいになっちゃうんですけどそんなこともないんですけど今日ちょっとどっちかっていうと実はエピソード感強い部分というかパーソナルな話をしていこうかなっていう感じですねはいお願いします本日のテーマはですねCICD一体何をトリガーにして何を実行するの問題はいはいはいこれね

僕のちょっとこれまでの経歴をお話しさせていただくとですねはいそのトリガーとかに結構フォーカスしている感じですかいやというかまあなんかCICDどういうものなのっていうところからさらに踏み込んで具体的にはこういうことをするとなんかいい感じで回るのねっていうところまでを知れると嬉しいんじゃないかなエピソードにしたいなと思っている知れるかなエピソードはい分かりましたはいはい

でちょっとこれまでの僕の経歴をお話しさせていただくとですねまずSES最初の現場時代ここはですねおそらくCICDは組まれていたはず組まれていたはずしかしテストコードはまずなくててかCICDって言うとちょっとあれかもしれないデプロイ用のスクリプトがあっただけかもしれない

何してたんだろうなあれはちょっと具体的に何してたかわかんないですけどデプロイはそれスクリプトでやっててSQLは別で流してたんですよなのであんま完全自動化はされてなかったはず実行タイミングも手動だった続いてメンター時代この時はもうねCICDとか全く関係ないです自分たちであの

教材のサイトとかも運用してたんですけど完全手動デプロイでやってましたその後転職して求人サイト運用時代この時もデプロイ用のスクリプトはあったんですけどデプロイは手動かつ手順違う場合とかは毎回手順書を書き換えてそれをリーダーが実施するみたいな感じでした

ここもSQLは別で流してたしテストコードもなかったんで同じくあんまCICDみたいなしっかりした流れにはなってないとインテグレーションしてない感じですねデプロイのみだったんですよしかしですね私今一人でプロダクトを作るしかも短期間で2個もみたいな状態になってるんですけどそれをやるにあたって

こまめにそのデブ環境にデプロイしてったりとかしなきゃいけないんですよっていう時にCICDがないと死んでしまう死んでしまうかもしれないもうめんどくさすぎてやばいめんどいしデプロイしてる時間がもったいないんではい

回数しかも最初多いし多分うんうんうんこれなら最初にコード作っちゃって自動でデプロイするようにしてそれでやってった方が絶対それでやんないと僕は死んでしまうと思ったんですよはいというので組んでたんですけど結構苦戦しましてなるほどこれまで経験がなかったわけですもんねなんかちゃんとしたそれまで経験なかったしちゃんとしたものも見てきてないしなんならテストコード書いたことないうん

っていう状態から始めてますはいはいはいすごいっていうので今日話すのはなんかこう世の中的にこれがベストプラクティスだぜっていうのはあくまでちょっとあのなんだジェミニーから出てきたやつが今裏で実は用意されてはいるんですけどはいそれはさておきさておき今回こういう試行錯誤してこういうとこに詰まって最終的にこういうとこに落ち着きましたその結果今のところでは問題出てませんよっていうところの

ベストエフォート的な感じだよねっていうのの紹介とあとは最後ジェミニだったらどういうのを作るのっていうのを聞いた結果をやっていこうかなと思いますノリさんのベストエフォート

ノリさんのベストアイフォートこれ多分どんなアプリケーション作ってるかによってもデプロイの手順イメージ違う気がするんですよなので今回私が使ったのはですねLaravelとReactLaravelはPHPのフレームワークでなので基本的にはインタープリターで動くコンパイルしなくても動く系の言語ですねReactはタイプスクリプトを使っててデプロイするならビルド必要

っていう状態ですとあと環境はですねDocker環境でDockerで作ってましたなんでローカルはDockerで動かしてあとDevと本番もねEC2の中でDocker立ててそこで動かしてますこれがねまた厄介ポイントだったんですよ

正直僕はDockerを使って本番環境まで運用みたいなのをやったことないうんうんうんので実際これ合ってるのかどうかみたいなのがよく分かってなかったなるほどあとブランチの運用はいもう多分大事だと思うんですけどこのパイプラインの話するにあたって基本的にはフィーチャーで開発してデブにマージしたらデブにデプロイされてテストしてOKだったら

メインにマージして本番環境をメインブランチで作り上げるみたいなめちゃめちゃよくあるフローですねを採用してました一旦ここまで大丈夫ですか一旦大丈夫ですそのデブにマージして大丈夫じゃなかった大丈夫じゃなかったなデブにマージしてテスト流れましてOKだったら

ごめんさっき言ったテストはどっちかっていうとE2Eテストの方自動テストはもっと前に動かしているE2EテストE2Eテストも自動で回る

いやこれはね気合で回る気合で回る気合で俺が回るパターンじゃあ回ってじゃあそれで気合で回ってOKだったなってなってマスターへのマージーマスターじゃないメインへのマージーそこはまた手動でのりさんがデブからメインでマージしてるいやえっと手動か自動かは今は割と何でもいい

とりあえずそういう流れで本番まで持っていきたかったそれを自動化したかったっていう話ですねOKですまずですねちょっとララベルってどうやって普段デプロイするのっていうところから解像度を高めるためにお話するんですけど僕今までやってたやつだと

一旦もう機能は出来上がってデブでのテストも完了したと思ってください本番上げるってなった時に何するかっていうとまずEC2だったらSSHで接続して中入るんですよサーバーの場合によってはメンテナンスモードにしますとメンテナンス不要な場合は特にしないですと今回フルでやるとしてメンテナンスにしますかメンテナンスモードにしてまずGitをプルしてきますメインブランチをそのEC2サーバーの中ではい

でコードが最新の状態になったらマイグレーションファイルを実行しますとでマイグレーションファイル実行したらデータベースが更新されますで今回リアクトもセットで使ってるんでリアクトビルドするためにNPMLANビルドとかヤーンとか他のツール使ってるパターンもあるかもしれないんですけどそういったフロントのビルドをしますとであとはキャッシュクリアしますと

キャッシュクリアしたらメンテナンスモード解除しておしまいって感じですねキャッシュクリアは大事なんですねキャッシュクリア大事ですねもししなかったらどうなっちゃうんですか一部古い状態で動こうとしてバグるとかがあり得る特にラベルとかってコンパイル済みのビューとか

あとは設定とかをキャッシュして早く動かすみたいなコマンドあるんですよ本番だとそれを実行してちょっとだけスピード上げるみたいなこともあってそいつらをクリアしないと変な挙動になることがありますねなるほどはいやったほうがいいですねうん

でメンテナンスモード解除したらおしまいって感じかなうんまあだから割とシンプルですよねプルしてデータベース更新してビルドしてキャッシュ消しておしまいうんっていうのをやってたんですよはいただ今回ですねそのやり方としてはいEC2上にDockerで動かすぞって決めたんですようんでなんでそうしたかったかっていうとはいうわあの環境では動いたのにこっちでは動かねえっていうのをなるべくなくしたかったうん

っていうのもあってアプリケーションをDocker使って動かせばいいじゃんってなったんですよまず最初の過ち過ち1過ち1各インスタンスであるいは各環境で別個でDockerをビルドしてしまっていた各環境で各環境EC2の中でDockerが何個も出てきちゃうってことですか

元々どの環境にもDockerは入ってるんですけどDockerで立ち上げるとき今回Docker Composeで動かしてたんでDocker Composeアップとかで動かすじゃないですかそのアップで動かすときに初めてだったらイメージプルしてきてDockerファイルあったらビルドしてってやるじゃないですかっていうのを各環境でやってしまっていたそれは過ち一位これは過ち一位ですねこれ何が問題だったかっていうと

Dockerってさ早いとはいえ最初立ち上げるのめっちゃ時間かかるじゃないですか確かにイメージありますだからデプロイするたびに各環境ですごい時間かかったんですよソースコード変わって新しくビルドしますって言って1回メンテナンスモードに入って5分くらいメンテナンスモードに入った中でもろもろ終えてやっと復帰するみたいなこれいけてないよねっていうまあ確かに

でもそうですねそれは回避する術があるんですねあります知りたいこれを回避するためにまずやったのがそもそもビルドを各環境でやるのをやめてGitHub Actionsでビルドしなきゃいけないんだなってことに気づきましたGitHub ActionsってさDockerコンテナの中では立ち上げてるじゃないですか多分

コンテナを立ち上げてその中でコマンドを実行してるんですよそうなんですねなのでその中でまずイメージをビルドしちゃうんですよ今回だったらECRっていうAWSのコンテナのリポジトリみたいなところに保存したんですけどそこにもうビルド済みのものを置いておきますと各環境ではそれをプルするだけにしたみたいな

はいはいはいなのでそのダウンロードにかかる時間ぐらいしかかからなくなって一気にビルド時間というかメンテナンスに入る時間が数十秒数秒ぐらいにはなったすごいめっちゃ楽しく一旦これがビルドのパイプラインの過ちでしたとECRにイメージを置くことでで各環境で

Docker ComposeアップをするのではなくDocker Composeアップは各環境でやるんだけどDockerファイルのビルドがなくなったって感じだねそれはGitHub Actionsが1回だけやってて1回やればOKそこでビルドしたやつが保存された状態になるからあとはそれをアップするだけみたいな理解しました

理解しました完全に理解しました完全に理解しましたはいいいですねじゃあちょっと説明してもらっていいですかやばいやばいやばいやばい2分の1になった的な感じですかねデブとメインでそうそうビルドの回数も減ったねそれで言うともともと全環境でビルドしてたんですけど今回のパターンだったらじゃあまず

一旦そのパイプラインの全貌を話すとフィーチャーで開発しますと開発が終わったらプッシュしますよねプッシュしたらプルリク作りますプルリク作ると自動テスト走りますとそれがパスするとあと同時に一応エージェントのレビューも挟むようになっているけどそれは消したい重い

重いしよく失敗するコンテキストあふれて失敗するんだよねジェミニCLIがプリリクのレビューとかコーディングエージェントできるようになったよみたいな瞬間に使ったんだけどちょっとあんまりうまくいってないしょっちゅうコメント失敗していつも実行ログのところからしか見れない

さすがにプロリクにコメントで残してほしいんだけど確かに長いコンソールの中からねどこがコメントだって探して見つけるっていうのをやるのがまずしんどくなってきたしそれによってソースコード回収することもそんななかったんであーそうなんだこれをやんなきゃなみたいなのはたまにあるけどあんまりなかったんで消したいうん確かにチッコロがやばいな

で一旦プレリック作るとそれが走りますとそれが通ったら別に通らなくてもマージできるっちゃできるんだけど一旦通ったらマージしますとはいすると今度デブにマージされた時に動くやつがありますよねとうんデブにマージされたらまずコードチェックアウトしますよとはい新しいコードの状態になったらそのデブの中でビルドしますとうん

でビルドされたイメージがECRに保存されますECRに保存されたら次はEC2のコンテナ内にSSH接続してそこで新しいECRにプッシュされたイメージを持ってきてそれでデブの環境を作り変えますよというか新しい状態にしますよとうん

新しいイメージをプルしてきたらその後にさっきのマイグレーションとかキャッシュクリアとかはいはいはいは実行しますはいでそれでやっとデータベースとかキャッシュの状態がちゃんとした状態になってデブ環境が動くようになりましたこれで一旦デブまで完了ですとはいでデブにマージすると自動でデブからプロド

に向けたプルリクを作るようにしててで一旦デブで上がった状態で一回テストしますとこれ動き問題ねえかなってこれだとこの機能でこのサーバーがないから落ちるみたいなのとかは正直これまでの状態をチェックできてない例えばだけどアプリケーションからメール送信する機能が必要だったけどSMTPサーバーが用意されてないとかだとこけるんですようん

なんでそういうのをチェックするために手動で一通り機能をテストしてこれなら問題ないねってなったら最終的にプロドにマージするとでプロドにマージするとプロド側でビルド済みのイメージはもうあってそのイメージテストされてるんでそれを本番環境でプルしてきて同じようにマイグレーションとキャッシュクリアとかやってこれで無事本番環境に運ばれるようになった

っていうのが今回の最終機能ですね最初に話忘れたんですけどここにたどり着く前にもう一個試行錯誤があって前段があるんですねパイプラインから各環境でビルドしてた時代各環境でいろいろコマンド実行するのめんどくさいなってなってビルド用のスクリプトを作ってた時代もあったんですよさっきのキャッシュクリアとかも書かれた

そうそうそうシェルスクリプトも置いておいてそれを起動するだけにしておくみたいなそれを置いておくと一個便利なことがあって必要ないコマンドを実行しなくていいというか必要ないコマンド例えばだけどマイグレーションとかってさデータベースに更新なかったら別に実行しなくていいじゃないですか確かに確かに確かに

っていう時とかにその条件分岐でシェルスクリプト書いておいて別にマイグレーション実行されても何も起きませんでしたで終わるからそんなことしなくてもいいっちゃいいんですけどそういう細かい条件分岐とか挟めるようになるんで場合によってはちょっとデプロイのパターン変わるんだよな

みたいなケースの時はシェルスクリプト用意しておくとちょっと便利かもしれない確かにとは思ったなるほどうんでもちょっとビルドしてそれをプルーするだけになってからはねあんまりまだ必要性感じてないからちょっと一回廃止してますねうんうんうんっていうのが1アプリケーション目の学び1アプリケーション目の学びはいありがとうございますで2アプリケーション目はい

はもうちょいチャレンジングに行こうってなったんですよ うんで僕今までテラフォーム使ってきてないんですけど うんはいはいテラフォームを使おうと おーさすがにはい カーソルが全部書いてくれるだろうっていうはいはいそういうあの甘ったれた気持ちでさすがにテラフォームを使い始めたんですよ はい

次はですねこのテラフォーム周りでパイプラインミスったんですよねテラフォーム周りのパイプラインテラフォーム周りというとちょっとあれでまず今回どういう感じにしようかなと思った時にモノレポでいこうってなったんですよ全部ガチャ全部入ってるリポジトリでフロントもバックエンドもインフラもインフラも入れちゃったんですよこれが終わってました

終わっちゃったんですねこれが終わってましたねまずフロントとバックを一緒にしたのは結果良かったなんで良かったかっていうと今カーソルで結構かけるじゃないですかはい

なんでほぼもうエージェントが書いてる状態なんですけどそうなった時にフロントとバックが同じリポジトリに入ってると一気に開発できるから超楽確かにAAAがちゃんと見てくれてカーソルがちゃんと見てそれを考慮しつつコードを書いてくれるっていうそうそうそうそうだから1機能がもうなんだその1リポで完結するからうん

結構こっちの方が今は人足りてないし楽だなってなってたうん分業もいらないしね今別に一人しかいないからリポジトリ分かれるだけちょっと損なんですよ今確かにで一旦第一プロジェクトの時それでうまくいってたんでじゃあこのノリならテラフォームも混ぜた方が一緒混ぜたんですよ

確かにフロントバックのコードあったらインフラ作ってって言ったらガーっていい感じに書いてくれそうな気もするこれが良くなかったですね大失敗ですか何が起きたかっていうとパイプラインがめっちゃ複雑になってしまったパイプラインが複雑になったテラフォームとかじゃなくてパイプラインが複雑になったパイプラインが複雑になりましたなんでかっていうとGitHub Actionってさ

.github っていうのをルートに作るじゃないですかそこにワークフローディレクトリ切ってどんなパイプラインを動かすかっていう設定ファイルのyaml書いていくと思うんですよこれがね特定のディレクトリを見ないといけなくなったんですよねまずなるほどだから今回の変更でこのディレクトリに変更があったらこのパイプラインを動かすみたいななるほどっていう問題がまず一個起きますとで

それにより設定ファイルが無駄に複雑になるんですよもしかしたら別の解放法あんのかもしれないけど一旦私がやった範囲だとそうなってしまったでさらに問題が同時に動かすのが難しい同時に動かす

例えば今回の機能開発によってAWSのサービスが1個必要になりましたとってなった時にテレフォームのまず変更するじゃないですかでサーバー用意するじゃないですかサーバーというか機能を用意するじゃないですかその上で機能プロダクトのコードも変更するじゃないですか同時に変更があった時どうするんだろうっていう問題が起きてパイプライン動くじゃないですか

じゃないですか動いた時にアプリケーションのコードよりも前にインフラを動かしたいっていう気持ちだったんですけどそういうのがやりにくすぎたなるほど結果的にインフラのコードだけ書き換えて一回プルリクマージした後にアプリケーションのコードは別で書き換えてプルリクマージするみたいなっていう依存関係がねめんどくて順番とかの

なるほどなライフサイクルがちょっと違うというかアプリケーションとインフラだとそれなんかあれなんですかねいくつもデプロイするみたいなイメージだとちょっとお金的にあれなんですかねブランチ分けたりしたら解決しなかったりしません?しないのかなブランチ分けたら

どんな分け方ですかちなみに顧客ごとに分けたらいけるかなと思ったんですけどそういうことじゃないですね大元でそもそもアプリの回収が必要だったりとかするからブランチ分けても結局どのブランチに対してもその変更は適用しなきゃいけなくなっちゃうのかそうそうそうどっちにしろ依存関係が生まれるんですよねそっかダメか

ややこしいですねめんどくさいですねしかも別にインフラとアプリケーションのコードが一緒になったところで恩恵別になかったお互いを見合って同時に変更できて嬉しいみたいな支援が一つもなかったそれもあれなんですか今から分離するのはもう厳しいんですか

いやめんどくさいキャラ厳しくはないディレクトリごと切ってるからまあHitHub Actions調整すれば割と簡単にいけるんだけど2個めんどいのがあって1個はそれをやったからといって別に急にシンプルにはなるんだけどはい

動いてるからいいから気持ちになってもいるできてるし一人ですからねそこに時間を割くより他のあると思いますしもう一個はオーガニゼーションが自社じゃないからもう一個リポジトリ作ってもらうのも依頼費が必要だからちょっと面倒くさいなるほどっていうのが重なった結果今は

一個の中で別のタイミングで動かしてるとうんうんうん感じですねなるほどさらにインフラ環境のミスこれは多分テラフォームを知らなかったことによるミスなんですけど順番的に結構急いでたんで一旦デブ環境できればいいかっていう気持ちでデブ環境を立ち上げるためのテラフォームを書いていったんですよはい

なんかベストプラクティス的なのを見るとテラフォームのディレクトリにはエンバイロメントみたいなのを切ってその中にデブとかプロドとかを切ってデブの中にデブ用のを作れるといいよみたいなそういう感じなんだねってデブの中にデブ用のやつというかコード全部突っ込んで一回作ったんですよでも混ざっちゃってたんですよねグローバルなサービスがグローバルなサービスが混ざっちゃうDNSとか

ルート53みたいなあれはどうしたかったかっていうと一個のホストゾーンホストゾーンってわかる?レコードとかいろいろ書いていく場所なんだけどはいホストのゾーンホストのゾーン歌舞伎町みたいになってるけど大丈夫?大丈夫ですはい一個のホストゾーンに

ひまぷろ.comだったらひまぷろ.comはこのサーバーに向けるよみたいな設定書いていくとかさらにエイリアスつけてデブ-ひまぷろ.comはデブ.ひまぷろ.comはこっちのサーバー向けるよってデブ環境向けるみたいなことをしていくのでデブ専用のことじゃないというかなるほど

そういうグローバルな情報までデブに関係ないプロドまで関係しちゃってるやつとかもそこに書いてしまってたとなんで一回分けたんですよ共通のやつはグローバルに書こうと思ってあとECRもそうだよねさっき言ったコンテナのイメージをストックする場所あれもデブの環境の時にビルドしてプッシュしますと

でそれを一回デブで動かした後に同じイメージをプルしてくるんでデブとプロドが同じ場所を参照するじゃないですかこれもグローバルだなってそれもグローバルに移動したりとかっていうのをやったんですよそしたら今度はもうねアプライができないできないこけまくって特に自動化するとそれがめっちゃめんどくさくて最終的な解決方法としてはですねグローバル系のやつとデブ系のやつは

そもそも動かすタイミング変えようと思ってグローバルに必要なやつは手動で起動するようにしましたね手動で起動して事前に作っておいてデブ環境用の方は自動で動かすようにしたみたいなこうすれば依存関係完全にコントロールできてめっちゃ楽になったっていうそこのシェルスクリプトは組もうとは思ってない思ってないシェルスクリプトでやるといいのか

自分の今の現場のやり方は結構そうなってるかもしれないですねシェルスクリプトの中でAzureにログインするところから始まっていろいろリソースグループどれを使ってとかした後最終的にテラフォームアプライが走るみたいなシェルになってますねそういうことねそうすればいいのかでもちょっとそれだけだと何していいか分かんないな

正直テラフォームの中のコードが何をしてるか分かんないからねそこまでのコントロールできないんだよなまだ一旦バーっと書かせたやつで把握しきれてないってとこですかねそうねそんな感じだわ今ようやくなんか見えてきたけどまだ細かいとこよく分かってないうんとかあれかな書くコードっていうよりもコマンドの方が分かってないかもテラフォームのそうユニットプランアプライじゃん大体の流れはい

それぞれが何の範囲を担当しているかが正直裏側見えてないかも特にユニット確かにどのタイミングでやるべきなのかってちょっと俺も曖昧ですわユニットが何してるかちょっとよく分かってないからなそれが分かればもしかしたらセルフスクリプトかけるかもしれないそんなこんなでテラフォーム部分はまずアプリケーションと一緒にしてしまったっていうのがミスったのとグローバル

書く環境でもまた動くタイミング違うんだなってのに気づいてそこを分けなきゃいけなかったのをミスったポイントだったなっていうのがありましたで今そこはちょっと主導片方主導になっちゃってるけどシェルスクリプト使ったらもしかしたら自動化できるかもって感じですねうんまあというのでなんとかパッチワークを当てまくってズタボロのCICDパイプラインができてて今いやすごいすごいですね

あんまりベストプラクティスとかを調べながらやる時間なかったんで常に困ったところにパッチを当てながらここに行ったんですよなんでもしかしたらねここ変じゃねみたいなのが絶対あるなと思っててそれはちょっとぜひご意見欲しいですねいいですね募集するスラックコミュニティでもそうねぜひお願いしますちなみに最初に言ってたジェミニが出してくれたワークフローはいはい

ちょっと読んでいきますよまず

ワークフローの全体像フィーチャーブランチからちなみにどういう風に投げたかというとさっきのアプリの説明してラベルリアクト使っててドッカー使っててGit運用こういうのですよというのを説明した上でこの条件でGitHub Actionsを使ってCICDを実装する場合に最もベストとされる方法を教えてください特にトリガーとそのトリガーに対して何を実行するかを知りたいですというので投げてますとワークフローの全体像まずCIのフェーズは

フィーチャーブランチからデベロップへのプルリクエスト時に実行しますここでコードの品質を担保するということで動かす内容がソースコードをチェックアウトして環境のセットアップ環境のセットアップは諸々の依存関係のインストールとかそれ系ですね静的解析とリンピングこれやってなかったな

リンキング リントー es リントーとかああはいまあでもこれやってもちょっとあのスピード落ちそうだから今はいいや でテストの実行はいでリアクトのビルドで最後ドッカーイメージのビルドなるほどねプルリクエストの段階でビルドまでやるんですね ドッカーイメージのデベロップブランチへのマージ実行時はい

環境開発への自動デプロイが主な目的になっててそうすることをチェックアウトしますよとでさっきビルドしたイメージを持ってきてそれをサーバーにプッシュしてサーバーでプルするのかなさっきのイメージCIのフェーズでプッシュしたイメージを持ってきますとそのイメージをビルドしてタグを付けますそれを

開発サーバーでデプロイするんで ssh 経由でサーバーにデプロイアート接続してそこでイメージをプルしてきてアップしてマイグレーション実行してキャッシュクリアして うんっていうのをやって終わったら通知を通すのねスラックにあーなるほどね結構大事ですよねこれ大事だなぁ 通知めっちゃ大事ですねこれやってないわで

ラストメインブランチへのマージ時に実行する本番環境のデプロイこれは実行するジョブは同じくDockerイメージのビルドしますよとこれもタグ付けるんだけど今回はリリースのバージョンが分かるようなタグ付けをしますと本番サーバーへのデプロイっていうところでやることはあんま変わんないですねイメージを持ってきて本番最適化用のコマンド

とかを実行して最終的に通知なんでデブとちょっと違うけどほぼ同じだね流れをやることの本質はっていうのをやるといいですよってことで一旦今読んだ学びとしてはビルドはあれなんだねデブのデプロイじゃなくてCIの段階でやるといいんだねっていうのが分かりましたでも

しばらくはやんない気がします修正は時間かかりそうだなというのでここ最近あったパイプライン組むの苦労した本当にあったパイプの話でしたいやーすごいですね実体験をもとにちなみにどのくらいでそこら辺のパイプラインって整備したんですかいやこれはもう長期に渡ってやってるよコツコツと最初のなんだろうヘンテコー

ヘンテコパイプラインでしばらくやってたしねだからなんだ2ヶ月ぐらいでやってるのかなまあそうか必須ですもんね一人のプロダクトなのに作るのすごいなぁとも思いますけど作らない方が相当な手間がかかるんですもんねこれ作らなかったら失敗してるかもしれないねプロダクトがそうねタイミングというかリリースできずに終わってたかもしれないあー

大事だしそうねこの2ヶ月あって7月から始まって一番最初に紹介したヘンテコパイプラインでやってたやつは2ヶ月経ったぐらいさっき言ってた新しく作ってますみたいな方は動き始めてからは1ヶ月ぐらい経ってるんだけど実質の稼働はまだ1週間2週間ぐらいって感じかなそれぐらいの

スケジュール感ではありますねいいですねてかあれだなこんな簡単にジェミニが答え出してくれるならさ聞けばよかったこれ調べてさこれ通り実行しろよっていうねそこは調べてなかったですね中途半端に動かせてしまうからこそねやってしまうミスみたいなやつだよねララベルのデプロイ方法は知ってるわけじゃん

一方それをコンテナのワークロードに置き換えた時にどうなるかが分からなかったゆえのやつだからしかもコンテナ使っても動かすだけなら動くなって頭の中でイメージしちゃってたんだよやった結果問題が紛失しまくってこれは絶対違えってなって今に至るいい学びですね

だって一生忘れないですもんねもう一生忘れないかなわかんないなでも実際に書いてるのはAIだからなまあ確かに気持ちが痛みが少ないんだようんすごいですいいですねというので皆さんもアプリ作るってなってスピードが大事ってなったら今回の学びを参考にして最初から綺麗な

ワークフローを組むといいんじゃないかなって思います綺麗なワークフローを組むとねバイプラインのエラーが少ないしコードも減って楽なんじゃないかなって気がするんだよなやっぱ明らかにコードの量減りましたもん最初と比べてはいということでひまじんプログラマーではハッシュタグひまプロでXでのポストを募集しておりますあなたの実体験本当にあった話

パイプの話いやパイプじゃなくてもいいです本当にあったこんな話日常生活の何でもOKじゃないですか何でもOKかせめて開発にまつわることをぜひ教えてくださいはいお願いしますはいまた番組の説明欄ではお便り募集お便りフォームによってお便りが募集されておりますはいこちらから我々に何か聞きたいこととかもしくはラジオで取り上げてほしい本当にあった

○○の話とかがあったらぜひとも送ってきてください最近お便り少なくて寂しいですからねそうですねまたチャンネル概要欄にはひまじんプログラマープレゼンツオンラインコミュニティひまぷろ談話室の参加リンク申し込み募集フォームが設置されている可能性がございます必ず設置されていますなのでそちらからご応募いただけると

もしかしたらこの番組をより楽しむためのコンテンツとかがそのスラック内によって提供されている可能性がありますのでぜひともご参加くださいお願いします最後に番組のプラットフォームから星をつけていただけると我々すごく励みになるのでぜひよろしくお願いしますお願いしますそんなわけで本日は以上でございますバイバイ日本のエンジニアは使うアプリが多すぎる

事実!ヒマプロの使用アプリ平均数38.6個!レイキャストならアプリの即起動!過去のコピー履歴を引き出せる!ウィンドウのリサイズなどこれ一つで作業効率アップ!しかも料金無料!今すぐレイキャストで検索!