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
Four Keys にはどうやら2つの意味があるらしい - bonotakeの日記
先日、スクラムフェス福岡でこういう話をしてきました。 speakerdeck.com 特に国内ではここ1, 2年界隈を騒がせている "Four Keys" と呼ばれる4つの指標についての話で、乱暴に内容を一言でまとめるなら、「Four Keysをちゃんと使いたかったらまず出典の本を読もうぜ」というものでした。 元々、Four Keysとか、それを包含する「開発生産性」と呼ばれる分野の世間での使われ方に妙な違和感をずっと感じていたのでこういう話をしに行ったのですが、講演後に現地で議論したりとか、あとこの資料を公開した後の反響を見たりしていて、1つ気づいたことがありました。 それは、世の中でいう "Four Keys" に実は2つの意味があって、その2つがひたすら混同され続けているのでは ということでした。 その2つというのはこれ↓です。 デリバリのパフォーマンスを測る指標 組織のパフォーマン
Broken Ownership
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
Feature Flagsのベストプラクティス（機能トグル）｜Harness正規販売代理店（株）Digital Stacks
実運用でのテスト、トランクベースの開発、デフォルトでのフィーチャーフラグの使用 - これらは全て、フィーチャーフラグのベストプラクティスです。今すぐ詳細を学び、あなたのフィーチャーフラグ体験を可能な限り有益なものにしましょう！ これまでにも、「意外と知らないフィーチャーフラグの5つの活用例」「フィーチャーフラグを使った本番環境でのテスト」「Progressive Delivery。 Canariesとフィーチャーフラグ 」など、フィーチャーフラグについて多くの記事を書いてきました。 しかし今日は、チームが成熟し、フィーチャーフラグを立てることが標準になってきたときに、よりよい結果を得られるよう、より高度なフィーチャーフラグのベストプラクティスを提供するために時間をとりたいと思います。 これらのヒントは、ソフトウェアチームが、機能トグルの実装、機能テストの拡張、アクセス制御のためのシステム動
devops - Pete HodgsonさんのFeature-togglesが面白かったので翻訳してみた - Qiita
Feature Toggles Pete HodgsonさんというThoughtWorksの方が書かれたFeature Togglesという記事が面白かったので翻訳してみました。 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016の記事で取り上げていただいた通り、マイクロソフトの内部の開発では多くのフィーチャートグルが使われています。このことをより深く理解したいと思って個人的に翻訳したものを公開します。私的な自分が理解する用の翻訳でありますので、その辺はご考慮いただければと思います。Pull Requestは歓迎いたします！ 概要 フィーチャートグルズ(Feature Toggles)は、とてもパワフルなテクニックだ。チームがコードを変更することな
[DevOpsプラットフォームの取り組み #4] CUE言語の紹介 - NTT Communications Engineers' Blog
はじめに DevOpsプラットフォームの取り組みを紹介する4回目の記事です。 Qmonus Value Streamの開発チームの會澤です。 連載4回目では、Qmonus Value Streamの重要な構成要素であるCUE言語についてご紹介します。 前回の記事では、Infrastructuer as Code (以下IaC)の課題と、Cloud Native AdapterというQmonus Value Streamチームの独自技術について解説しました。 Cloud Native Adapterは、「インフラストラクチャの構成」と「ワークフロー」をCUE言語を使って宣言します。 CUE言語は、複雑なシステム構成をスケーラブルに管理できることから、近年注目を集めているデータ記述言語です。 前回の記事でご紹介したとおり、KubeVelaやDaggerなど最近リリースされたIaCソリューション
![[DevOpsプラットフォームの取り組み #4] CUE言語の紹介 - NTT Communications Engineers' Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/aa86d9ff6e0194620b0a9a7b3d4526c76487bbd4/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FN%2FNTTCom%2F20220802%2F20220802094547.png)
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SadServers - Linux & DevOps Troubleshooting Interviews
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
<!-- "> '> --><title>