「Terraformデプロイパイプラインを作るなら、どのツールが自分の組織にあっているのだろう？」 Terraformのデプロイパイプラインの実装方法は、選択肢が多くて迷ってしまいます。 この記事では、デプロイに使用できるツールをまとめてみました。 デプロイパイプラインのツール選定の参考になれば幸いです。 前提 Terraformは様々なリソースを管理することができますが、今回はAWSリソースをTerraformで管理する想定としています。 所々AWS固有の単語がでてきますが、ご了承ください。 なぜTerraformのデプロイパイプラインは必要なのか？ デプロイフローをおさらいして、デプロイパイプラインなしの運用の課題を考えてみます。 Terraformのデプロイフロー Terraformで構成管理している場合、リソースの設定変更時は以下のようなフローで行うことが多いです。 コードの編集
terraform importしてplan差分がない=環境が再現できているといつから錯覚していた？ - Qiita
はじめに 先日、Terraform v1.5.0がリリースされました v1.5の目玉はなんと言っても import ブロックと terraform plan -generate-config-out によるtfファイルの生成ですよね〜。これで既存のリソースもimportし放題だと巷で話題です。 ところで、Terraformの特徴として、「インフラをコード化することで環境が再現できる」などと一般的に謳われています。また、Terraformには「既存リソースをimportする機能」があります。別にそれぞれ単独では間違ってはないのですが、これらを組み合わせて、「既存リソースをimportしてplan差分が出なければ元の環境を再現できる」と言えるのでしょうか？ 残念ながら現実にはそうとも言い切れません。なんとなく経験上わかってる人もいるとは思いますが、意外と気づいてない人も多そうな気がしたので、ち
技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。 はじめに: 人と成りては童子のことを棄てたり インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。 プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。 それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通され
中央集権体制からDataOpsへの転換 / centralized-to-dataops-transformation
【イベントページ】 https://chatwork.connpass.com/event/311948/ 我が社が考える最強のデータ基盤'24最新版 Chatworkは約2年前よりデータ基盤の刷新プロジェクトを推進してきました。 スモールスタートで始まったプロジェクトは、今や拡大期を迎えています。 このイベントでは、そのプロセスや直面した壁などを大公開！ さらにゲストには大西氏、CARTA HOLDINGSのPei氏を迎え、各社の考え方やこれからのアーキテクチャについて激論を交わします！
ニーリーのSREによるリリースサイクルの改善〜「隔週深夜1回→1日2回」にリリース頻度を向上させた道のり〜｜株式会社ニーリー公式note
プロダクト開発グループSREチームの大木（おおぎ）と菊地です。 突然ですが、皆さんのプロダクトではリリースはどのように行われていますか？ 実は、ニーリーのメインプロダクトであるPark Direct（パークダイレクト）はわずか1年前まで隔週に一度、深夜0時からしかリリースを行うことができていませんでした。開発組織の健全性の指標として使われる d/d/d (deploys / a day / a developer) という指標で、1年前の我々は d/d/d=0.015ぐらいのスコアでした。この指標は d/d/d >= 0.1 が健全な組織としての目安となるそうです（※1）。かなりの開きがありますね・・・。 この記事では、SREチームのリリースエンジニアリングと開発チームのプロセス改善により、リリースの頻度が大幅に向上したというお話をしたいと思います。 ※1 『エンジニアリング組織論への招待
※この投稿は米国時間 2024 年 1 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 あなたは Acme Corp という架空の会社のエンジニアで、CI / CD と自動化を用いたソフトウェアの統合と配信、データ主導型の指標およびオブザーバビリティ ツールの実装を行う大型プロジェクトに関わっているとします。しかし仲間のエンジニアの多くは、認知負荷が高すぎることで苦戦しています。Kubernetes クラスタのデプロイと自動化、CI / CD パイプラインの構成、セキュリティに関する懸念事項など、検討すべきことはさまざまです。会社の拡大と成長を支援するには、そのような課題の解決方法に関する考え方を改める必要があるとあなたは気付きます。そこで役立つ可能性があるのが、プラットフォーム エンジニアリングです。 プラットフォーム エンジニアリングは「コンピューティ
脆弱性診断の内製化と外注
2023/09/07 Cyber-sec+ MeetUp vol.1 で発表した内容です。
「なんでも屋」は避けたいですか？なんでもできたら最強じゃないですか？：No SRE , No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ #SHIFT TECH TALKS#1 後記とQA補足 #SHIFT_SRE - 株式会社X-Tech5
Blog X-Tech5エンジニアがお送りするテックブログ SREやDevOpsをはじめ、インフラエンジニアリングの実践情報を届けします。 「なんでも屋」は避けたいですか？なんでもできたら最強じゃないですか？：No SRE , No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ #SHIFT TECH TALKS#1 後記とQA補足 #SHIFT_SRE 2024年4月2日 こんにちは。CTOの馬場（@netmarkjp）です。 2024年3月26日に TECH PLAY にて No SRE，No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ｜ #SHIFT TECH TALKS#1 が開催されました。 わたしはトップバッターとして『SREsのためのSRE定着ガイド』をお話しました。 ご質問を多数いただきまして、時間内にはすべては扱えず残念で
[資料公開] DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 #devio2023 | DevelopersIO
盛況のうちに閉幕しましたオフラインイベント。お暑い中多数のご来場をいただき、ほんとうにありがとうございました！ 2日目 7/8 の 15:10 より、標題の 長すぎる タイトルのセッションで登壇しました。その時に資料を公開します。 「開発環境」と銘打っていますが、運用がメイン担当であるエンジニアの方にとってもヒントになるものを盛り込めたのではないかなーと自負しています。 *1 内容 日々大切なアプリケーションを開発されている開発者の方々のなかには、開発基盤やパイプラインに何かしらの課題を感じている方も多いのではないでしょうか。 それらを一撃で吹き飛ばす特効薬「銀の弾丸」はもちろん存在しませんが、その一部は、ツールや手法・考え方の工夫次第で軽減できるものかもしれません。 状況の変化に合わせて武器や装備を整え直すRPG（ロールプレイングゲーム）のように、開発環境やパイプラインに改善の余地はない
![[資料公開] DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜 #devio2023 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/bd645ea7ea4c43ccbe3f3fdc22958f3a1111361b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F07%2F202307-session-sdlc-refactoring-guide-devio2023-eyecatch.png)
Terraformとdriftctlで行うGoogle Cloud 権限管理の省力化 - ZOZO TECH BLOG
はじめに こんにちは、ML・データ部MLOpsブロックの岡本です。 MLOpsブロックでは日々複数のGoogle Cloudプロジェクトを管理しています。これらのプロジェクトでは、データサイエンティストやプロジェクトマネージャーなど別チームのメンバーが作業することもあり、必要に応じてメンバーのGoogleアカウントへ権限を付与しています。 権限の付与はプロジェクトの管理者であるMLOpsブロックメンバーが行いますが、これは頻繁に発生する作業でありトイルとなっていました。 また権限付与後はこれらを継続的に管理し、定期的に棚卸しすることで不要になった権限を削除する必要があります。しかし当初の運用だと権限の棚卸しの対応コストが大きく、これが実施されずに不要な権限が残り続けるという課題もありました。 本記事ではMLOpsブロックで抱えていたGoogle Cloudプロジェクト内での権限管理における
はじめに こんにちは。ZOZOTOWN開発本部アプリ部バックエンドの髙井です。普段は筋肉のビルドが趣味のエンジニアをやっています。私のチームではZOZOTOWNアプリのバックエンド全般の開発から運用までを行っています。 突然ですが、皆さんご存知でしょうか？ ZOZOTOWNはカスタマーサポートセンターの運営管理や従業員のマネジメント等を総合的に評価する「HDI五つ星認証プログラム」にて、五つ星認証を4回連続で取得しています。これは、CS（カスタマーサポート）対応をする弊社社員の皆さんの愛あるサポートの賜物で、同じサービスに携わる身としてもとても誇らしい気持ちです。 そんなCS対応ですが、問い合わせによっては原因調査をエンジニアが行っています。本記事では、CSからエンジニアに来たお問い合わせ（以後、CS問い合わせと呼ぶ）をまとめたレポート作成の自動化についての事例を紹介します。運用コストを抑
株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。2回目は、「Enabling Team」の役割について。前回はこちら。 サービスの完全なオーナーシップを持っているのはすごく大事 名村卓氏（以下、名村）：それをする（認知負荷を下げる）ために何をするかというと、Cognitive Load、認知負荷は見ている領域が広がると結果的にキャパシティを超えちゃうので、そもそも絶対量を減らす必要があります。ドメインフォーカスをするんだけど、そのドメインが大きすぎるとそれだけでキャパシティがオーバーフローするので、サービスのサイズやチームが見るべき領域をできるだけ最小化して
はじめにこんにちは、SAIG/MLOpsチームでアルバイトをしている板野・平野です。 今回は、昨今注目されている大規模言語モデル(LLM)の開発においてMLOpsチームがやるべきことを考えるため、まずはLLM開発の流れを調査・整理しました。 本記事はその内容を「LLM開発のフロー」という題目でまとめたものです。LLMを本番運用するときに考慮すべきこと、LLM開発・運用を支援するサービスやツール・LLMシステムの構成例などについては、「LLM開発でMLOpsチームがやるべきこと」と題して別記事でご紹介していますので、ぜひ併せてご覧ください。 ここでのLLM開発とは、「LLM自体の開発」および「LLMを活用したシステム開発」の両方を含みます。また、「LLM自体の開発」は学習フェーズ、「LLMを活用したシステム開発」は推論フェーズ、として記載しています。 本記事ではLLM開発における各フェーズの
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC 調査会社のIDCは、4年後の2028年までに生成AIベースのツールがソフトウェアテストの70%を作成できるようになり、手動テストの必要性が減り、テストのカバレッジが向上することで、ソフトウェアのユーザービリティとコードの品質向上が実現するとの予測を発表しました。 同社によると、生成AIによるテストスクリプトの生成や管理などを含むテスト自動化は日本を除くアジア太平洋地域で特に人気が高まっており、開発者とDevOpsの専門家がこれらの技術を活用することで、ソフトウェア開発全体の自動化をより推進していくことになるとのことです。 また生成AIはレガシーアプリケーションのコードに対するリファクタリングも促進するとしており、2027年までにリファクタリングに関わるコードの変換や開発タスクの50％が
A Theory of Scrum Team Effectiveness 〜『ゾンビスクラムサバイバルガイド』の裏側にある科学〜
Regional Scrum Gathering Tokyo 2024での講演資料です。 --- 2023年、ソフトウェア工学分野の論文誌であるTOSEM[1]、およびトップカンファレンスであるICSE 2023[2]に、スクラムに関する1本の論文が同時に採択されました。 僕は50ページを超えるその論文を読んで衝撃を受けました。こういう学会に投稿されるスクラム・アジャイルの論文は、アジャイル実践者の目線からするとあまりピンとこないものもあるのですが、この論文はまず、そういった点で一分のスキもありませんでした。 ただの研究者ではない、明らかにスクラム実践者が書いた論文でした。 一体誰が書いたのか、と思って調べてみると、2人の著者 Christiann Verwijs と Daniel Russo のうち、Christiaan Verwijsはあの『ゾンビスクラムサバイバルガイド』の著者の1人
TerraformとGitHub Actionsで複数のCloud RunをまとめてDevOpsした結果, 開発者体験がいい感じになった話. - Lean Baseball
ざっくり言うと「TerraformとGitHub ActionsでGoogle Cloudなマイクロサービスを丸っとDeployする」という話です. Infrastructure as Code（IaC）は個人開発（趣味開発）でもやっておけ 開発〜テスト〜デプロイまで一貫性を持たせるCI/CDを設計しよう 個人開発（もしくは小規模システム）でどこまでIaCとCI/CDを作り込むかはあなた次第 なお, それなりに長いブログです&専門用語やクラウドサービスの解説は必要最小限なのでそこはご了承ください. あらすじ 突然ですが, 皆さんはどのリポジトリパターンが好きですか? 「ポリレポ（Polyrepo）」パターン - マイクロサービスを構成するアプリケーションやインフラ資材を意味がある単位*1で分割してリポジトリ化する. 「モノレポ（Monorepo）」パターン - アプリケーションもインフラも
Linux Daily Topics オープンソースのライセンス変更は「単一障害点のリスク」 ―Linux FoundationからHashiCorpへのアンサーブログ 「もしあなたが朝起きてすぐに、LinuxカーネルがBUSL（Business Source License）のもとで今後供与されることになるというニュースを目にしたらどうしますか」―10月17日付のLinux Foundationのブログはこんな出だしで始まっている。投稿者はLinux Foundationのプロジェクト＆リーガル部門でシニアバイスプレジデントを務めるMike Dolan、オープンソースライセンスの専門家としても知られており、Linux Founationの数々のプロジェクトを法務面から支えてきたプロフェッショナルである。 How open source foundations protect the li
こんにちは。取締役兼ACS事業部の責任者の上林です。 前回の記事「なぜDevOpsの発展にプラットフォームエンジニアリングが必要になるのか？」から間が開いてしまいました。前回お約束した通り、プラットフォームエンジニアリングに関して、海外での動向について少しお話をさせて頂ければと思います。掲題の「DevOpsは死んだ？」や「Googleは私たちに嘘をついた」など、過激なことが言われている側面も取り上げます。 まずは世界の動向ということで、少し私なりの解釈でプラットフォームエンジニアリングに関連するここ数年の歴史を見ていきたいと思います。見解についてはあくまでの個人の見解ですのでご了承ください。なお、プラットフォームという言葉で見てしまうと2011年にIDCさんが第三のプラットフォームを提唱したなど話が膨らんでしまう側面がありますので、ここではプラットフォームエンジニアリングに閉じて記載させて
@stormcat24 です。先日社内で各部署からパネラーを招き開発生産性に関する勉強会を開催したところ、参加者から「技術的負債のことを経営陣に理解してもらうコツはありますか？」という質問がありました。 また、本日開催の開発生産性Conferenceにおいての基調講演で、「LeanとDevOpsの科学」の著者であるNicole Forsgren氏が登壇しましたが、こちらのセッションでもQ&Aでも同様の質問が出ていました。 『LeanとDevOpsの科学』著者登壇！開発生産性Conference (2023/07/13 09:30〜)# 開発生産性Conference 2023 エンジニア不足が叫ばれるなか、開発生産性が今注目を集めています。 インターネット・テック企業はもちろんのこと、大手企業における内製化の取り組みも生産性を上げる1つの手段として向き合う企業が増えてきています。 一方で、
Forkwellさん主催の「今から予測する2024年のPlatform Engineering」で登壇した資料です https://forkwell.connpass.com/event/303922/
HashiCorp TerraformのフォークであるOpenTofuに続いて、HashiCorp Vaultのフォークとして新プロジェクト「OpenBao」がLinux Foundation Edge傘下で進んでいることが明らかになりました。 OpenTofuに続いてOpenBaoがフォーク HashiCoprは今年（2023年）8月、それまでMozilla Public License v2.0（MPL2.0）のオープンソースライセンスで提供していたTerraformやVaultなど同社製品のライセンスを、商用利用に制限があるBusiness Source License v1.1（BSL1.1）に変更すると発表しました。 このライセンス変更に反発した開発者達が中心となり、2023年9月にLinux Foundation傘下でTerraformのフォークである「OpenTofu」が立ち
今年もState of DevOps Reportが発表されましたね。ということで、ザザッと全体を読んで気になったところなどピックアップして読み解いてみました。 全文が気になる方は以下からPDFをダウンロードしてみてください。 cloud.google.com 今年の調査主軸 組織の業績 組織は収益だけでなく、顧客のため、さらに広範なコミュニティのために価値を生み出さなければならない チームパフォーマンス アプリケーションまたはサービスチームが価値を創造し、革新し、協力する能力 従業員の幸福 組織やチームが採用する戦略は、従業員にとって有益なものでなければならない。すなわち、燃え尽きを減らし、満足のいく仕事体験を育み、価値あるアウトプット（つまり生産性）を生み出す能力を高めることである。 今回は上記３つの成果達成に対しての調査となった。 調査結果短評 生成的な文化を持つチームは、組織のパフ
Faster Pull Request Reviews 〜ハイパフォーマンスチームへの道〜 / Faster Pull Request Reviews
『ベストプラクティスから学ぶ！Four Keys向上へのトライ~夏の開発生産性LT Week~』の登壇資料です。 - イベントURL: https://findy.connpass.com/event/292030/
Flutterアプリの定期リリースを支える自動化 - Fast DOCTOR Technologies TECH BLOG
本稿では、ファストドクターのモバイルアプリのリリースフローを整備した取り組みについてご紹介します。 モチベーション ファストドクターのモバイルアプリは、2022年夏にFlutterでのフルリプレースを実施し、それ以降は機能の開発が完了次第随時リリースをするという戦略を取っていました。 この戦略はシンプルであり、開発に関わっているステークホルダーが少ない状況下でうまく機能していました。しかし、組織の拡大に伴い以下のような問題が発生するようになりました。 複数機能の開発スケジュールの調整をしたり、バックエンドのリリース・QAとの整合性を取ったりという必要性が増し、調整コストが肥大化 リリースが不定期なため、いつPull Requestをマージすれば良いか分からずopenされたままのPull Requestが多数 この状況を改善するために、以下の要件を念頭に定期的なリリースとそれを支える仕組みを
燃え尽きエンジニアを救う「オンコール最適化、5つの教訓」|インシデント管理プラットフォーム│PagerDuty
DevOpsチームの中で、業務としての「オンコール対応プロセス」はよく話題に上ることがあります。では一方で「オンコール対応に従事するチームメンバーが抱える個人的な悩みや問題」についてはどうでしょうか？ 「オンコールシフト中のストレスや不安にどう対処したらよいか？」 「オンコールローテーションと子供の世話といったメンバーの個人的な事情を両立させるにはどうしたらよいか？」 「燃え尽きや離職といった問題は、チームメンバー同士の思いやりで解決できるのか？」 オンコール対応のプロセスが適切にマネジメントされていたとしても、オンコール対応チームにおけるこういった悩みは尽きません。そこでPagerDutyでは、2021年11月から12月にかけて、9つのチームからオンコール担当のエンジニアを集め「担当者の現場目線から見たオンコール対応についてのディスカッション」を実施しました。チームメンバーがオンコール対
SREを以てセキュリティエンジニアリングを制す / SRE, Security Engineering, and You
SRE NEXT 2023 のスポンサーセッション (20min) で使用したスライドです。 --- 概要: システムやソフトウェアの信頼性（Reliability）とセキュリティは多くの共通項を持つ概念です。本セッションでは、信頼性に主な関心を置いた技術体系であるSREを、セキュリティリスクの健全な管理のための技術体系として活用する方法を考察します。具体的にはSLO/SLI/エラーバジェット的発想に基づくセキュリティリスク管理や、セキュリティに関するソフトウェアエンジニアリング技法について、具体的な事例も交えながら論じます。 セキュリティ領域は技芸（Art）的解決が必要な課題領域も未だ多く、Engineering的体系は進化の途上にあります。SREというプラクティスを土台としてセキュリティ課題の解決を検討することは、SREに慣れ親しんだ（あるいは興味を持った）技術者の集まる本カンファレン
「今から予測する2024年のPlatform Engineering」で発表した資料です。 https://forkwell.connpass.com/event/303922/
Conventional CommitsとCHANGELOGの自動生成でリリースのユーザ影響をわかりやすくした話 - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
最近関わっているプロジェクトでは、大きなアプリケーションのリアーキテクチャを行っています。 そこではフルスクラッチでインフラの構成を書き直す機会がありました。 そのプロジェクトは社内では比較的複雑な構成になっていて、リアーキテクチャにあたっては、アプリケーション特有の事情により、考慮すべきポイントや難度が高いところがたくさんありました。 具体的には、複数のマイクロサービス間の協調性や独立性とそれに付随する認証/認可、クライアント証明書(mTLS認証)の管理、歴史的経緯による複雑性を正すためのawsアカウント移行などなど。 それらは別の機会で語る(or 同僚の誰かが語ってくれることに期待したい)として、この記事ではインフラをフルスクラッチで書き直すにあたって選択したCDKTFについて、紆余曲折を経つつも最終的に採用したディレクトリ構成について書きたいと思います。 タイトルには「ベストな」とあ
2024/04/16(火) に行われた イベントの登壇資料です 先達エンジニアに学ぶ 思考の現在地 Online Conferencehttps://findy.connpass.com/event/313119/
Google Cloud のマネージド Terraform、 Infrastructure Manager 登場！
こんにちは。クラウドエースの阿部です。 今回はひっそりと一般提供されていた Infrastructure Manager について紹介したいと思います。 Infrastructure Manager とは Infrastructure Manager (以降、Infra Manager と表記) は、 Google Cloud におけるリソースのデプロイや管理を IaC で自動化するためのマネージドサービスです。 内部では Terraform と Cloud Build を使用してリソースの管理を行っています。 Infra Manager の特徴 特徴としては以下の通りです。 GitHub 等と連携した CD (継続的デリバリ) の構築を簡単に実装できます。Cloud Build で同じ事をやる場合は、 cloudbuild.yaml で CI/CD パイプライン設定が必要です。また、ロー
バクラクの爆速開発を支えるDevOpsチームの「のびしろ」！ #のびしろウィーク - LayerX エンジニアブログ
こんにちは！バクラク事業部DevOpsチームです。 この記事は LayerXテックアドカレ2023 の37日目の記事です、前回はid:kikuchyさんが『歳末！バクラク申請・経費精算モバイルアプリ のびしろ大放出祭 』という記事を書いてくれました。また、38日目はid:suguruが『バクラク Enabling Team の課題とのびしろ #のびしろウィーク』を書いてくださいました！ 今回はのびしろウィークということで、バクラクのDevOpsチームの伸びしろをお伝えできればと思います！ のびしろウィークとは のびしろウィークとは、LayerXの各チームメンバーが自分たちのチームの「のびしろ」について対外的に発信する期間です！ 過去の対外的な発信では社内でうまく行った事例などについては各種発信していましたが、どういう課題があってどういった方の協力を求めているかについての発信はあまり行なって
SonarCloudと始める静的コード解析 〜ソフトウェア品質向上のための第一歩〜 - ZOZO TECH BLOG
はじめに こんにちは。FAANSバックエンドエンジニアの浜口（@xlgorbylx）です。普段はFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。例えば、ZOZOTOWN上で実店舗の在庫取り置きができる機能や、コーディネート投稿の機能などを備えています。投稿されたコーディネートはZOZOTOWNやWEAR、Yahoo!ショッピング、ブランド様のECサイト等に連携が可能です。これによりお客様のコーディネート選びをサポートし、購買体験をより充実したものにします。機能の詳細に関しましては、下記プレスリリースをご覧ください。 corp.zozo.com 本稿では、Go言語で実装されたFAANSのバックエンドシステムについて、SonarSource社の提供するSaaSである「Sonar
Terraform の基本的な仕組みから実践まで深く学べる一冊「詳解 Terraform 第3版」を読んだ - kakakakakku blog
2023年11月21日（明日📅）に出版される新著「詳解 Terraform 第3版」を読んだ📕 本書では Terraform の基本的な仕組みを学べるだけではなく，Terraform を実践的に使うときに必要になるステート管理・モジュール・シークレット管理・テストなど幅広いトピックまでまとまった一冊になっていて素晴らしかった❗️また Terraform の日本語書籍は今まであまりなく，この内容を日本語で読めることも素晴らしいと思う． 詳解 Terraform 第3版 ―Infrastructure as Codeを実現する 作者:Yevgeniy Brikmanオーム社Amazon 本書は翻訳を担当された松浦隼人さん，そしてオライリー・ジャパン様に送っていただきました．出版情報を知ったときから絶対に買おうと思っていたほど気になってました．ありがとうございます❗️ そして出版おめでとうご
CloudFormation IaC generatorを使った既存AWS環境の管理方法 / Managing existing environment with AWS CFn IaC generator
2024/02/05にリリースされた AWS CloudFormation IaC generator (Infrastructure as Code generator) を使い、手で作った環境をCloudFormationまたはCDKで管理するためのファーストステップガイドです。操作イメージのスクリーンショットも付いています。 まず操作感をイメージしていただくための資料であって、諸条件を網羅したものではありませんのでご注意ください。 詳細は以下のサイトもご覧ください。 AWS CloudFormation にアプリケーション全体をインポート https://aws.amazon.com/jp/blogs/news/import-entire-applications-into-aws-cloudformation/ Announcing CDK Migrate: A single co
Platform as a productの取り組み - Sansan研究開発のPlatform Engineering / Platform as a product initiative - Platform Engineering at Sansan R&D
■イベント Platform Engineering Meetup #7 https://platformengineering.connpass.com/event/307275/ ■発表者 技術本部 研究開発部 Architectグループ 神林 祐⼀ ■研究開発職 採用情報 https://media.sansan-engineering.com/randd ■Sansan Tech Blog https://buildersbox.corp-sansan.com/
TFLint: Terraform の Linter を活用しよう - kakakakakku blog
Terraform を使うときに記法やお作法を共通化してベストプラクティスに近付けるために TFLint を導入すると便利❗️ 最近 TFLint を導入する機会があったので作業ログをまとめる📝 github.com TFLint をセットアップする TFLint のセットアップは macOS だと Homebrew を使えば簡単〜 今回は TFLint v0.47.0 を前提にする． $ brew install tflint $ tflint --version TFLint version 0.47.0 + ruleset.terraform (0.4.0-bundled) TFLint を実行する 基本的には tflint コマンドを実行すれば OK👌 該当する Warning があるとだーっと表示される． $ tflint 10 issue(s) found: もしモジュール
HashiCorpが、「Terraformによるインフラストラクチャのセキュリティ強化に関する6つの手法」というブログ記事を公開しました。この記事では、クラウド環境への移行に伴うセキュリティ上の課題に対処する方法が具体的に述べられています。 HashiCorpが、Terraformによるインフラストラクチャのセキュリティ強化に関する6つの手法を公開しました。 この記事では、クラウド環境への移行に伴うセキュリティ上の課題に対処する方法が具体的に述べられています。 HashiCorpの調査によれば、セキュリティはマルチクラウド環境の成功に不可欠な要素として挙げられており、Terraformを活用することでセキュリティとコンプライアンスを重視したインフラストラクチャのプロビジョニングプロセスを実現することができます。 1. プロビジョニングスキルのギャップを埋める 調査によると、スキルギャップが
[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント / Tips for designing and structuring tests to increase deployment frequency in front-end development
2023/10/06にオンラインでタイミーさんと共同開催させてもらった「Four Keysで改善する開発生産性〜データ・モバイル・フロントエンド〜」での資料です。 https://uzabase-tech.connpass.com/event/294494/ === セクション② フロントエンド開発における、デプロイ頻度を上げるためのテスト設計と仕組みづくりのヒント https://www.youtube.com/live/mrfTRtL8gOI?feature=shared&t=1856
![[2023/10/06 - Four Keysで改善する開発生産性] フロントエンド開発における、 デプロイ頻度を上げるための テスト設計と仕組みづくりのヒント / Tips for designing and structuring tests to increase deployment frequency in front-end development](https://cdn-ak-scissors.b.st-hatena.com/image/square/60e555b2900801a1c6cc52f41796765a4a92a91a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5c3a4c39012049358f4cdea43d34ba5e%2Fslide_0.jpg%3F27291210)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraformのデプロイパイプラインに使用できるツールをまとめてみた | DevelopersIO
生産性指標をFour Keysから変更した話 - Sansan Tech Blog
プロダクト開発はなぜ直観に反するのか - 弁護士ドットコム株式会社 Creators’ blog
How to become a platform engineer | Google Cloud 公式ブログ
LookerStudioでDevOpsのレポーティングを自動化する - ZOZO TECH BLOG
プロダクト開発メインチームのパフォーマンスを最大化するには？ 生産性の鍵「認知負荷」を下げる「Enabling Team」の在り方
LLM開発のフロー | フューチャー技術ブログ
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC
オープンソースのライセンス変更は「単一障害点のリスク」―Linux FoundationからHashiCorpへのアンサーブログ | gihyo.jp
「DevOpsは死んだ？」はメーカーのポジショントークか？ - APC 技術ブログ
経営層に開発生産性向上へのコミットについて理解してもらうためには
2024年のPlatform Engineeringはこうなる(なってほしい)
HashiCorp Vaultもフォークへ、「OpenBao」がLinux Foundation傘下で進行中
2023 State of DevOps Reportを読んだ - 生涯未熟
ソニーでの事例から考えるプラットフォーム開発
ベストなCDK for Terraform(CDKTF)のディレクトリ構成を探る
日本におけるデータエンジニアリングのこれまでとこれから
Terraformが考える、インフラセキュリティを強化する6つのポイント