手順 Android側 コマンドラインでAndroidプロジェクトの作成 antコマンドでプロジェクトをビルド gitにcommit & push hudson側 hudsonのインストール hudsonを起動 hudsonプロジェクトを作成 jobの追加 ターゲットプロジェクト テストプロジェクト hudsonからビルド hudsonでテスト AndroidTest側 コマンドラインでAndroidのテストプロジェクトの作成 antコマンドでプロジェクトをビルド エミュレータを起動する コマンドラインでテスト実行 gitにcommit & push hudsonのインストール http://hudson-ci.org/ からhudson.warをダウンロードして適当なところに配置 Androidプロジェクトをコマンドラインから作成 hudson上でBuildするのにantコマンドを使いま
既に使いこなしている @miyatay さんからpom.xmlを分けてもらったので、@zaki50 さんと @bols_blue さんと @hidecheck さんと4人で束になって倒してみた。 なにがうれしいの? 構成管理できると、依存関係の追加とか簡単にできて楽だよ! あと、Hudsonで簡単にCIぶんぶん丸できて幸せらしいよ!! ↑この程度の認識の奴がmavenに手を出すと不幸になるのは確定的に明らか 現在僕は不幸です!!ちくしょう!!(問題点が解決できない) やってみよう! 正直参考リンクの通りにやれ、で全部終わる予感。 とりあえず動くコード この記事書いてる時は commit 004f0ef maven-android-plugin GettingStarted samples サンプルすごい役に立つ 基本的なところ Androidプロジェクト作成 mavenコマンドの覚え書き
Each section covers the upgrade from the previous LTS release, the section on 2.387.1 covers the upgrade from 2.375.4.
Androidアプリ開発においてCIツールHudsonで分散ビルドするようにするプロジェクトは多いと思うんですが、署名自動化についてメモ。(今はJenkinsですね。でも以下はHudsonですすめたいと思います) Build Secret Pluginについて アプリをAndroidマーケットから配信するためにはリリースモードでコンパイルして作成されるAPKファイルに秘密鍵の署名で署名する必要があります。これは keytoolで秘密鍵を生成し、jarsignerで署名する手間が発生します。けどHudsonには「Build Secret Plugin」という便利なプラグインがあって、これは秘密鍵と秘密情報をzipファイルで圧縮してHudsonサーバへアップロードすることで、APKファイル作成の都度の署名するとかのめんどくさい手順が省けます。 前提 ここでは以下の名称での例を示します。適宜読み
先週末、ベイエリアの日本人技術者の交流会(?)であるJTPAに行って、「オープンソースコミュニティの運営について」というタイトルでHudsonのプロジェクトの初期から大きくなるまでの間の運営上の工夫などを発表してきました...というより、好き勝手にしゃべってきました。 オープンソースソフトウェアを沢山の人に使ってもらって沢山の人に開発者として参加してもらうには、相手の立場に立ってできるだけ色々な事を簡単にしていくといいですよ。それには技術的な工夫もあるし、もっとsocial hackのような工夫もあるし、どうやって見知らぬ他人同士が共同作業をしないで済むようにするか、みたいな話もありますよ。みたいな話です。僕としては、技術・プログラミングを使ってこういった本質的には技術的でない問題を解決することができて、Hudsonはその点が自分でも気に入っているんだ、というような事を主張したかったのです
Hudsonコミュニティーの代表の一人「abayer」がプロジェクト改称のについて声明した。Kohsuke Kawaguchiを含むコミュニティーリーダがオラククルと交渉してきたが、プロジェクト名については接点が見出せず、コミュニティーの投票にかけることになるそだ。次の名前には「Jenkins」がもう選んである。Hudsonに続いて英国の執事っぽいものを選んだそうだ。 http://www.hudson-labs.org/content/hudsons-future 分かり易いバージョンはこちら オラクルとの交渉はプロジェクトのインフラ(メールリストやSCM)、Hudson coreのコードレビューポリシー、これからのガバナンスの構造など、良い成果があがった。 しかし折り合いがつかない部分もある。 第三者依存ライセンス(third party dependency licenses)と、「
はじめに Hudsonを標準状態のままで使用した場合、Hudsonにアクセスできる全てのユーザが、Hudsonの全ての機能を制限なく利用できてしまいます。 Hudsonの機能を熟知しているチーム内でHudsonを使用するのであれば、この標準状態の方が設定に煩わされない分、簡便に運用できるので都合が良いかもしれません。 しかし一般的には、間違った操作によってHudsonが動作しなくなることを防ぐために、「Hudsonの管理者」と「Hudsonの利用者」くらいの最低限の区別をした方が良いのではないかと思います。 そこで、この記事では、Hudsonのユーザーデータベースを使用して、Hudsonの操作権限を制御する方法について説明したいと思います。 なお、説明を簡素化するために、Hudsonの公式サイトにはない用語や分類を用いて説明していますので、その点はご了承ください。 操作権限を制御する前に
はじめに リリースに向けて追い込みに入っている状況なのに、マーフィーの法則が予定どおりに(?)働いて、「昨日まで動いていたHudsonがハードディスク故障のせいで動作しなくなっている」なんてことになると大変です。 この記事では、そんな状況でも慌てず騒がず対処できるようにするために、Hudson環境のバックアップについて説明したいと思います。 なお、この記事におけるバックアップ方針は次のとおりです。 (A) : お金をかけずに取得する (B) : 安全なタイミングで取得する (C) : 分かりやすい方法で取得する (D) : Hudson自身に(定期的に)取得してもらう バックアップの前に バックアップ対象 バックアップ対象は、Hudson環境が構築されているHUDSON_HOMEディレクトリの内容になります。 (HUDSON_HOMEディレクトリ内のディレクトリ構成例は以下を参照) HUD
11月12日金曜日、Hudsonの生みの親である筆者の訪日にあわせて、法政大学情報科学部、Seasarファウンデーションの後援で、Hudson勉強会(またの名を「日本ビルド職人の集い」)が開催されました。200人以上集まる大きなイベントとなり、様々な発表やLTが行われました。その模様を報告します。 「Hudson初心者向けデモ」 まず、cactusmanさんによる、Hudsonをさわった事のない人向けへの紹介とデモが行われました。「java -jar hudson.war」で起動できるのが大変便利だとし、Hudsonからはスケジューリング、チェックアウト、ビルドの実行、結果のまとめ、ビルドの通知などができると紹介されました。 デモでは、Subversionリポジトリ上に格納されたMaven2プロジェクトをビルドする様子を紹介し、コミット後すぐにビルドが始まる様子や、新しいテストを追加
忙しいプロジェクトだとどうしてもおろそかにされがちなところですが、maven2やant+ivyを使ってビルドやリリースの自動化を行い、Hudsonなどの継続的結合環境上で動作させることは、開発生産性向上のために欠かせないことです。ビルド自動化はアジャイル開発なら当然必須ですが、そうでないウォーターフォールのプロジェクトであっても、是非取り入れたいことです。 そこで、意外な盲点となるのが、正しくビルドスクリプトを作成して、メンテナンスするプログラマーのスキルが非常に重要であるという点です。こういったビルドスクリプトはあくまでも最終納品物ではなく、生産性向上のためのツールという位置づけのためか、多くのプロジェクトではきちんとした工数や担当者がアサインされることなく、仕事の合間に知識のあるプログラマーがボランティアで開発するというケースも多いのではないでしょうか。しかし、最近の複雑なアプリケーシ
Announcing Beta Availability of InfraDNA’s Certified Hudson CI (ICHCI) Server I’m happy to announce the beta release of InfraDNA’s Certified Hudson CI (ICHCI) Server. ICHCI is a value-added distribution of Hudson, and here’s why I think it’s useful: First, ICHCI is more stable sustaining release trains from Hudson; ICHCI is periodically branched off from a version of Hudson that was of particularl
An amazing open source community of Tools, Projects and Collaborative Working Groups.
前に考えていた開発プロセスの変更を色々試行錯誤してみてある程度固まってきました。過去の記事は以下からどうぞ。 Subversion, Git, Redmine, Hudson – 現状の連携 » tune web Subversion, Git, Redmine, Hudson – 今考えている連携 » tune web Subversion, Git, Redmine, Hudson – 今考えている連携2 » tune web ネットワークが切り離された外部チームとのやりとりは結局git bundleにしました。外部チームからはパッチでもらい、レビューした後に適用する。ある程度開発が進んだらgit bundleでリポジトリをコピーして外部チームに送付。外部チームはbundleファイルをそれぞれcloneして開発を行い、適宜git fetch/git pullしながら更新に追従します。タ
そろそろ大規模ソフトウェア開発に一言いっておくか。デイリービルドとリグレッションテスト すばらしいスライドだ。ディリービルドとリグレッションテストを大規模パッケージ開発において適用したときの雰囲気が良く現れている。10年前の話のようだが今で言うCI(継続的インテグレーション)だよね。 僕も2年ぐらい前にパッケージ開発でCruiseControlを適用したことがある。junitのテストケースがあったがメンテされていなかったので使わなかった。結合レベルの自動テストもあったがこれもメンテされておらずそんなに使わなかった。スローテスト問題もあったしね。その代わり新たに結合レベルの自動テストを作っていってそれなりにうまくいったように思う。ただ実質一人プロジェクトだったこともあり途中から面倒になってやらなくなった。一人だと自分のローカルがマスターといってもいいので大規模に比べるとCIのメリットは薄い。
現在関わっているとあるプロジェクトでは、maven-release-pluginを使用してリリースビルドを行っていました。maven-release-pluginを組み込んだプロジェクトをHudsonからキックすることで、リリース用のアーカイブを作成し、リポジトリにアップロードしていました。 先日、このリリース方式を少し見直したので備忘録としてここにまとめておきます。 新方式の内容 新方式では、maven-release-pluginを使用しないやり方にしてしまいました。 具体的には、Hudsonから「clean deploy scm:tag」を実行するというシンプルなやり方にしました。 リリースを行うバージョン番号は、pom.xmlに記述するのではなく、HudsonのParameterized Buildを使ってビルド時に変数として渡してあげる方式にしました。 maven-release
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く