[B! DevOps] ledlizerdのブックマーク

アジャイルな開発には安全性が不可欠 : 現実世界の安全機構との3つのアナロジー | POSTD

(2016/7/15、著者プロフィールを修正いたしました。) 仮に、高速道路の自動車をより速く走らせることがあなたの務めだとします。もしあなたが、ドライバー全員にただ﹁アクセルを思いきり踏むように﹂と言ったら、一体どうなるでしょうか？結果は明らかに、大惨事となるでしょう。それなのに、ソフトウェアの構築を速めようとする時に、多くの開発者がまさにそんな態度を取っているのです。その理由として持ち出されるのは、以下のようなことです。﹁本当にアジャイルに進めたいので、デザインやドキュメントには時間をかけられない﹂﹁これは本番環境にすぐ反映しなきゃいけないから、テストを書く時間はない﹂﹁何もかも自動化する時間はなかったので、コードのデプロイは手作業でやる﹂自動車が高速道路を高速で走るには、安全性が欠かせません。より速く走るためには、ブレーキやシートベルト、エアバッグといった、いざという時にド

ledlizerd 2016/04/26

リンク

日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ

私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この2つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。見えてきた﹁物量﹂の違い私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは1つのことをこなすための﹁物量﹂が違うということです。

ledlizerd 2016/03/31

リンク

日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ

私が初めてeXtremeProgramming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？これは、私がマイクロソフトの面接の時に、当時

ledlizerd 2016/03/28

リンク

アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) | DevelopersIO

アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。アジャイル・クラウド・DevOps は実際のところどんなものなのか？　上手くいく／上手くいかない取り組みの違いはどこなのか？　そもそもそれは本当にやるべきか？　組織とエンジニアの関係、評価はどのようにすれば良いのか？　といった幅広いテーマについて語っていただきました。このインタビュー記事は、アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方手を付けたけど、なんだか上手くいっていないことにお悩みの方もしく

ledlizerd 2016/03/11

リンク

ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。新言語を採用するときに、考慮すべきことの一つとして、﹁インフラ﹂への影響があります。新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに﹁インフラ﹂への影響について聞かれます。もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

ledlizerd 2016/03/04

リンク

【資料公開】DevOpsの基本

こんにちは。@ryuzeeです。営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の﹁個別プロセス﹂の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの

ledlizerd 2016/02/10

リンク

【資料公開】強いチームの作り方 | Ryuzee.com

2015年11月10日に某社の社内勉強会で、﹁強いチームの作り方﹂というテーマで話をしたのでその際の資料を公開しておきます。内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。最近DevOpsの文脈ですぐに﹁インフラ自動化しないといけない﹂とか﹁ツール使って効率化﹂みたいな話を頻繁に聞きます。が、端的にいえば、﹁実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである﹂というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。一度自分たちのチームや組織について考えてみるとよいと思います。

ledlizerd 2015/11/11

リンク

Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った / How&Why I have been leveraging Kibana for DevOps

2015/4/4, Elasticsearch勉強会 in 名古屋 https://elasticsearch.doorkeeper.jp/events/21984 ブログ http://blog.exoego.net/2015/04/kibana4-use-case.html

ledlizerd 2015/04/07

リンク

Dockerが、分散環境構築ツール群「Docker Machine」「Docker Swarm」「Docker Compose」を公開

Dockerが、分散環境構築ツール群﹁Docker Machine﹂﹁Docker Swarm﹂﹁Docker Compose﹂を公開 Dockerは、Docker Engineの環境を構築し、分散環境を整え、デプロイするための一連のツール群﹁Docker Machine﹂﹁Docker Swarm﹂﹁Docker Compose﹂を公開しました。MachineとSwarmはベータ版公開、Composeは正式版公開です。

ledlizerd 2015/02/27

リンク

はてなブックマーク

タグ

関連タグで絞り込む (14)

DevOpsに関するledlizerdのブックマーク (9)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第3週）

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス