「Jenkins ユーザ・カンファレンス 2015 東京」 において 「はてなにおける継続的デプロイメントの現状と Docker の導入」 という発表を行いました - Hatena Developer Blog
アプリケーションエンジニアの id:nobuoka です。 現在は 「少年ジャンプルーキー」 の開発に携わっています。 面白い漫画作品が数多く集まっておりますので、是非ご覧ください！ さて、去る 1 月 11 日に 「Jenkins ユーザ・カンファレンス 2015 東京」 が開催されました。 はてなからも 「はてなにおける継続的デプロイメントの現状と Docker の導入」 というタイトルでセッション発表を行いました。 ここに発表資料を公開します。 発表資料 はてなにおける継続的デプロイメントの現状と Docker の導入 from Yu Nobuoka 概要 内容としては次の 3 点です。 はてな全体のサービス開発と Jenkins についての概要 「少年ジャンプルーキー」 の開発プロセスと Jenkins の活用 開発中の機能を確認するための web アプリケーションを Docker
jenkins + prove で失敗したテストを並列しないで再テストする試み - soh335 memo
深淵な理由で（特に並列度をあげると）たまに落ちてしまうテストがあって、その度にあぁこれはたまに落ちちゃうやつなんですよねみたいな会話するのもいかがかと思っていた。 なので、落ちたテストがあった場合に並列しないで再度 prove してあげてそれでも落ちたらレポートするがいいかなぁと思ったのでこういう感じでやってみた。 JUNIT_NAME_MANGLE=none JUNIT_OUTPUT_FILE=output.xml prove -lvr -j5 --harness TAP::Harness::JUnit t JUNIT_OUTPUT_FILE は TAP::Harness::JUnit が生成する xml を指定する環境変数。 JUNIT_NAME_MANGLE に関しては TAP::Harness::JUnit - search.cpan.org に説明がある。 デフォルトだと hud
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 はローカル
Jenkins で静的解析のグラフを作るとコードを読まなくてもソフトウェアの品質が分かって面白い - おともだちティータイム
細かく書きたいけど、とりあえずメモだけ。 ステップ数が増ている なんらかの開発が行なわれている ステップ数が減っている リファクタリングが行なわれている? 単に仕様落ちしたコードが削除された可能性もある テストカバレッジが下がる テストが書かれていない ... ステップ数が増えている場合 テストが減っている ... ステップ数が変わらない場合 FindBugs 、 PMD 、 Android Lint の警告数が増えている 品質の低下、レビューが正しく行なわれていない CPD 警告数が増えている 品質の低下、レビューが正しく行なわれていない そろそろリファクタリングしたほうがいい Checkstyle 警告数が増えている 品質の低下、レビューが正しく行なわれていない Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化してい
Jenkinsでビルド後に音（BGM、SE）を鳴らしてみた - suzukij's diary
Twitterでビルド後の通知にゲームのBGMを鳴らしてるという話を聞いたのでマネしてみたところ結構良かったのでメモ。 導入した理由 楽しそう 通知はメールやらIRCやらでやっていたけどなんとなく埋もれがち、気付かなかったりすることもあった ビルド後に音を鳴らしてみて そこに居れば絶対に気付くのは良い ビルド失敗音がなる度に失敗した理由をチームメンバと話すようになった。「あ、今の自分かも。調べますね。」みたいな。 フィードバックがより早くなった ゲームみたいで楽しい 他チームの人も「何やってんの？」みたいな感じで Jenkins とか CI な開発に関心持ってくれる その他 BGM、音はチームメンバで楽しく決めたい。趣味の合う合わないとか。 失敗音はなるべく軽いものを（継続的に鳴るので重いと辛くなっちゃう） Jenkinsで音を鳴らすには プラグインのインストール Jenkins Soun
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
