CIのその先へ
This document discusses continuous integration (CI) and using Jenkins for CI. It mentions using Vim, Git, LaTeX, and generating PDFs. It discusses setting up a private system build in CI that uses Ruby and sbt (Scala build tool). Jenkins is used to run builds from version control and ensure the system is properly integrated and built.Read less
次第に腐るテストコード - Fly me to the Luna
結論を最初に書くと、 テストコードを書くだけではダメで、デイリービルドなりCIしないと意味ないんじゃないっすか？という事です。 最近Hudsonを使っていてすごいいいなぁ、と思うのがこの画面。 「リグレッション」という表現はすごい的を射ているなぁ、と思います。以前は「失敗」となっていたと記憶しています。 なんで的を射ているかと思ったかと言うと、テストコードって回帰テストの中で動かされると、その結果は「成功」と「失敗」だけではありませんよね。仕様変更による影響がテストコードので、テストコードが失敗すると言う事もある訳で。確かid:hyoshiokさんのブログだったかで拝見したかなんかだったんですが、Oracleでは毎朝デベロッパが出社すると、QA担当の人から失敗した回帰テストが回覧し、デベロッパに「これは障害なのか、仕様変更による影響なのか」を判断してもらった、と言う話を目にしました。テスト
BPStudy #31 に行ってきた - yukungのブログ
最近全然勉強会に行けてなかったんですが、なんとか仕事の都合をつけて参加してきました。 テーマは、継続的インテグレーションツール「Hudson」ということで、Hudsonコミッタのid:cactusmanさん。 個人的には、最近はチーム管理の仕事がメインになってきてて、HudsonやMaven、Trac／Redmineなどのツールを使ったプロジェクト運営の領域に興味がわいてきたこともあって、今回参加させていただきました。 内容のログや、Twitterのまとめは以下でまとめてくれているので、そちらを参照推奨です。id:kashisanさん、id:ikikkoさん++ ログ BPStudy#31に参加しました - かたるほどでもない技術系ブログ Twitterまとめ BPStudy#31 - Togetter 上記で内容はバッチリだと思うので、僕個人が期待していたこと／聞きたかったこと、話を聞い
大規模受託開発におけるCI - wyukawa's diary
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI（継続的インテグレーション）だよね。 僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。
Invention Works: Mavenと他のツールとの連携
実際の開発ではmaven単体だけで使われることはほとんどなく、mavenを複数のツールと組み合わせて使用します。 そのなかでもJava開発でよく使われているIDEのEclipseとの連携があります。 そのほかのIDEとしてはNetBeansや、最近、無償のコミュニティ版が提供された、IntelliJ IDEAもmavenと組み合わせることが可能です。 また、継続的インテグレーションツールとの親和性も高いです。 EclipseとMavenの統合 一番身近な例としてはEclipseとの連携です。 Eclipseのプラグインでm2eclipseというプラグインがあります。 これは、Eclipse上でMavenを使えるようにします。 主だった機能としては、mavenの設定ファイルであるpom.xmlを読み込んで依存関係にあるjarファイルを自動で取得してパスを通します。また、artifactIdと
Continuous Integrationの12の勘所 - Fly me to the Luna
個人的にCIは大好きで、いろんなところで首をつっこんでは、仕組みを学んで来ました。その勘所をかりかり書いてみました。内容が固いので文体も固いですが、この記事書いている人はこんなに固くないです。むしろゆるゆるです。 最初で全ての環境(ビルド・テスト・CIサーバーの設定)を整えられればパーフェクトだけれども、一度に全部やりきるのはきっと現実的ではない。開発環境としてフルスタック揃ったものはいくつもでているけれども、プロジェクトごとに違う設定は必ずどこかにあるからだ。例えば開発用のDBは各マシンに用意しているけれども、インテグレーション用のDBは別途用意している、とか。設定は「こうすれば良くなるかも」という継続的な改善をしていくつもりで、一番最初は軽めに1時間くらいでできる範囲で一本通す。 小さく産んで、環境を壊さない程度の改善を少しずつ加えて育てていく。育てられるのは製品コードやテストコードだ
プログラマの思索: CIツールHudsonを使いこなす
XPのプラクティスの一つが常時統合(CI・Continuous Integration)。 別名、デイリービルドと言われる。 第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。 #Hudsonの全機能はまだ使いこなせてないので念のため。 【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる 【元ネタ】 バージョン管理と常時結合 豆蔵：継続的インテグレーション（CI）をしましょう Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。 Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。 今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。 ローカルマシンで手作業でビル
Hudson をちゃんと始めてみようと思います - Natural Software
Hudson をちゃんと始めてみようと思います ということでいろいろ調査中。 基本/応用的な使い方 アップデートについて 環境移行について サービス化について：TracLightning 付属の Hudson を Windows サービスとして動かす - かおるんダイアリー プラグインについて 分散ビルドについて：Hudson で分散ビルドのためのスレーブ設定 - かおるんダイアリー 基本/応用的な使い方 ここいらへんを読めば大体基本的なところが網羅できるかと。 ｢マルチ構成プロジェクト＆分散ビルド｣も今後、積極的に取り入れていきたい。 CIツールHudsonを使いこなす: プログラマの思索 Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社 第1回 Hudsonの導入 第2回 Hudson事始め 第3回 Hudsonによるチーム間の連携 | 分散ビルド 第5回 高
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
CIツールの利点とか - 豆無日記
1ヶ月くらい前に某スカイプで書いたまとめ発言だけど、割といい感じだったのでコピペしておきます。 id:yamkazuがtumblrしてたので、そこからサルベージ。 “CIツールは、第1段階では、保険として使える。 1:09 最低レベルでは、ビルドが通るかどうかを保証する保険として。 1:09 テストケースをかけば、それがグリーンであることを保証する保険として。 1:09 テストケースの充実度によって、保険レベルがどんどんあがる。 1:10 先の段階では、用意されたテストケース群が通ったビルドのみを、人力テストに回すようにすることで、人力テストの無駄な繰り返しによる残念な稼働が減らせるようになることが期待できる。 1:10 ということかなぁ。” “あと、CIを導入することで、(1)資産価値の高いテストを書くことへの動機付け、(2)オレらって先端イってるよね？的なチームのマインドおよび結束力の
第2回 Hudson事始め | gihyo.jp
この連載では、オープンソースの継続的インテグレーション(CI)サーバであるHudsonを利用した、ソフトウェア開発の生産性向上について解説しています。前回の記事では、Hudsonの紹介と、インストール手順について解説しました。今回は、実際にHudsonでプロジェクトをビルドをする過程をより詳しく見ていきます。 ジョブの種類を選ぶ まずはHudsonの新規ジョブ作成画面(http://localhost:8080/hudson/newJob)に戻りましょう。ここでは、新しいジョブの作成に先だって、ジョブの種類を選びます。これは、IDEに似ています---ここで適切な種類を選択することによって、プロジェクトにあわせて特化したサポートが提供されるわけです。何もプラグインをインストールしない状態では次の選択肢が表示されます。 フリースタイルプロジェクトのビルド本記事では主にこれを解説します。ソースコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer