Accelerate 第1版（以下単にAccelerateと呼ぶ）はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。 端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を
こんにちは。弊社のエンゲージメントサーベイ製品HR Spannerのリードエンジニアを担当している岡部です。昨今注目されているDevOpsとそのケイパビリティについて、およそ一年前に社内の勉強会で発表を行ないました。今回の機会に、こちらでも寄稿させていただきたいと思います。 元になっている書籍は比較的大規模な開発を対象にしていると思いますが、当社のHR Spannerは10名程度の比較的小規模な開発であり、それを前提とした内容になっています。 DevOpsとは何か？ 書籍「LeanとDevOpsの科学」では大規模アンケート調査により、高収益、高利益率、高市場占有率を持つ企業は、単に起業家精神やM&Aの取り組みだけでなく、開発組織におけるDevOpsのケイパビリティを強化している傾向が浮かび上がっています。この結果は単なる相関関係ではなく、統計手法によって因果関係として確認されています。また
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Azure DevOps全体の概要については、こちらをご覧ください。 https://qiita.com/mstakaha1113/items/1cf45a5119e1397d0315 "Boards(ボード)"は、開発の根幹を成す大切なサービスです。 サービスとして何があるのかご紹介します。 超概要なので、具体的な画面の説明はありません。 "Boards"のメニュー かなりザックリした説明になります。あえて抽象的な言葉で説明しています。 Work Items : 作業の一覧です。自分に割り当てられている作業をすばやく見つけたい時などに
@Pepabo Tech Conference #15 - ECプラットフォームSUZURIの開発の裏側 https://pepabo.connpass.com/event/215058/
こんにちは。HRBrainでインフラエンジニアをしている間野(@mano_0307)です。 今年の5月にインフラエンジニアとして入社しました。Kubernetesを使っている弊社で、Kubernetesをまったく触ったことのない私のような人間がインフラエンジニアになれるというのが弊社の素晴らしいところです。合言葉は「トライドリブン」。日々トライができる素晴らしい環境です。 Dev環境という各社共通の悩み 多くの会社で何かと困っているのがdev環境なのではないかと思います。 dev環境今日も空いてないよ・・・フルリモートでどうせバレないし、寝ちゃお あれ？久々に使ったdev5環境がうまく動かないよ。・・・(数時間後)あー、最新のmasterがrebaseされてないからAPIのinterface変わってんじゃん！うわー寝よ・・・ そろそろdev環境増やしたいな・・・でも、あの設定も複製しなきゃ
2020年3月3日、クラウド・ネイティブについて議論する「Cloud Native Talk Night vol.4」が開催されました。コンテナやマイクロサービス、サービス・メッシュなどが業界の話題となっている昨今、エキスパートたちが最新動向をシェアします。第4回のトークセッションテーマは、「クラウドネイティブ運用の最適解」。クラウドネイティブ時代に求められるDevとOpsの役割や、従来型運用からのシフトなどについて、さくらインターネット田中邦裕氏、リクルートテクノロジーズ藤原涼馬氏、日本アイ・ビー・エム青山真巳氏がパネルディスカッションを行いました。 なぜDevとOpsのコミュニケーションが重要になってきたのか新野淳一氏（以下、新野）：今までの議論の中で、アプリケーションの開発の人たちと運用する人たちは密接にコミュニケーションしなければいけないという話がありましたが、今の藤原さんのお話だ
Google Cloud Next 2019 in San Francisco が 2019 年 4 月 9 ~11 日に開催されました。その中で、DevOps 関連の発表をまとめました。 Cloud Code for IDEsCloud Code を利用することで、クラウドネイティブアプリケーションを、より速く、より簡単に、開発・デプロイ・デバッグすることができます。Cloud Code for VS Code (Beta)、Cloud Code for IntelliJ (Alpha) で利用可能です。 コンテナを使ったアプリケーションを開発する場合、ソースコードを編集するたびに、コンテナのビルド・デプロイを繰り返す作業が頻繁に発生するため、開発以外の作業に多くの時間を取られてしまいます。 Cloud Code を利用することで、ソースコードの変更を自動的に検知し、本番環境へのデプロイ
CloudNative Days Fukuoka 2019 講演資料
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー！) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか？ 上手くいく／上手くいかない取り組みの違いはどこなのか？ そもそもそれは本当にやるべきか？ 組織とエンジニアの関係、評価はどのようにすれば良いのか？ といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく
昨日は、娘達とクッキーを作ってて、余った白身でラングドシャクッキーを作って美味しかった。ども。椎葉です。 F-team, L-team 牛尾さんの記事にF-team、L-teamってあるんだけど、これ、今僕のいるチームでやってることだー。って思った。Microsoftさんの最先端のチームと同じ思想に辿り着いてたってことで、なんか嬉しいなー。 simplearchitect.hatenablog.com Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。 だいたいは同じなんだけど、ちょっと違う部分があるのでそれをメモしておく。以前からの流れでOps TeamとDev Teamって呼んでるんだけど、今流行りのDevOpsとは関係ないので注意ね。 Ops Team
5. GoogleでのSREの定義 l “Fundamentally, it’s what happens when you ask a software engineer to design an operations function.” l https://landing.google.com/sre/interview/ben-treynor.html l https://www.usenix.org/conference/srecon14/technical-sessions/presentation/keys-sre l 「SRE とは、操作機能を作ってくれとソフトウェア エンジニアに頼んだときに起こる ことだ」 l http://googlecloudplatform-japan.blogspot.jp/2016/07/sre-google-mission- control.
SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes（k8s）へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で
新しいサービスを立ち上げるときは、予期されるトラフィックに対応したいと思うと同時に、途中で何かが起こっても実際のユーザーに影響を及ぼすことは避けたいと考えるものです。では、どうすればサービスの本格稼働の前に問題を見つけることができるのでしょうか。そんなときはダーク ローンチ（dark launch）を検討してください。 ダーク ローンチとは、実際のユーザーから発生したトラフィックをコピーして新サービスに送信し、新サービスからの結果をユーザーに返す前に破棄することです（注 : ダーク ローンチを “フィーチャー トグル”（機能切り替え）と呼ぶこともありますが、それだとサービスの立ち上げに伴う “ダーク” な隠れトラフィックの側面を捉えることはできません）。 ダーク ローンチでできることは次の 2 点です。 新サービスが、既存サービスと同様に実際のユーザーのクエリに対応でき、以前にはなかった不
概要 先日、Tech Night @ Shiodome # 4というイベントに参加して、LTをしてきました。 どんなイベントか 「DevOpsと自動化」をテーマに、事例・知見を共有する場でした。 もとはソフトバンク様の社内勉強会で「外部ゲストを呼ぶ → 公開イベントになった」とのことです。 社会にシェアする姿勢が素敵だと思いました。 他の参加者の発表 あたりまえのことをあたりまえにやる難しさ AWS ECS （EC2 Container Service）を用いた AWS へのDocker コンテナデプロイ 自動化におけるコード管理 送信メールサービスをユニットテストしてみた DevOps、本当のところ こちらのConnpassのページに資料が上がっています。 どんな話をしてきたか こちらが当日の発表資料になります。 ざっくり説明すると DevOps（全体最適化）の前に、業務標準化（ドキュメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
