PHPでもHudson使うべし
今までもPHP案件でCIはしているんだけど、環境にはCruiseControl＋phpUnderControlという構成で、これももう古いなぁと思ったのでHudsonに移行してみた。 感触としては、PHP案件でもHudson使うべし、でいいんじゃないかな。 導入 今回導入した環境はCentOS5.3なので、rpmを使ってインストールできる。 sudo rpm --import http://hudson-ci.org/redhat/hudson-ci.org.key wget http://hudson-ci.org/latest/redhat/hudson.rpm rpm -Uvh hudson.rpm なお、当然のことだが、Hudsonを動作させるためにはJDKのインストールが必要なので、先にインストールしておく。 インストールが完了したら自動起動の設定をして、起動する。 /sbin/
HudsonからJenkinsへの移行
HudsonをJenkinsにupgradeしてみた。 下調べ Jenkins公式サイトのドキュメントに詳しく載っている。 Upgrading from Hudson to Jenkins https://wiki.jenkins-ci.org/display/JENKINS/Upgrading+from+Hudson+to+Jenkins When you do "apt-get install jenkins", it will uninstall the hudson package, transfer your /var/lib/hudson to /var/lib/jenkins. Jenkins Debian packages http://pkg.jenkins-ci.org/debian/ Jenkinsは公式のDebianサポートが手厚いので助かる。ただし不具合報告も あ
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
第2回 Hudson事始め | gihyo.jp
この連載では、オープンソースの継続的インテグレーション(CI)サーバであるHudsonを利用した、ソフトウェア開発の生産性向上について解説しています。前回の記事では、Hudsonの紹介と、インストール手順について解説しました。今回は、実際にHudsonでプロジェクトをビルドをする過程をより詳しく見ていきます。 ジョブの種類を選ぶ まずはHudsonの新規ジョブ作成画面(http://localhost:8080/hudson/newJob)に戻りましょう。ここでは、新しいジョブの作成に先だって、ジョブの種類を選びます。これは、IDEに似ています---ここで適切な種類を選択することによって、プロジェクトにあわせて特化したサポートが提供されるわけです。何もプラグインをインストールしない状態では次の選択肢が表示されます。 フリースタイルプロジェクトのビルド本記事では主にこれを解説します。ソースコ
Subversion, Git, Redmine, Hudson – 結局こうなった » tune web
前に考えていた開発プロセスの変更を色々試行錯誤してみてある程度固まってきました。過去の記事は以下からどうぞ。 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しながら更新に追従します。タ
Subversion, Git, Redmine, Hudson – 今考えている連携2 » tune web
Subversion, Git, Redmine, Hudson – 今考えている連携 » tune webでいただいたコメント、実際にやってみて出来なかったことを反映してアップデートしてみました。 前回からの差分がいくつかあります。 git svnの窓口となるリポジトリとgit開発時のcentralとなるリポジトリを分けた。 内部設計書としてソースからDoxygenで生成したものを使っていたことを思い出したので追記 外部との作業項目のやりとりにRedmineからチケット一覧をExcelをエクスポートして使っているのを追記 お互いにパッチを送り合うのをやめて、パッチをもらったらgit-bundle(1)で作成したファイルを送るようにした。これなら物理的に離れていても同じリポジトリを使って作業出来る。 gitとSubversionの橋渡しにかなり悩んだのですが、実用Gitによると、窓口を1つ
Subversion, Git, Redmine, Hudson – 今考えている連携 - tune web
これからが本番、検索エンジンから来た方は先にSubversion, Git, Redmine, Hudson – 現状の連携 » tune webを読むことをおすすめします。上記が週末考えていた「こういう連携なら今の問題点を解消できるかな」と思えるフローです。「こうしたほうがいいよ」とかコメントありましたらお待ちしています。 1番のポイントはバージョン管理システムとしてGitを中心に据えました。社内はSubversionで統一するという規則があるので残すとして、開発チーム内ではgit svnを使ってGit化し、Subversionを直接触らないようにします。協力会社はSubversion縛りが無いのでGitで統一してもらいます。これまでは差分ファイルを送り合っていましたが、Gitを使えばパッチをうまく作り、修正単位でパッチファイルをやり取りすることが出来るでしょう。これまでは複数の修正がま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
