toenobuのブックマーク / 2022年12月20日

toenobu id:toenobu

2022年12月20日のブックマーク (5件)

開発フローでちょっと便利なツールをCloudflare Workersで作る - STORES Product Blog
STORES 予約でエンジニアリングマネージャーをしています、ykpythemindです。この記事は STORES Advent Calendar 2022 の20日目です。 STORES 予約では以前ご紹介した、細かくPull Requestを積み重ねてデプロイをしていく戦略で開発をしています。今回はCloudflare Workers を用いて私達の開発を少し改善にした方法をご紹介します。今回つくったもの以前の記事にあるように私達はPull Requestをマージした後、Slack上のデプロイ専用のチャンネルでスラッシュコマンドを打つことでデプロイを発火しています。デプロイしている図 Pull RequestのAuthorがマージをし、その人がデプロイするフローにしています。しかし、マージしたあと本人がデプロイを忘れることがあるスラッシュコマンドだけ見てもこの後なにの
toenobu 2022/12/20
リンク
社内向けテスト設計プロセスを作ってみた - Commune Engineer Blog
QAの須賀(@kawabeaver)です。先日QA Test Talk Vol.2で「自分たちのテスト設計プロセスを作ろう」というタイトルで、テスト設計プロセスを作る思考過程について発表させていただきました。（発表資料はこちら）外部イベントで発表するのは初だったので緊張して「出社推奨日」がうまく言えませんでしたが、楽しい時間を過ごせました。さて、本記事では、上記発表で少し紹介したテスト設計プロセスについて説明したいと思います。テスト設計のやり方に悩んでいる方、他の人のテスト設計を教える立場の方などのお役になれば幸いです。テスト設計とは何かテスト設計はなぜ必要かテスト設計プロセスをなぜ作ったかテスト設計プロセス作成のゴールテスト設計プロセスの内容テスト対象を洗い出すテスト対象について、テスト条件に関する情報を洗い出すテストすべきテスト観点を洗い出す各テスト観点に対し
toenobu 2022/12/20
リンク
IAMユーザーにAssumeRoleの権限が無くてもスイッチロールできる（ように見える）のはなぜですか？ | DevelopersIO
困っていた内容スイッチロールの信頼関係設定における AssumeRole権限について質問します。自アカウントのIAMユーザーに、自アカウントのIAMロールにスイッチできるよう設定を行っています。ロールの信頼関係を次のようにアカウント（ root = アカウント自体の意味になります）で指定した場合、ユーザーに「sts:AssumeRole」のアクセス権限が必要だと認識しています。 arn:aws:iam::XXXXXXXXXXXX:root 一方で、ロールの信頼関係を次のようにユーザー名で指定すると、ユーザーに「sts:AssumeRole」のアクセス権限が無くてもスイッチロールできてしまいます。 arn:aws:iam::XXXXXXXXXXXX:user/username このような振る舞いの違いが起きるのはどうしてでしょうか？ユーザー名で指定する方法でスイッチロールする場合、
toenobu 2022/12/20
リンク
[仕様変更] IAM ロール信頼ポリシーの挙動が変更になり IAM ロールの「暗黙的な自己信頼」がなくなりました | DevelopersIO
（※）2022年6月30以降に「暗黙的な自己信頼」の使用実績があるロールでは、2023年2月15日まで「許可」個人的にちょっと勘違いしていたのは#4,#16のケースで、「同一アカウント」かつ「ユーザー/ロール単位で信頼している」場合にはプリンシパル側の IAM ポリシーでの許可はいらない、という点でした。ちょっと試してみた上記のパターンからいくつかピックアップして試してみます。同一アカウントで信頼ポリシーだけで許可されているパターン #4,#5に該当するパターンです。 IAMUser0 に IAM ポリシーがアタッチされていない状態で、IAMRoleA を Assume Role します。まずは IAMRoleA の信頼ポリシーが以下の場合です。（#4） IAMRoleAの信頼ポリシー { "Version": "2012-10-17", "Statement": [ { "Ef
toenobu 2022/12/20
リンク
GitLab　GCPに　移行した（中編） - pixiv inside
こんにちは、インフラ部の id:sue445 です。前回に引き続きGitLabのGCP移行について紹介します。前編の記事はこちらになります inside.pixiv.blog 今回の目次今回の目次やったこと2: 実際にGCPに構築した GitLab構築に関係するリポジトリの構成 gcp-gitlab-terraform gcp-gitlab-playbook gcp-gitlab-helm 備考全体の構成図 webservice (GitLab 本体) GitLab CI 3rd party製のDockerイメージから公式のDockerイメージに移行した Docker Swarmは継続利用 GitLabを複数ゾーンで動かすための準備だけしたやりたかった構成現在の構成 Cloud IAPとTunneling SSH Connectionsを利用したgitアクセス Tunnelin
toenobu 2022/12/20
リンク
- 2022年12月21日
- 2022年12月20日
- 2022年12月19日