fujiwara.bsky.social 2025/7

ECS Blue/Green deploymentに対応したecspressoのnightlyを出しておいたので試して貰えると嬉しいです github.com/kayac/ecspre...

昨夜Claude Codeにやらせてたecspresso rollbackの改善、素面でよくコードを見たら作りからして全然良くなかったので自分で全部書き直してcommit messageだけ書いてもらった。うーむ

strategy=ROLLINGだと普通にロールバック成功するぽいからBLEU_GREENの時だけの問題か、仕事ならサポートに問い合わせるんだけど今の個人アカウントでビジネスサポートに入るのはさすがにあれ

これだよなあ。狙ったdeploymentをstopさせることでロールバックが成功しそうなものなんだけど dev.classmethod.jp/articles/ama...

ECSのイベントログのこれはわかる「deployment failed: rolling back due to user action (stop-service-deployment).」rollbackをリクエストした結果デプロイが失敗した、のは分かるが「ロールバックが失敗とは何を指してるんだ」

ecspresso rollbackを新しいdeploymentsの仕組みに対応させている。in progressなdeploymentがあればそれをStopDeploymentする(マネコンでロールバックを押した時と一緒?)んだけど、そうすると「ロールバックに失敗」になるのがよくわからん…マネコンいわく「状況の理由 ロールバックを実行するロールバック候補が見つかりません。」

速いわけがない

return nil, nil はやめようね、みたいな指摘を毎回diff見ながらしていて完全にジュニアに指導している気持ちになるんだよな

わかりきっているコードベースでやると、いちいちジュニアエンジニアとペアプロしながら書いていく感覚なので、速くなるわけはない。が土地勘がないところでの速はだいぶ変わるんじゃないかなという印象

熟練のOSS開発者だとLLMに任せる方が遅いみたいな話あったけど、それはそうで把握しきっているコードなら自分で書いた方が速い。でもLLMに書かせて調整する方が消耗が少ない作業は結構あるからなあ

マネコンではdeployが終わってるのにCLI/SDKのServiceStableは無駄に待たされるの、ちょっと納得いかないんだけどAPI互換を考えると仕方ないかも知らん。しかし手に馴染むツールを作るという立場からするとこの手触りを常に追えないのは明らかによろしくないな

生活に密着したツールの作者はその上で生活していたほうが絶対に良いので、おそらくecspressoは早晩誰かにメンテを引き継ぐ方が幸せになるんだろうけど、やりたい人いるかね

あーこのまえPRもらった ecspresso deploy --wait-until=deployed、理由が分かってきた。去年末ぐらいからdeploymentの概念が独立してて新しいdeploymentが完了したらマネコンは完了って言うのに、SDKのserviceStableは古いdeploymentの完了を待つ(ので遅い)。これは毎日生活してないと気が付きにくいなあ…

久しぶりにecspressoを弄ってるけどtf+jsonnetで書いたtfstate参照ありの定義ファイルもclaude codeは普通に真似していい感じにしてくれるな。これぐらいはやるか

いつぶりか覚えてないくらい久しぶりの自宅花金

2週連続イベントの週末で全然ゆっくりできなかったので3連休はありがたい。が設計ナイトの資料はここで作らないとな…

今日のチョコサプ ガンダム(ハイパーハンマー)

社内Slackで「爆破解体」と言い続けて絵文字も用意したらだんだん浸透してきた気がするぞ

"Amazon ECS enables built-in blue/green deployments - AWS"

"Accelerate safe software releases with new built-in blue/green deployments in Amazon ECS | Amazon Web Services"