はてなブックマーク

DevOps や Platform Engineering, Developer Productivity など、開発活動の生産性を高める活動や分野を指す言葉が広く謳われるようになってきましたが、その活動を始めようと思っても効果について説明するのは難しいなと感じていました。 そんななか、Google Cloud による The ROI of DevOps Transformation という、DevOps 施策の ROI を計算する方法がいくつか紹介されている記事を見つけました。 この記事の内容がそのまま使えるかと言うと判断に困るのですが、面白かったので 1 つの計算方法として紹介していきたいと思います。 前提 Four Keys について DORA の研究によって、Four Keys 指標は組織のパフォーマンス（収益性、品質、顧客数、満足度など）に相関関係があることが分かっています。 F

GitHub Appsとは何かがよく分からなかったので、実際に作りながら学んでいきます。 GitHub Appsとは 1つめは利用者側から見た概要。２つめは開発者から見た概要です。 GitHub AppsはGitHubの機能を拡張するツール GitHubを操作したり、GitHub外と連携したりできる。例えばissueを開いたり、Slackに通知したり リポジトリにインストールして使用する マーケットプレイスで様々なGitHub Appsが公開されている。リポジトリにインストールするだけで同じ機能が実現できるのが嬉しい。Actionsでそれをしようとするとyamlが個別に必要になる。 パッと見でも、リポジトリ内の画像サイズを最適化してくれるアプリ、静的解析してくれるアプリ、依存関係の古いバージョンを自動で検知して更新PRを出してくれるアプリなど、多種多様。 GitHub Appsはどのように

どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。　go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM

先日、人生で初めて OSS にコントリビュート（貢献）してきました。 自分の実力ではとてもできないだろうと思って手を出そうともしなかったのですが、真面目にコツコツ取り組んでみるとついにはその目標を達成することができました。 かかった期間も一週間以内（ぶっ通しではないので実際の時間はもっと短い）でした。 もちろん優しい issue を対象にしたというのもありますが、一週間なら挑戦してみようかな という前向きな気持ちになれる期間ですよね。OSS にコントリビュートするのに壁を感じる方は多いと思うので、この記事ではそういった壁を取り払うべく、自分が OSS にコントリビュートするまでの道のりを書いていこうと思います。 この記事では、以下の内容を扱います。 OSS コントリビュートへの意欲・背景 OSS にコントリビュートするためにやったこと OSS コントリビュートしてみてどうだったか OSS

Amazon Cognitoを理解したいと思ってログイン画面を実装していると、ログイン成功時に以下の3種類のトークンを返されることに気づいた。 idToken accessToken refreshToken これら3つの使い分けを調べたので、記事に残そうと思う。 idTokenとは idTokenがいわゆる「トークン」であり、認証成功後に使いまわすアレである。 accessTokenとは accessTokenはいまいちピンとこないトークン。 AWSの公式ドキュメントを調べたところ、以下のように書いてあった。 アクセストークンの目的は、ユーザープール内のユーザーのコンテキストでの API 操作を承認することです。例えば、アクセストークンを使用して、ユーザーにユーザー属性を追加、変更、または削除するアクセス権を付与することができます。 アクセストークンの使用 この説明だけを見ていると「アク

GitHub Actions から AWS や GCP などのクラウドリソースを操作するときは、 OIDC を使用することが主流だと思いますが、手順に沿って設定はできるもの仕組みがよく分かっていない方も多いと思います。 この問題は厄介で、様々な"分からない"が絡まりあって生まれている問題だと思います。 例えば、 どんな仕組み・流れでAWS・GCPを操作できるようになっているのか分からない（私） そもそもなぜOIDCを設定すると嬉しいのか分からない（私） 色々な設定をしたけど何をしているのか分からない（私） などが挙げられると思います。 これらを解消し、OIDCを利用したGitHub ActionsとGCPの連携の流れ・仕組みを探求するのがこの記事の目的です。 ※Google CloudのことはGCPと書きます。 ※記事で触れないこと GitHub Actions - Google Clou

DevOpsの考え方として「トランクベース開発」というものを知りました。 自分が知らなかっただけで、考え方としては前から存在していたようですが、今回調べてみてめっちゃ良さそうだなーと思ったので、簡単にまとめたり感想を書いたりしてみました。 関係ないですが、本を読む時間がなかったりつらかったりするときは、 気になるワードで検索し、出てきた記事をひたすら読む それをまとめ、自分なりに噛み砕く というのが良いんじゃないか？と感じ始めてきたこの頃です。 トランクベース開発とは ようは「細かいコミットを頻繁にメインブランチにマージする開発方法」ということ。 昔はSubversionなるバージョン管理アプリが存在し（知らない世界。。）、そこでは trunk という言葉があったみたいです。トランクとはGitでいうmainブランチのことで、そのリポジトリのメインを表す存在だったよう。 トランクベース開発で