Docker で「速くてウマイ」な CI 環境を構築するための 5 つの Tips | 株式会社ヌーラボ(Nulab inc.)
Docker 社のユースケースでもあげられているように、CI/CD で Docker を使うというのは、プロダクションシステム以外で Docker の特性を活用できる良い場所だと考えています。ヌーラボではBacklog でのプルリクエストの提供以降、CI のジョブの実行のために Docker を利用しています。ここではその運用から学んだ５つの Tips を紹介したいと思います。 ヌーラボの CI 環境の全体図 これがヌーラボの CI 環境の全体図です。 CI には Jenkins を利用しており、Jenkins のジョブのトリガーとなるのは左側の Backlog や Typetalk です。実際には Jenkins Backlog Plugin や Jenkins Typetalk Plugin を利用してジョブを処理しています。これらのプラグインの詳細については本ブログ末に参照先をのせて
クックパッドにおけるScalable Deploymentsのスライドが興味深い - GeekFactory
クックパッドにおけるアプリのデプロイの資料が非常に興味深いので紹介します．これは @sora_hさんがRubyKaigi 2014で発表 された資料で，100台以上のサーバに短時間でアプリをデプロイする仕組みをどうやって作り上げたのかが説明されています． 以前，スライドの内容を箇条書きにまとめていたのでシェアします．最近では，Jenkins User Coferenceの発表（How We Use Jenkins? // Speaker Deck）でほんの少し引用されていたりします． 内容のまとめ スライドは90枚あります．ざっくりまとめた内容を以下に示します． 概況 140サーバに1日10回のデプロイを実施している（ピーク時） コードベースが大きい モデルだけで約 69K LOC プロダクトコードとテストコードを合わせると約 319K LOC デプロイのルール CIのビルドが成功したリビ
分散テスト実行システムRRRSpecをリリースしました - クックパッド開発者ブログ
技術部アルバイトの鈴木(@draftcode)です。 クックパッドが内部向けに開発・運用を行ってきた、分散テスト実行システムRRRSpecをオープンソースとして公開しました。RRRSpecは時間のかかる自動テストを分散処理することで、全体のテスト時間の短縮を狙うアプリケーションです。現在クックパッドでは17000を超えるテスト項目があり、マシン一台でテストを実行すると完了まで数時間かかります。このテストを60並列程度の分散処理で行うことで、平均8分から9分程度で完了できるようになりました。また、Amazon EC2のスポットインスタンスを利用することにより、大幅なコスト削減も同時に達成しました。 https://github.com/cookpad/rrrspec 分散テスト実行とは アプリケーションが大きくなるにつれて、自動テストの数も大きくなっていきます。クックパッドでは、非常に多くの
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
Droneのオープンソース版を試してみました。 - Yosssi's blog
Droneのオープンソース版が公開されたということで、早速こちらを試してみました。 GitHub: https://github.com/drone/drone デモビデオ: https://docs.google.com/file/d/0By8deR1ROz8memUxV0lTSGZPQUk GitHubのREADME.mdによると、Droneは現在以下のバージョンのUbuntuで動作検証が実施されているとのことでしたので、今回は前述のデモビデオでの手順通り、DigitalOceanでDocker 0.8 Ubuntu 13.04 x64のDropletを作成・起動し、その上でDroneをインストールすることにしました。 Ubuntu Precise 12.04 (LTS) (64-bit) Ubuntu Raring 13.04 (64 bit) インストール $ wget http:
Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー
Jenkins おじさんと戯れること半日、うまくいったので備忘録を残しておく。 やりたかったのは Chef で構築したサーバーを Jenkins で CI する、というもの。このときサーバーはテストが終わる度に破棄して、テスト開始時に再度真っ新な状態から立ち上げたい。(こういうサーバーを壊して作ってというテストはなんという名前で呼ばれるのだろう?) 仮想サーバーを破棄/作成をプログラマブルにやるのはもちろん Vagrant プロビジョニングは Chef Chef の環境を整えるのに knife-solo 0.3.0.pre3 テストは serverspec コードは Github に上げる (https://github.com/naoya/jenkins-vagrant-test) CI は Jenkins という構成になっている。ひとまず Jenkins や Vagrant はローカル
クックパッド株式会社様で開催された「chanko勉強会」に参加してきました #chanko - Kentaro Kuribayashi's blog
クックパッド株式会社様で開催されたchanko勉強会に行ってきました。 chanko: https://github.com/cookpad/chanko chanko以前は、本番サービスとは別の閉じた環境(社内のテスト環境のような)を作って新機能などの仮説検証を行うという、普通の開発スタイルであったのが、 本物のユーザからのフィードバックを得ることで、より正確な仮説検証を行う また、その際に実験的機能が他の機能に影響を与えることのないこと を可能とするために、chankoが開発・導入された。これによって、速く、正確な仮説検証サイクルを回せるようになったとのこと。このあたりは、まさに『リーンスタートアップ』にしつこく語られているような内容で、それを、書籍刊行以前から開発・導入していたのはすごいなと思う。単によりよいプラクティスを実践していたら、それがいつの間にか名前をつけて呼ばれるようにな
なぜUnitTestは理解されない？
TwitterでこんなTweetが流れた… エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・ UnitTestのエビデンスって…なに？ 一般的にテストのエビデンスというと、次の2点を指す。 テスト手順を明らかにするもの（ex. テスト設計書、テスト仕様書、...） テスト結果の証拠（ex. 画面ハードコピー、DBスナップショット、...） UnitTestでは、これはこのように解釈できる。 テスト手順を明らかにするもの ＝ テストコード テスト結果の証拠 ＝ 今実行すればテストが全てグリーンになること これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。 なぜUnitTestはいつまでも理解されないのだろう。 余談。これらのことは、Seleniumなどを使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
