Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
Gerrit + Jenkins StartUp - MyBetaBook
CIServer http://jenkins-ci.org/ 環境 Gerrit サーバー：Ubuntu Server 11.10 x64 ※Windows にインストールしたかったけど、色々ハードルが高そうなので今回は Ubuntu Gerrit：gerrit-2.2.2.1.war Jenkins サーバー：Gerrit サーバーに同居 Jenkins：1.454 Gerrit Trigger プラグイン：2.5.0 クライアント：Windows 7 x64 ゴールイントラネット内の Windows クライアントから、Gerrit サーバー上の Git に push すると、自動で Jenkins がビルドを行うところまで Gerrit の構成は、 ・DB 以外は、デフォルト(MySQL)の設定 ・メール通知は無し(SMTP サーバーは立てない)
わんくま名古屋 #14 で発表してきた - ぐるぐる～
CI と DVCS を組み合わせて幸せになろう、という話です。 発表資料は ciwankuma.pdf で、手順とかも書いたやつは CI(ipa).pdf です。 今回は、「こういうことができる」というのを重視して、具体的な手順とかは説明しませんでした。レベル 3 くまーだしいいよね？ で、具体的な手順とかは CI(ipa).pdf の方を見てもらえればいい・・・ようにしようとしたのですが、したのですが！まだ全然できてません。 そのうち頑張ります。 ちなみに今回は CI に Hudson を、DVCS に Git を使いましたが、たとえば DVCS は Mercurial でもできるっぽいです。 ただし、Git では post-receive で受け取ってから CI を起動し、失敗したら reset を使って巻き戻しましたが、Mercurial には「受け取った内容は取得できるけどリポジト
Git Pluginの文字化け - ssogabeの日記
Hudson の Git Plugin を使うと文字化けする問題とその解決方法 (不完全) に書かれているとおり、Windows上のHudsonでGit Pluginを使用すると変更履歴の文字化けが発生します。 要点だけ書くと、変更履歴に表示される履歴は"git log"の出力を取り込むのですが、デフォルトではUTF-8で出力されるログをWindowsのデフォルトエンコーディングであるWindows-31Jとして扱ってしまうのが問題のようです。 GitSCM.javaの714行目に、 private String putChangelogDiffsIntoFile(IGitAPI git, String branchName, String revFrom, String revTo) throws IOException { ByteArrayOutputStream fos = new
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ページを開く
Personal Cloud Storage – Microsoft OneDrive