State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく

このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 （品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。） --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル

大分周回遅れなのだけれども、最近読んでいる「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」がめっぽう面白い。なお以下にKindle本へのリンクを示すが、私はここに書いた手法で定額制の範囲内で読んでる。 Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations 作者: N

ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究

この記事は、SRE Advent Calendar 2018 - Qiitaの24日目として投稿しています。 SRE風のインフラエンジニア SREとDevOps そもそもDevOpsとは SRE本でも取り上げられている、DevとOpsの目的の差異 ミクロなDevの目的 ミクロなOpsの目的 Ops側の視点での安定性の考え方を改める システムを高速に更新可能にしておくことで安定性を担保する インフラエンジニアではなくSREとしてどう高速リリースを実現するか プロダクトの高速リリースに効くところを見極める リリースするにあたっての心配事を潰す 開発チームが自律して動ける仕組みやツールを提供する 今の組織でやれていること 開発チーム出身の人がSREチームにジョインしてくれている SREチームに入る新人のエンジニアさんもRails研修などを通して最低限の開発力を持っている SREチームのケツを叩い

2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供 3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメイ ンモデリングなどが専門領域 https://www.attractor.co.jp/ 4. 今日の話はこちらです ✤ Effective DevOps 4本柱による持続可能な組織文化の育て方 ✤ 3/24 発売 ✤ オライリー 3,888円 ✤ ぜひよろしくお願いします!! ✤ http://bit.ly/EffectiveDevOps

1. DevOps for Business 2017/6/6 株式会社アトラクタ 取締役最高技術責任者/アジャイルコーチ 吉羽龍太郎 2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ 野村総合研究所、Amazon Web Servicesなどを経て創業 ✤ アジャイル開発/改善/自動化/クラウド関連のコンサルティングとトレーニングを提供 3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / 改善 / 自動化 / チーム育成 / クラウドコンピューティング / ド メインモデリングなどが専門領域 https://www.attractor.co.jp/

2016年5月24日に行われたJava Day Tokyo 2016における講演「Javaエンジニアのための"クラウド時代の過ごし方"」の資料です

Q: “Is the latest version deployed?” A: “I deployed animated gif support to production.” Q: “So animated gif support is released?” A: “The animated gif release is deployed.” Q: “…” I’ve worked at many companies where “deploy”, “deployment”, “ship”, and “release” are used loosely, even interchangeably. As an industry, we haven’t done a great job of standardizing our use of these terms, even though

みなさん、デプロイしてますか！！ ロールバック失敗してないですか！！ ロールバックが失敗したとき冷や汗かきますよね。 さて、何気なくしているサーバーに対する新バージョンのアプリデプロイ。 どんな方法があるのでしょうか。 簡単にですが利用したことがある方法をまとめてみました。 サービス停止＆デプロイ 最もシンプルですが駄目な奴です。 サービスを停止させないとデプロイできない悲しい方法。 アプリに必要なファイルを上書きしていたり配置している瞬間はサーバーが動作しないためです。 シンボリックリンク・デプロイ CapistranoやFabricが有名かと思いますが、各サーバーに新しいアプリを配置してから一気にシンボリックリンクを書き換えていき、新しいアプリに向けさせる方法です。 ロールバックする場合は以前のシンボリックリンクに戻します。 たまにロールバックに失敗して悲しいことになることも。 Rai

AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This

前置き AWS LambdaはEC2インスタンス無しでイベント駆動で必要な時に必要なだけコードを実行でき、課金も立ち上げているだけで料金がかかるEC2とは違い、完全なる使った分だけ課金という非常に強力で魅力的なサービスです。 しかし、このサービスはその軽量でシンプルなコンセプトとは裏腹に従来無かった独自の概念が多いためか、面倒なことや悩ましいことが多いと感じています。 だからこそ、もっと簡単かつ実用的に使いたいという想いからLamveryというツールを作っている訳なのですが、その中でも実用面で大きな課題となると感じていたデプロイの部分において、現時点で自分の中でのベストプラクティスと言って差し支えないフローを組むことができたので紹介したいと思います。 Lambda functionのdeployにおける３つの課題 ①デプロイパッケージの作成 Node.js npm installしてnod

サービス開発の現場を語る！ #chibadan の発表資料です http://chibadan.connpass.com/event/41625/

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

ブログからの引用です。ブログはこちら 今回はアーキテクチャパターンとかリファクタリングで有名なMartin Fowler氏のブログであげられていた "InfrastructureAsCode"(原文はこちらを勝手に解釈して意訳してみましたという内容です。 意訳 感想 さっそくいきましょう。 インフラストラクチャーアズコードというのはコンピューティングやネットワークをソフトウェアシステム同じように扱えるようにソースコードを通じて定義するアプローチである。こうしたコードは可監査性やビルドの再現可能性を実現するために管理され、テストの方法や、継続的デリバリーの実現のやり方に依存する。これはクラウドコンピューティングプラットフォームを扱う方法としてここ数十年行われてきた方法だし、これからのコンピューティングインフラストラクチャーを扱う主要な方法である。 私(Fowler氏)は、鉄器時代に育って、当

Tech-Circle #12 Terraform Handson での LT 発表資料です http://techcircle.connpass.com/event/25496/

AWSの利用で以下の課題はありませんか？ ・多数のAWSアカウントがあり管理が難しい ・セキュリティ標準がなく設定者により差異がでる ・セキュリティ監査工数が膨大になる これらの対策として ・多数のAWSアカウント管理を効率化した方法 ・AWS利用のセキュリティ標準策定や監査の自動化 などをご紹介した資料になります。

インフラチームエンジニアの藤田 (@dtan4) です。Terraform でインフラをコードで管理するようになって1年が経ちました。 Wantedly のインフラは AWS + DNSimple 上で稼働していますが、そのリソースの殆どをおよそ1年前から Terraform のコードで管理しています。もちろん1年前の時点で既存のリソースは数多くあったわけですが、それらも Terraform のコードに落としこむため Terraforming という変換ツールを作りました。現在ではインフラ変更の際に GitHub 上で Pull Request によるレビュー + CI 上で自動適用を行う体制が整っております。 以前 Wantedly Advent Calendar '15 で Wantedly での Terraform 運用事情を一通り紹介しましたが (Terraform と CI で実