Docker互換のセキュアなコンテナ実行環境「Podman」超入門いまやWebアプリの開発やデプロイにおいて、コンテナは欠かせないものになってきました。 コンテナ実行環境にも色々ありますが、その中でも支配的なのがDockerでしょう。 ですがDockerは、その構造上いくつかの問題も抱えています。 今回はDockerと互換性を持ちながらも、よりセキュアに運用できるPo…
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま
デプロイ頻度を向上させることへの誤解
デプロイ頻度(deployment frequency)とは 組織のパフォーマンス(収益性・市場占有率・生産性)と、デリバリのパフォーマンスとは高い相関があります。 デリバリのパフォーマンスとしては、Four Keysと呼ばれる4つの尺度が有名です。 参考: エリート DevOps チームであることを Four Keys プロジェクトで確認する そのうちの１つであるデプロイ頻度(deployment frequency)とは、文字通り本番環境に変更が反映された頻度のことを指します。 2022年の State of DevOps Report によると、高パフォーマーと低パフォーマーには雲泥の差があることが記されています。 high performerのデプロイ頻度はおよそ1日4回、1年間で1460回。 low performerは1ヶ月に1回〜6ヶ月に1回の頻度でしかデプロイを行っておらず
平均修復時間・変更障害率を可視化のメリットと改善のためのアクションーFour Keys運用
Four Keysの個別指標ごとの基本的な解説記事を書いていきます。 今回は、変更障害率と平均修復時間を見る意味と指標の改善アクションをなぜ・どのようなことをやるのかについてご紹介します。 PR：Offers MGRはFour Keysの可視化機能があります Offers MGRではFour Keysの可視化機能があり、 月次でのFour Keysのチーム・組織別の振り返りへの活用 半期ごとの技術戦略、組織戦略への活用 などの場面で、様々な企業で活用されております。 開発生産性を高める上で、まず現状・課題の把握を行い、チームごとでの改善への取り組みのマネジメントを行い、全体を引き上げていくツールとしてぜひお使いください。 Offers MGR プロダクト開発組織のパフォーマンス最大化 変更障害率と平均修復時間を可視化、改善する意味 変更障害率 (Change Failure Rate) 変
デプロイ頻度・変更のリードタイムを向上させる意味とアクションーFour Keys運用
前回は、Four Keysの変更障害率・平均修復時間を見るメリットと改善方法の記事を書きました。 今回はデプロイ頻度と変更のリードタイムに関して見る意味と改善方法についてご紹介します。 デプロイ頻度の重要性 デプロイ頻度の改善に関する構造 デプロイ頻度を見る意味 デプロイ頻度を向上させることが事業やプロダクトにどう影響を与えるのかは以下のような流れであり、プロダクトを顧客やユーザーに提供する上でまず最初に気にすべきポイントです。 1 デプロイ頻度や変更のリードタイムが短い → 2 顧客・ユーザーへの提供速度が速い → 3 プロダクトの提供価値の向上しやすい → 4 プロダクトの成長≒事業成長へ デプロイ頻度とは デプロイ頻度は、**特定期間の営業日で開発チームがどれだけ迅速に新機能や修正をリリースできるかを示す指標（Offers MGRの場合）**です。 デプロイ頻度が高いほど、開発チーム
S3のブロックパブリックアクセス設定について分かりやすく説明する - 非凡な才能をください。
s3のセキュリティ設定について、国内外で前から問題になっているんですね。 ソリューションアーキテクトの資格取得に向けて、ハンズオンをしていたところ、s3の「アクセス権限」の設定の中の特にブロックパブリックアクセスの設定について、分かりにくかったので書き残します。 news.yahoo.co.jp techtarget.itmedia.co.jp 設定箇所 新規に作成する場合、全ての設定値はデフォルトで有効になっており、パブリックアクセスをすべてブロックするようになっています。 ①新しいアクセスコントロールリスト (ACL) を介して許可されたバケットとオブジェクトへのパブリックアクセスをブロックする 機能：ACLの新規作成、設定変更でパブリックアクセス可能な設定にしない 既存のACLの設定は何も変わりません。ACLでパブリックアクセスを許可していればアクセスできますし、無許可にしていればア
AWS、「Amazon Q Developer」で、社内コードや社内APIにも対応するカスタマイズが可能に
コード生成AIの「Amazon Q Developer」が社内のコードやライブラリ、APIなどを学習できるようになった。顧客データの取り出し方など社内コード特有の質問にもチャットで答えてくれる。 Amazon Web Services（AWS）は、生成AIがコードの生成などをしてくれる「Amazon Q Developer」に、社内コードや社内APIの知識を追加できるカスタマイズ機能の提供を開始したことを発表しました。 Slather on personalization with your order of real-time suggestions. You can customize #AmazonQ Developer to generate even better code suggestions—based on your internal libraries, APIs, &
ShellScriptで自動化を楽にしたい時に知っておいても良いこと | sreake.com | 株式会社スリーシェイク
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
プログラムの生産性を高めるためになにを勉強するか - きしだのHatena
用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ
建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena
建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？という質問がブコメであって、似たような話もいくつか見かけたのですが、建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです。なのでソフトウェアでは自動化されています。 もしも業務システムの納品物が、バベッジの階差機関のような歯車を組み合わせた機械式の計算機で、ビル一棟分に歯車をつめこんで組み立てて納品するというようなことになれば、多重下請けで分業してビルドするのが最もよい方法ということになると思います。 追記 「継続的デリバリーのソフトウェア工学」では、「ソフトウェア開発を選んだ私たちがバカでない限り、私たちにとっての製造とは、ビルドボタンのクリックです」とあります。橋梁建設を例に、物理的な製造・生産との違いが説明されています。 継続的デリバリーのソフトウェア工
多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん
ゆっくり解説動画を一瞬で作れるAIアプリ「NoLang」の使い方まとめ
「NoLang」は「○○の解説動画を作って」と入力するだけで解説動画を作成できるウェブアプリです。新たに、画面端にキャラクターを2体配置して対話形式で物事を解説する「ゆっくり解説」形式の動画が作成可能になったので、実際に試してみました。 【🔥重大発表】🐬NoLang 2.0をリリースしました！！ ついに、「ゆっくり解説」形式の動画生成や縦型ショート動画の作成が可能に！ 他にも動画の長さ指定、プロンプトによるスタイル制御、画像生成AIなど新機能が目白押し。 圧倒的進化を遂げたNoLangを是非お試しください！https://t.co/WcRBvKLhP1 pic.twitter.com/JOFN8t45KK— マーベリック|生成AI@NoLang (@sayhi2ai_jp) July 7, 2024 ・目次 ◆1：NoLangのアカウント登録 ◆2：「ゆっくり解説」形式の動画を作る設定
業務日誌用のノートを買った
日本法令の「ビジネスノート」シリーズを知っていますか 近所の文房具屋で、「工事日誌」「自動車運転日誌」というノートを見かけたとき、見知らぬ業務の世界に触れた気がしてどきどきした。 日本法令という会社のビジネスノートシリーズというらしい。「自動車運転日誌」にはいったい何を書くというのか。気になったのでひととおり買ってみた。 宿日直日誌 書店で見かけて最初にロマンを感じたのがこの宿日直日誌だ。 なにせ宿直日誌を書いたことがないので分からないが、というかだからこそ魅力を感じるわけだが、きっとどこかの営業所に宿直をした社員とかが書くのだろう。 宿直は交代制なんだろうか。1ヶ月に1回くらいかな。宿直してる間は何をしてるんだろう。2階の奥の方に宿直室があって、電子レンジとテレビがあるのかな。コンロと流し台とかもあるけど、結局カップラーメンを食べるのかな。 そういうことが、この表紙を見ただけでぶわーっと
ChatGPTにタスクリストを突っ込んで「最初にやるのどれ？」って聞いて終わったら次の指示を受けているけどこれより馬鹿な使い方をしてるやついる？
ワン・チャン・アルディ @WangChangHardy 俺よりバカなChatGPTの使い方してるやついる？タスクリスト突っ込んで、最初にやるのどれ？と聞いて最初のやつ終わったら、終わりました。って報告して次の指示受けてる
脳に収まるコードの書き方
Mark Seemann 著、吉羽 龍太郎、原田 騎郎 訳、Robert C. Martin まえがき TOPICS 発行年月日 2024年06月 PRINT LENGTH 312 ISBN 978-4-8144-0079-9 原書 Code That Fits in Your Head FORMAT Print PDF EPUB ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します
生産性の可視化こわい - masayuki5160's diary
TL;DR 立場によっては、組織全体の生産性の可視化が必要なのはわかる。 ただ、チーム単位での生産性の細かい可視化の話はちょっとこわい。チーム単位での生産性に関しては、ある期間にそのチームがどんな機能をリリースして、それがどうだったか、を評価して、をすればだいたい良いような。 生産性の可視化？ 全然知らなかったんだけど、開発生産性の可視化を支援するSaaSがあると先日知った。こちら。 findy-team.io なるほど最近はすごい便利なものがあるなーと思った。 一方で、このツールと日々にらめっこしてるチームはなんか僕が目指したいチームではないなと思った。だから、僕はこういうツールは今の僕の立場としてはいらないなーと思った。 でも、組織に所属するエンジニアが100名、200名とか規模になってるようなとき、その組織のCTOなりVPoE、組織横断の課題を解決するチームなどはこういったツールは必
なぜゲーム業界はJenkinsを選ぶのか？その理由と利点 | DevelopersIO
こんにちは ゲームソリューション部の出村です。 みなさんはソフトウェア開発においてCI/CDツールは何を利用していますでしょうか？ これまでゲーム開発の現場を見てきましたが、ゲーム開発においてよく使われるCI/CDツールはやはりJenkinsです。このJenkins、一昔前ではWeb開発をはじめとしてさまざまなソフトウェア開発でよく利用されていました。ただ、ここ最近はGitHub Actionsなど他のツールに置き換えられているという印象があります。 しかし、ことゲーム開発においてはGitHub Actionsといった他のCI/CDツールではなく、Jenkinsが利用されている場面が圧倒的に多いです。これは、他のCI/CDツールを利用したくないという消極的な理由ではなく、Jenkinsを利用する明確な理由があるためだと考えています。 ゲーム業界はJenkinsが活用される理由 ここでは、ゲ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DORA | Capabilities: Trunk-based Development
弊社Slackには「婆さんや飯はまだか」というチャンネルがあり、こういう運用をされている→「最高の会社じゃん」「優しい世界」
SPFx 1.19.0 - Error during build with [object Object] errors that didn't happen in previous versions · Issue #9675 · SharePoint/sp-dev-docs