アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 ＃12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの１つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番
Trelloは、https://www.trello.com で提供されているオンラインのタスク管理サービスで、利用している人も多いと思います。僕自身も以前書いたSCRUM BOOT CAMP THE BOOKの執筆の進捗管理や、Regional Scrum Gathering Tokyoのタスク管理などで使っていました。 このTrelloのオープンソース版のクローンが登場したので紹介します。 LibreboardLibreboardは、こちらで開発が進められているオープンソースソフトウェアでMITライセンスで提供されています。2014年の頭に開発が始まり、最初の開発ペースは早くありませんでしたが、昨年末くらいから急激に開発速度が上がってきているようです。 技術的には、NodejsのフレームワークであるMeteor(メテオ)を利用しています。 Meteorの詳細については以下を参照すると良
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 全国1000万人のInfrastructure as Code職人とImmutable Infrastructure芸人のみなさんこんばんは！ ということでタイトルの通りなのですが、このたび5月22日に「Chef実践入門 コードによるインフラ構成の自動化」(技術評論社)が発売になりますのでお知らせいたします。 本の表紙はこんな感じになります（カバーの色やデザインは変更の可能性があります）。 ご予約は、こちらで受付中です！昨年前半に着手していたので随分時間がかかってしまいましたが、なんとか出すことができました。 今回はCakePHP界隈でもおなじみの安藤祐介さん、イケメン寿司＆ドラクエ好きでおなじみの伊藤直也さん、Ruby使い
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
全国1000万人のPackerユーザーのみなさんこんにちはこんにちは。 Packerは、Mitchell Hashimotoさんによって開発が進められている様々な環境の仮想マシンのテンプレートを簡単に作れるツールです。例えばVagrantを使っている場合はいままではPatrick Deboisさんが作っていたVeeweeを使うのが定番でしたが、このPackerの登場で主流が移りつつあります。 またPackerでは、Amazon EC2用のAMI (Amazon Machine Image)を作成することもできます（某ドラクエ好きな著名エンジニアのIさんが「PackerはAMI作成ツールだ！」と言っていたのを聞いたような気がw） 今までは、Packerでミドルウェアやパッケージをインストールしたり、細かい設定をする場合にはShellのProvisionerを使っていたのですが、先日登場したバ
数日前に初めてのVagrantの書籍であるVagrant: Up and Runningが発売されました！著者はVagrantの作者であるMitchell Hashimoto氏（今年日本に来るそうです！）です。Kindle版なら1215円でかなりお手頃価格です。 感想としては、始めの一歩からプラグインの解説まで、ひと通り網羅している感じで、これから体系だててVagrantを使っていきたい方の学習には便利だと思いますし、既に使っている人でもリファレンス代わりになるのではないかと思います。ページ数も約150ページですので、さくっと読めます（ちなみに内容は英語で書かれていますが、分かりやすいです） Vagrantは過去に何度か大きな仕様変更が入っています。例えば0.7系と1.0系でプラグインの互換性がなく、1.0系と1.1系以降でも互換性がない、1.1系以降ではgemでの配布からインストーラーで
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く