Trac Lighting付属のHudsonをCI以外の目的で使ってみる - almost nearly dead
移行への道は実作業に疲れたので中休みってことで、運用を考えてみましょう。 運用といって一番最初に考えなきゃいけないのがバックアップです。 Trac Lightningにはバックアップ用のスクリプトが付属しています。 2.0.9までは改変しないとshで実行している部分の関係からWindowsのタスクに登録しても実行できませんでした。しかし2.1からの付属のbackup.batについてはタスクに登録することで実行可能になっています＼(^o^)／ となるとバックアップはWindwosのタスクに登録して定期的に実行するのが素直ですが、私は素直に登録するのは止めて『Hudson』を使っています。 Hudsonを使うメリットは 任意のTimingで実行可能 実行結果をクライアントから確認可能 実行のログが勝手に残る 追加処理がbatファイルを作成せずHudson上で登録・管理できる の4点。 本来のH
<改訂>Trac入門 - almost nearly dead
Tracはチームが既に確立している開発プロセスと開発ポリシーに影響をなるべく与えないように最小限のアプローチを提供するWebアプリケーションです。 〔改訂〕Trac入門 ~ソフトウェア開発・プロジェクト管理活用ガイド (Software Design plus) 作者: 菅野裕,今田忠博,近藤正裕,杉本琢磨出版社/メーカー: 技術評論社発売日: 2013/03/08メディア: 大型本購入: 1人 クリック: 13回この商品を含むブログ (5件) を見る通称「白本」ことTrac入門の改訂版を献本頂きました、ありがとうございます。*1 結論から言うと、Excelで課題管理してるところは取りあえず読んでおけ！でしょうか。 そんなことを言うと恐らく「今はRedmineでしょ〜」とか「チケット駆動開発が〜」と言い返す人も多いでしょう。でも「話はExcelの管理、日付フォルダを止めてからだ！出来てない
第1回 Tracをオススメする，これだけの理由：ITpro
Tracの便利さに惹かれるが，インストールに煩わしさを感じ，Tracを簡単にインストールできるTrac Lightning（旧Trac月）の開発を行う。また，日本のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として，プロジェクト管理ツールのTracが注目を集めています。Tracは，Ruby on RailsやSpring IDEなどでも利用されています。本連載では，開発現場を交通整理するために，Tracを利用したプロジェクト管理の効率化を，Tracの基礎から紹介していきます。 ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。 ま
受託開発でTracを導入してよかったことや失敗したこと
Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。 デブサミ2011では、[デブサミ]速報：2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。「チケット管理システム大決戦」というセッションは、デブサミ史上最大の観客数となったと聞いています。 なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか？ 開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、「作業を適切なサイズに分割する」「優先順位をつける」「人をアサインする」という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
