GitHub - dora-team/fourkeys: Platform for monitoring the four key software delivery metrics of software deliveryYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ソフトウェア開発の指標でFour Keysも計測できるFindy Team+の開発チームは何から改善を始めたか - Agile Journey
ソフトウェア開発チームのパフォーマンスを測る指標、それがFour Keysです。「Four Keysはすぐに上がる数字ではなく、地道で本質的な取り組みをしながら、数値を見ることで自分たちはうまくやれていることを確認するもの」と語るのは、Findyのプロダクト開発部でエンジニアリングマネージャーを務める栁沢正二郎さん。 栁沢さんが開発に携わっているFindy Team+は、エンジニア組織がパフォーマンス改善に利用できるSaaSです。GitHubのリポジトリやJiraのイシュートラッキングなどを解析して、エンジニアやチームのパフォーマンスを数値化できます。2022年8月には、Four Keysについても可視化・分析できる「DevOps分析」機能をリリースしました。 注目したい点は、Findy Team+の開発組織自身がFindy Team+をドッグフーディングしていること。つまり、Four K
ヤフーでは開発迅速性と品質のバランスをどう取ってるか（2022年）
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 皆さんは「No Measurement, No Improvement」という言葉をご存じでしょうか。これは「測れないものは改善できない」という意味で、熱力学者であるウィリアム・トムソン博士の言葉とされています。 下図はGoogle社のDORA（DevOps Research and Assessment）を参考にして作成しました。開発スピードとサービスの品質を改善するためには計測が必要です。計測のための4つの指標を紹介します。 四つの指標で計測し、開発スピードとサービスの品質を改善 開発スピードの分析に利用する指標は、1つ目が「Change Lead Time（開発が始まってから本番にデプロイされるまでの時間）」、2つ目が「De
Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG
こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。 以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。 Netflixにおけるフルサイクル開発者―開発したものが運用する 2012年―Netflixでの重要なサービスの運用は骨の折れ
You are what you Git: how your VCS branching model affects your delivery cadence
You are what you Git: how your VCS branching model affects your delivery cadence The path of a software engineer is one of constant learning. We learn things from concepts and processes to languages and tools. Once we have seen them work, we add them to our arsenal and make them our praxis. Before joining CircleCI, my years of experience led me to believe that I was an engineer with a firm underst
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
1日に15回本番デプロイを実現するトランクベース開発のコツ | CyberAgent Developers Blog
株式会社サイバーエージェントでバックエンドエンジニアをしている江頭です。 今回、私たちのチームにトランクベース開発という手法を取り入れることによって、デリバリーの速度と開発効率が上がり1日に多いときで15回以上本番デプロイができました。 この記事では、トランクベース開発とはどのような手法なのかご説明したあとに、実際に導入してわかったことをご紹介したいと思います。 トランクベース開発とは トランクベース開発とは、ソースコードのバージョン管理手法です。現在一般的な手法であるGitflowでは、機能毎にブランチを作成し 1つの機能実装が完了するまでそのブランチで作業し、コードレビュー完了後に各役割ごとに存在するブランチへマージします。 Gitflowでは1つのブランチへ長時間にわたり変更を加えるため、次のような課題があります。 メインブランチへのマージの際に差分が多くコンフリクトが発生する可能性
アジリティの高いソフトウェアに求められる品質とは何か――和田卓人氏が解説【デブサミ2021夏】
和田卓人氏 事業のコアになったIT ITがビジネスの現場で使われ始めた当初は、「あると便利」程度のものでした。IT部門が主導する、一部がちょっと便利になる道具としてのIT。それがいつしか不可欠なものとなり、今ではITをコアに据えたビジネスが一般的になってきています。特に最近ではDX（Digital Transformation）の波が押し寄せ、ITの事業コア化の動きは加速しています。 「このDXには大きく分けて2つのDXが存在します」。ところてんさんの言葉を引用しながら、和田さんはそう解説します。守りのIT、SoR（Systems of Record）的なDX。そして攻めのIT、SoE（System of Engagement）的なDX。事業のコアとなるDXは後者であり、この講演ではそこに焦点が当てられています。 「あると便利」から「必要不可欠」を経て「事業のコア」に変化していったIT プ
稼働率100%をねらってはいけない | タイム・コンサルタントの日誌から
多くの製造業においては、工場の稼働率が、重要な管理指標として今も使われている。3週間前のエントリ「原価の秘密 － なぜ、黒字案件だけを選別受注すると赤字に陥るのか 」（2014/07/06）でも説明したように、製品の個別原価を計算する際、材料費や労務費などの他に、製造機械の使用時間に応じた費用を含めるのが普通だ。その製品の加工作業で、製造機械が何時間必要だったかをベースに、機械のコストをチャージする。いわば“機械の使用料”だ。 個別の機械1時間あたりの使用料単価を『機械賃率』と呼ぶが、これは各機械の年間の維持費用（減価償却費等）を、年間の実稼働時間で割って計算する。機械の遊んでいる時間が多いほど、実稼働時間は減るから、同じ作業をしていても原価が上がる、というのがふつうの会計の仕組みだ。だから、製造業では稼働率を上げるべく、あれこれと努力するという訳である。 そして、前回のエントリを読まれた
開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog;
以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。 前回の記事のサマリー バリューストリームマップを作り、開発フローの課題を発見する バリューストリームマップとは何か チームのバリューストリームマップを作る バリューストリームマップから課題を見つける 見つかった課題を解決する 開発パフォーマンスの指標で改善結果を振り返る まとめ：データを根拠にチーム改善するという進歩 参考 前回の記事のサマリー 前回の記事を前提として書くため、簡単にサマリーすると 開
Azure DevOps Boards(ボード)の超概要 - Qiita
Azure DevOps全体の概要については、こちらをご覧ください。 https://qiita.com/mstakaha1113/items/1cf45a5119e1397d0315 "Boards(ボード)"は、開発の根幹を成す大切なサービスです。 サービスとして何があるのかご紹介します。 超概要なので、具体的な画面の説明はありません。 "Boards"のメニュー かなりザックリした説明になります。あえて抽象的な言葉で説明しています。 Work Items : 作業の一覧です。自分に割り当てられている作業をすばやく見つけたい時などに使います。 Boards : 作業をカード型で提示し、ドラッグアンドドロップでステータス更新できます。付箋紙に書いた作業をホワイトボード上に貼りだしたような見せ方です。いわゆる"Kanban(かんばん)"と呼ばれているもので、作業の流れを可視化します。 Ba
Azure DevOps の SSH public key に ecdsa-sha2-nistp521 な鍵を追加しようとしたら invalid key される問題(未解決問題) - C++ ときどき ごはん、わりとてぃーぶれいく☆
Azure DevOps に ECDSA-521 な公開鍵を登録しようとしたらイヤイヤされた😅 つらい。 Visual Studio Developer Community にも「なんでや…」な感じのスレッドがありました: Support non-RSA keys for SSH authentication - Developer Community 「なんでや…」が続くスレッドに Burak Oezhan がこの記事よりたったの 6 日前に "気づき" を投稿していました: ECDSA 鍵を扱う機能自体は有効なんだ。フロントエンドが送信された鍵を阻んでいるだけさ。 フロントエンドを通すために "ssh-rsa" を "ecdsa-sha2-nistp521" の前の行に追加するんだ。 あるいは別の方法として、 単純に AAAA より前の全てを削除してもいい。鍵自体は AAA... か
Azure DevOpsとセキュリティ
【de:code 2020】 そのロジック、IoT Edge で動きます - Azure IoT Edge 開発 Deep Dive
Connect organization to Microsoft Entra ID - Azure DevOps Services
Azure DevOps Services Learn how to connect your Azure DevOps organization to Microsoft Entra ID. You can sign in with the same username and password that you use with Microsoft services. Add members to your Azure DevOps organization who are already a part of your work organization. You can also enforce policies for accessing your team's critical resources and key assets. For more information about
デプロイのベスト プラクティス - Azure App Service
開発チームごとに独自の要件があり、それによって、クラウド サービスで効率的なデプロイ パイプラインの実装が困難になる可能性があります。 この記事では、App Service へのデプロイにおける 3 つの主要なコンポーネントである、デプロイ ソース、ビルド パイプライン、およびデプロイ メカニズムについて説明します。 この記事では、特定の言語スタックのベスト プラクティスとヒントについても紹介します。 デプロイ コンポーネント デプロイ ソース デプロイ ソースは、アプリケーション コードの場所です。 運用アプリの場合、デプロイ ソースは通常、GitHub、BitBucket、Azure Repos などのバージョン管理ソフトウェアによってホストされるリポジトリです。 開発とテストのシナリオでは、デプロイ ソースはローカル コンピューター上のプロジェクトである可能性があります。 ビルド パ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it
Survey Shows Mounting DevOps Frustration and Costs
https://media.amazonwebservices.com/jp/summit2015/docs/Dev-04d-Tokyo-Summit-2015.pdf