https://toruby.connpass.com/event/286678/ の発表資料です。
テストデータを貯めて感じたこと
https://toruby.connpass.com/event/286678/ の発表資料です。
Infrastructure from Code (IfC) ツールまとめ - maybe daily dev notes
昨今Infrastructure from Code (IfC)という概念をよく耳にします。先日もAWSのGregor Hohpeが関連する記事を書いていました。 architectelevator.com この記事では、Infrastructure from Codeとはなにか簡単に紹介し、具体的にどのようなツールがあるか網羅的にまとめます。 Infrastructure from Codeとはなにか Infrastructure from Code (IfC) とは、その名の通り、Infrastructure as Code (IaC) に関連する概念です。IaCとの根本的な違いは、IaCは開発者がインフラを明示的に意識して構成を記述するのに対し、IfCでは開発者がインフラをできるだけ意識しないよう抽象化を試みていることです。これにより、差別化に繋がらない重労働ができる限り排除された高
「入門 継続的デリバリー」は継続的デリバリーを学ぶのに最適な教科書だった. - Lean Baseball
最近読んだ「入門 継続的デリバリー」がとても良かったので紹介しますね, というエントリーです. 入門継続的デリバリー良かったです. 「継続的デリバリー（Continuous Delivery）」とか「DevOps」ってどこから学ぶかわからんな！？ というのは割とあるあるだと思っています, そもそもめちゃくちゃ難しい話なので（ちゃんと学ぼうとすると）. そんな中, 「入門 継続的デリバリー」がよく説明できてて良かったので感想と関連する書籍を紹介できればと思っています. TL;DR 入門 継続的デリバリー 我々はなぜCDをするのか? 具体的なプラクティス 入門後に読むべき良著 Kubernetes CI/CDパイプラインの実装 継続的デリバリー チームトポロジー 結び - 我思うCDとDevOps TL;DR 「入門 継続的デリバリー」は継続的デリバリーの大切さと概念, 手法を現実にありそうな
AWS Security HubとSlackを利用して、セキュリティ状況の監視運用を効率化したお話 - Uzabase for Engineers
はじめに 初めまして！ソーシャル経済メディア「NewsPicks」SREチーム・新卒エンジニアの樋渡です。今回は「AWS Security Hub」と「Slack」を用いて、弊社で利用しているAWSリソースの監視運用を効率化したお話です。 お話の内容 年々増加するサイバー攻撃に対抗するため、セキュリティ対策は日々重要度が増してきています。 そこで弊社で利用しているAWSのリソースに対して、各種セキュリティイベントの収集ができるAWS Security Hubを利用することで、セキュリティ状態の可視化と迅速な対応がしやすい運用を行い、セキュリティ状態の現状把握から始めることにしました。特にNIST CSFの「検知」部分の運用について整備した内容となっています。 NIST Cyber Security Frameworkについて 皆さん、「NIST Cyber Security Framewo
価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization
024年6月28日に開催された 開発生産性Conference 2024 の講演資料です。 講演詳細についてはこちらをご覧ください。 https://dev-productivity-con.findy-code.io/2024
Four Keysを用いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ？」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津（@KawatsuYusuke）です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。 と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ？" が大事」についてお伝えします。 私たちの開発生産性向上のはじまりと、目指すべき状態の設定 Four
Terraformのフォークが「OpenTofu」としてLinux Foundation傘下で正式ローンチ。OpenTFから改名
Linux Foundationは、HashiCorpのインフラ構成ツールであるTerraformをフォークしたプロジェクト「OpenTofu」のローンチを発表しました。 We are excited to announce the launch of OpenTofu, an open source alternative to Terraform's widely used infrastructure as code provisioning tool. Read the announcement:https://t.co/Ju0d6Fq190#opensource #opentofu #ossummit pic.twitter.com/gQLGO7iAdu — The Linux Foundation (@linuxfoundation) September 20, 2023 Op
QAエンジニアがいない会社に入社してやったこと、まだやれてないこと - TalentX Tech Blog
はじめまして。2023年2月に入社したQAエンジニアの大出です。 前職はフリマアプリを開発する会社で約8年QAエンジニアとして働いていて、TalentXで初めてtoBのサービスのQA業務を行うことになりました。 入社前の状況 やったこと 新規開発の検証 テストプロセス改善 テスト計画の作成 ドキュメントの整理 バグチケットの整理 ドッグフーディング 採用 まだやれてないこと 終わりに TalentXは2015年にMyReferというサービスをリリースして以来、2023年2月に自分が入社するまで社内にソフトウェアテストを専門に行うメンバーは在籍しておらず、開発エンジニアが自分達で全てテストを行っていました。 そういう状況で私が入社してから約1年間でやってきたことを振り返りたいと思います。 TalentXの開発に興味がある人や、ソフトウェアテストを専門に行うメンバーが居ない会社でこれからQAエ
入門 継続的デリバリー
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要？ 1.2 なぜ継続的デリバリー？ 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか？ 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー
プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか | Google Cloud 公式ブログ
Darren EvansEMEA Practice Solutions Lead, Application Platform ※この投稿は米国時間 2024 年 5 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。 なぜ新しいトピックに対して否定的になってしまう人がいるのか、その理由は、群盲象を評すの寓話からわかります。その人自身の視点からのみで物事を見てしまうと、その全体像を見失ってしまうということです。プラットフォーム エンジニアリングはソフトウェア デリバリーの比較的新しい手法です。現在、IT 組織やソフトウェア エンジニアのチームの多くがプラットフォーム エンジニアリングについて検討している段階にあるのですが、プラットフォーム エンジニアリングとは何なのか、プラットフォーム エンジニアリングで何ができるのか、プラットフォーム エンジニアリングを導入す
「システム運用の基本と戦略」についてただまとめる
23卒でバックエンドエンジニアをしているたかしゅんです。（@1341Shun） 先日、株式会社サイバーエージェントAI事業本部の2024年度 エンジニア新卒研修でシステム運用に関する講義を行いました。 そこで話した内容とスライドを完全公開したので、内容について解説します。 90分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 実際の資料はこちらになります↓ 自己紹介 こんにちは、たかしゅんと言います。2023年度入社で今年で２年目になります。株式会社サイバーエージェントのAIオペレーション室で新規立ち上げをやっております。 入社して最初に広告プロダクトに配属し、PipeCDの導入などのDevOps業務を中心に行なっておりました。 記事もあるのでもしよろしければ、ご覧ください。 2月中旬からAIオペレーション室に移動し、新規立ち上げのインフラ環境の構築からCI
Terraform のコーディングにおいて、似た構成の複製をどのように表現するかは結構重要な課題です。放っておくと汚いコピペだらけになっていくからです。 色々な目的とやり方があると思いますので、その表現を実現するためのパーツにでもなればと思い、学習用教材的に書いてみるやつでございます。 目次 説明はそんなに多くないですが、コードのせいで縦長になったので目次を置いておきます。Terraform バージョンは v1.5.7 で動作確認しています。 単体の複製 count for_each セットの複製 module count + module 条件分岐 三項演算子 入れ子 ループ構造 for 複製の方法 階層構造 Pythonの入れ子ループ Terraform の入れ子ループ 続・階層構造 単体の複製 あるリソースに対して、単体の場合は count や for_each を使うことで、lis
先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン
TerraformのStateやModuleに関する設計 - tom-256.log
概要 名前付け 抽象度 インフラアーキテクチャ図 チーム 認証情報 変更(デプロイ)のライフサイクル DRYの誤用 コードの検索性 モジュール間の依存 アプリケーションレイヤーとの違い まとめ 概要 TerraformのStateやModuleに関する設計に関する考慮点をざっくり書く 名前付け ユビキタス言語とディレクトリ名や変数名を合わせて認知不可を下げる リソース名でなく役割・機能ベースのディレクトリ名にして認知不可を下げる プロダクトのコードネームはユビキタス言語なのでディレクトリ名にしても問題ない ModuleやStateのREADME.mdを書く https://github.com/terraform-docs/terraform-docs を使う うまく説明が書けない場合は設計に問題がある可能性がある チームメンバーが利用できるように考慮する いつどのようなときに使えばいいか
オンラインGitリポジトリを提供するGitLabが自社の売却に向けて投資銀行と協議しており、同業他社であるDatadogが買収の関心を示しているとロイターが報じました。 Exclusive: Google-backed software developer GitLab explores sale, sources say | Reuters https://www.reuters.com/markets/deals/google-backed-software-developer-gitlab-explores-sale-sources-say-2024-07-17/ GitLab Stock: Software Maker Seen Exploring Sale. Datadog Among Suitors? | Investor's Business Daily https://ww
「DevOps」とは？〜超基本から実践のポイントを解説〜|インシデント管理プラットフォーム│PagerDuty
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
Best practices for using the Terraform AWS Provider - AWS Prescriptive Guidance
Michael Begin, Senior DevOps Consultant, Amazon Web Services (AWS) May 2024 (document history) Managing infrastructure as code (IaC) with Terraform on AWS offers important benefits such as improved consistency, security, and agility. However, as your Terraform configuration grows in size and complexity, it becomes critical to follow best practices to avoid pitfalls. This guide provides recommended
フィーチャーチームの導入と新しいエンジニアリングマネジメントでChatworkが挑戦する、一貫したオーナーシップとDevOpsの実現 - はてなニュース
リリースから12年を迎えた「Chatwork」は、国内ビジネスチャットのフロントランナーとして、中小企業を中心に41万社以上の企業・組織に利用されています（2023年6月時点）。DAU（デイリーアクティブユーザー）も100万を超えるため（108.6万、2023年6月時点）、ビジネスタイムには絶えず飛び交う大量のメッセージをサービスとして安定して処理することが求められます。 一方で、長期間の開発によって蓄積した技術的負債等に対応するため、システムのアーキテクチャを見直す時期にもあります。それにあわせて開発組織も、巨大なモノリスに対して案件ごとにプロジェクトを組み直す既存の体制から、職能を横断したチームが自律して開発を推進できるフィーチャーチームへの移行がまさに進行しています。 こうした開発改善の実情と進め方について、本部長として推進する田中佑樹さん、エンジニアとしてフィーチャーチームに所属す
先週、エーピーコミュケーションズによるプラットフォームエンジニアリングについての勉強会に参加したのだが、全然理解できなかった。理解した前提のレポート記事は無理なので、せめて解説のどこで詰まって、なにがわからなかったのかくらいは理解しておきたい。勉強会の模様を追いながら、自身の思考を追いかけていくことにする。 とにかくグローバルでは注目が集まっているらしい 勉強会を行なったエーピーコミュニケーションズ（以下、APC）はNeoSIerを標榜するエンジニア集団。2023年1月現在で社員は430名で、AWSやAzureの有資格者が各100名以上在籍している。DockerEnterpriseを買収したミランティスとJVを設立したり、最近話題になったネットワーク機器のカプセルトイ（関連記事：「手のひらネットワーク機器」のサンプル入手！ 企画元にも開発秘話を聞いた）を手がけたり、ユニークな取り組みを行な
HashiCorpの創業者の一人であるミッチェル・ハシモト氏が先月（2023年12月）中旬、HashiCorpを去ることを明らかにしました。 ハシモト氏は2012年の同社創業から2016年まで同社CEOを務め、その後2021年までCTOを務めた後にフルタイム開発者として社員の立場で仕事をしていました。 After more than 11 years, I've decided to move on from HashiCorp. HashiCorp achieved more than my wildest dreams and I'm proud of the role I played. While this has been long planned, its still an emotional day. Here is the letter I shared with empl
【開催報告】プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 | Amazon Web Services
Amazon Web Services ブログ 【開催報告】プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2024 年 2 月 29 日に AWS オンラインセミナー「プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜」を開催しました。 本イベントは、プラットフォームエンジニアリングの基本的な概要と現状について解説した上で、SRE や DevOps との関連性、どんな課題をどう解決するのか、実装するとなれば、AWS でどう実現するのかといった点についてご紹介させていただきました。400 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！ アジェンダ AWS メンバーから、プラット
はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
『Lean と DevOps の科学』って教養ないと理解できないじゃん！っていう話 - Qiita
今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか？ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。 本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。 目次 初めに GW中に読も
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました | CyberAgent Developers Blog
AWS CodeBuildのGitHub Actions runnerサポートでLambdaが実行できるようになったので検証しました CTO統括室の黒崎(@kuro_m88)です。本日早朝に面白そうな発表を目にしました👀 AWS CodeBuild now supports managed GitHub Action runners AWS CodebuildがGitHub Actionsに対応したという内容ですが、要するにAWSがホストするGitHub Actions Runnerが出たということですね🎉 AWSがマネージしてくれることで、EC2(x64, arm)はもちろん、GPUとカスタムイメージも利用できるようです。 さらに注目したのはGitHub Actions RunnerとしてAWS Lambdaが使えるようです。Lambdaが使えると嬉しいポイントはActionsのjo
SRE NEXT 2024のLT発表資料です。 https://sre-next.dev/2024/schedule/#jp026 登壇者 ニフティ株式会社 島 翔平 (@glass_sms: https://twitter.com/glass_sms)
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
CyberAgent AI事業本部新卒研修「MLOps」の資料を公開します | CyberAgent Developers Blog
はじめに 近年、様々な分野で機械学習の利用が進む中、モデルの品質を担保し、継続的な学習を行うための施策が重要視されています。そのため、機械学習のためのDevOpsであるMLOpsの必要性が高まっており、AI事業本部でも研修内容に取り入れています。 より良いMLOpsを構築するためには、アプリケーションやインフラの知識も必要です。そのため、今年は昨年までと異なり、MLエンジニアだけでなくソフトウェアエンジニアも講義に参加しました。また、新たに実践編が加わり、より業務を意識した講義が追加されました。 Container編 基礎編 応用編 実践編 そこで、今回は研修で行われた各講義の資料を公開したいと思います。 Container編 Container編では、コンテナにまつわる技術に対しインデックスを張ることと、イメージ作成や運用時のTipsを学び実業務に役立てることを目的としています。 そのた
入門EOL対応
入門EOL対応 ~SREが鉄板の流れ全部見せます編~ https://fortee.jp/yapc-hiroshima-2024/proposal/8b778ed2-df11-4bee-a4b7-81e2b85b51c4 ソフトウェアは進化する一方で、全てのバージョンをサポートし保守し続けるのはリソースを効果的に割り当てる観点から現実的ではありません。 セキュリティリスクや管理コストを考慮し、サポート終了期間を設けるEOLを用いた運用が一般的に採用されています。 サービスを運営する中で、EOLに対して時間に余裕を持って対応できればよいですが機能開発が優先されることでリソース不足となってしまうなどでソフトウェアのEOL対応に対して後手に回ってしまうという課題がありました。 このセッションでは、GMOペパボのSREがソフトウェアのEOL対応をベースとした、ソフトウェアをただアップデートするだけ
よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。 出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニア
デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが） - mtx2s’s blog
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment（DORA）が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した（後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である）。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されたのでサマってみた
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all
「GitHub CI/CD実践ガイド」を読んで、GitHub Actionsを始めよう - とことんDevOps | 日本仮想化技術のDevOps技術情報メディア
弊社ではGitHub Actionsの登場以前からCI/CDを行っていることもあり、CI環境としてはCircleCIが標準となっています。とはいえ開発の中心はやはりGitHubであり、GitHub上で自己完結できるという点において、GitHub Actionsの優位性は見逃せません。 今まで筆者は「CircleCIでやってたこの機能は、GitHub Actionsではどうやるんだろう?」といった視点で、都度検索することが多かったのですが、そういうやり方では知識が横方向に広がらないのですよね。もしかしたらもっと便利な機能があったり、やってはいけないアンチパターンがあるかもしれないのに、ピンポイントに検索していると、そういう気づきが得にくいのです。 なので場当たり的にググるのではなく、どのような技術であっても、一度は体系的に学んでおく必要があるというのが筆者の考え方です。そんな用途にぴったりな
ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products
３年ほど前に登場した比較的新しいサービスであるApp Runnerを商用環境で導入した事例を紹介します。 インフラの運用の手間を軽量化できる一方で、利用して初めて気づく課題もありました。 本日は実際の導入事例に基づいて、ECS Fargateとの比較、CI/CD・監視の工夫から障害発生時の運用方法といった生の体験を紹介することで、これから導入を考えている方へ向けて、技術選定のポイントとなる"肌感"を共有できればと思います。 登壇アーカイブ：https://www.youtube.com/watch?v=YiE3n06tfCA
『詳解 Terraform 第3版』を翻訳しました 2023-11-21 『詳解 Terraform 第3版』という本が本日2023年11月21日、オライリー・ジャパンから出版されました。米O’Reillyから出版されている『Terraform: Up and Running, 3rd edition』を私が日本語訳したものです。この本は原著の初版が出版された頃からぜひ自分で翻訳したいと思っていたので、やっとここに至れて個人的にとても嬉しいです。 目次（詳細はオライリーのページへ） 第1章 なぜTerraformを使うのか 第2章 Terraformをはじめよう 第3章 Terraformステートを管理する 第4章 モジュールで再利用可能なインフラを作る 第5章 Terraformを使うためのヒントとコツ: ループ、条件分岐、デプロイ、その他のつまずきポイント 第6章 シークレットを管理す
AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり - Kengo's blog
Accelerate 第1版（以下単にAccelerateと呼ぶ）はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。 端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を
2023 年版の State of DevOps Report が公開されました。 State of DevOps Report とは Google の DevOps Research and Assessment（DORA）チームが毎年公開している DevOps や開発生産性にまつわる年次レポートです。 本記事で、今年のレポートの概要を簡単に見ていきたいと思います。 主な調査結果 Goodhart の法則を理解し、パフォーマンス向上の落とし穴を避ける 開発組織のパフォーマンスを評価する際、メトリクスの設定や評価の方法には注意が必要であり、特に「Goodhartの法則」という考え方を知っておくことが大切であると述べられています。 Goodhartの法則とは、簡単に言うと「測定が目標となると、それは良い測定基準でなくなる」という法則です。 この法則を踏まえた、パフォーマンスの評価や向上のため
Terraform（AWS）の構成を公開します
はじめに アプリボット SREチームの一条です。 弊社ではAWSやGCPの構築にTerraformを利用しています。 IaC（Infrastructure as Code）には欠かせないTerraformですが、長らく運用していく中で様々な課題に直面し、その度に構成や運用ルールを更新していきました。 しかし、まだ完璧な構成ではないと思っています。 なぜなら、会社・プロジェクト独自の事情もありますが、他社の事例を参考にしても運用方法は様々で、これといった正解がないと感じているからです。 今回は弊社のAWSにおけるTerraformの構成を公開しますので、事例の一つとして参考にしていただければと思います。 また、事例を世の中に増やすために、この記事を読んでくださった皆様も、構成や運用ルールを公開・共有していただけますと幸いです。 構成紹介 前提 弊社では1プロジェクトに対して、1~N個のAWS
HashiCorpのインフラ構成ツールであるTerraformをフォークしたオープンソースのプロジェクト「OpenTofu」が初めて正式版としてリリースされました。 The OpenTofu community is excited to announce the general availability of OpenTofu, the open source fork of Terraform, now a production-ready project under the Linux Foundation. Read the full announcement: https://t.co/KhJXz1Ge14#opensource #opentofu pic.twitter.com/miN1gj2ByE — The Linux Foundation (@linuxfoundatio
技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraformのループ記法を基礎から学ぶ | 外道父の匠
Four Keys にはどうやら2つの意味があるらしい - bonotakeの日記
GitLabが自社の売却を検討中との報道、買収候補に競合企業のDatadogやGoogle親会社のAlphabetなど
プラットフォームエンジニアリングがわからない
ミッチェル・ハシモト氏、HashiCorpを去る。「新しい分野に踏み出す準備ができた」
なれる!SRE - Becoming SREで学んだこと - じゃあ、おうちで学べる
GitHub Actionsにおける脅威と対策まとめ
FourKeysを導入したが生産性向上には至らなかった理由
野良社内ツールと開発生産性、プラットフォーム・エンジニアリング - Runner in the High
『詳解 Terraform 第3版』を翻訳しました
State of DevOps Report 2023 のまとめ
Terraformをフォークした「OpenTofu 1.6」、早くも正式版が登場
生産性指標をFour Keysから変更した話 - Sansan Tech Blog