コミットコメントを意地でも書かせたいと思うことがあります。 でも意外と書いてもらえなかったりします。 酷い場合だと バグ修正 とか 対応した だけ書いてあったりします。 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 単にエラーだと障碍だと騒ぐ人達が居るので、コメントの重要性をエラーメッセージで語りかけるようにもしてたりします(笑) 以下はTracLightning環境下で動作する(はず)のScriptです。*1 キーワードの定期的な見直しは必要ですが、コメントを書かないとコミットできなくなるので意識付けを行うのには有用だと思います。コミットコメントが書いてもらえないと悩んでいる方は試してみては如何でしょうか。 ＃結構やっ

Yuki Tamura @isoparametric @finalfusion 簡単にいうとVSSはいつも誹謗されるが、VSSを体験したことがない人は幸せで、VSSは死ね、ということですね？ 2010-02-04 22:39:30

こんな具合で，HudsonのテストトレンドをTracに貼る。 ただそれだけ。 {{{ #!html <h3>テスト結果の傾向</h3> <a href="http://example.com:8080/hudson/job/sample-job/"> <img src="http://example.com:8080/hudson/job/sample-job/test/trend"> </a> }}}でも見た目はそれなり。:-D ウチの会社も，SWEBOKのバッタモン配るくらいなら，これ配ればいいのに。 id:matarilloが書評書いてくれる事を期待してる。:-P ドメイン駆動 (Programmer’s SELECTION) 作者: Jimmy Nilsson,尾島良司,株式会社ロングテール長尾高弘出版社/メーカー: 翔泳社発売日: 2008/03/20メディア: 大型本購入: 8

RedmineやTestLinkなどのツールを駆使してプロジェクト運営すると、チケット、バグ、テストケース、要件などSW開発に関する事象にユニークなIDが振られるのに気付く。 すると、チーム内でこんな会話があって、お互いに事象を認識して共有しやすくなっているだろう。 今日は、チケットxxとyyのいずれを最優先で行うか？ 今、チケットzzの作業状態はどうなっている？ このSVNリビジョンrrの修正理由は、チケットIDがxxにある仕様から来たんだね。 今、あのバグxxのステータスはどうなっている？ テストケースは何番まで実施した？ そのテストケースyyは、要件IDがxxから作りました。 要件IDがxxをテストするテストケースが漏れていますね。 その仕様は、要件ID xxから来ているから、勝手に修正してはいけないね。 過去を思い出そう。 Excelでバグ管理していた時、きちんとしたワークフローを

チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。 それについてメモ。 【1】チケット駆動開発の基本は、チケットファースト。 チケットがXPのタスクカードに相当する。 担当者は、チケットへ作業内容を記入してから、作業を開始する。 開発者は実際、チケットをToDoカードのように用いている。 SW開発のタスクは単にプログラミングだけではない。 お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。 更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。 すると、チケットは終了するペースよりも登録する方がどんどん増える。 何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。 僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登

分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理

原則として、データベースに対する作業は必ずバージョン管理しなければならない、と強く主張した記事を投稿した後で、Scott Allen氏はデータベースのバージョン管理を最大限に利用する手法について詳しく述べている。彼は、ベースラインを作成し、スキーマのリビジョン管理に変更スクリプトを使い、データベースの（ビューやストアドプロシージャ、ファンクション、トリガ等の）プログラムされたオブジェクトを管理し、そしてブランチやマージ処理を利用する、包括的で実用的な手法を紹介している。 Allen氏は自身の経験から学んだことを、関係データベースを使用した開発のための３つのルール(source)として記載した記事を投稿した後で、一連の投稿を始めた。そのルールとは、: 1. 開発作業には、共有データベース・サーバは決して使用してはいけない。 ソフトウェア開発におけるたくさんの便利なもののように、共有データベー

先週、TestLinkのメーリングリストで、コミッタの川西さんとTestLinkのUI改善や運用方法について熱く議論した。 その議論で考えたことについて書いてみる。 【参考】 TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト TEF有志によるTestLink日本語化プロジェクト - TestLink日本語版で始めるテスト管理システム(簡易マニュアル) 僕はTestLinkを3ヶ月運用してみて、Redmineと同様にTestLinkは僕のプロジェクト運営に欠かせないツールになった。 僕のチームでさえも、単体～システムテストのケース数は数千オーダー。 もはやExcelのテスト仕様書で管理するのは非現実的。 しかし、テスト工程をExcelで管理しているプロジェクトが殆どで、どのプロジェクトも結合テスト以降の開発に苦労している。 特に、テストでNGと

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング

SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br

世の中、非常に数多くのIT屋と呼ばれるSIerやソフトハウスが存在し色々仕事を行なっていると思います。ですがこのIT屋と呼ばれる中でも問題のある企業や人というのは数多く存在しています。 開発を行なっている人にとってはプロジェクト管理の話というのはよく耳に目にすると思います。またソースや納品物などで構成管理というのもよく話題になるのではないでしょうか。 しかしIT企業の中で果たしてどのくらいの企業が（ある程度以上の）管理を行えているか、と言われると恐らく半数にも満たないのではないでしょうか。中小企業になればその割合は更に減ることと思われます。 ある会社での話ですが、「ソース管理はしっかり行なっています」とプロジェクトマネージャーや担当SEなどが言っていたのでどれどれと見せてもらったところ、APのソースはビルド時に圧縮し専用のフォルダに時系列で保存していたので「気持ちは微妙だけどまぁいいか」と

RedmineやTestLink、Hudsonなどのツールは一体何を改善して、何を目指しているのか？ 一言で回答するならば、これらのツールはいわゆるSW構成管理をIT化するツールなのだ、と考えればよい。 つまり、下記のイメージだ。 Excelで進捗管理していた →Redmineでプロジェクト管理をIT化 ソースや仕様書を履歴共有できる仕組みが無くファイルを日付管理していた →Subversionで共同所有 Excelでテスト仕様書を管理していた →TestLinkでテスト仕様書をWeb化 手作業でビルドしていた →Hudsonでビルドを自動化(継続的インテグレーション) 我々IT技術者は、お客様がExcelやAccessで運用している業務をIT化、Web化するのが主な仕事なのに、肝心の自分たちのプロジェクト管理の殆どは、Excelで運用して四苦八苦しているだろう。 日本の殆どのSIerで働

チケット駆動開発の戦略part2として、BTSをプロジェクト管理の汎用フレームワークとして使うアイデアをメモ。 #走り書きは後でまとめる。 【元ネタ】 【バグ管理の作法】Trac徹底活用！　第2回：なぜTracの導入に失敗するのか？ 質問「BTSについて教えて下さい」に対するgaryoさんの回答 【1】BTSはシステム開発に特化したToDo用のワークフローとgaryoさんは言っている。 --------↓引用開始↓----------- BTS自体は非常に使いやすいToDo用のワークフローシステムです。 「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理（要求管理）になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。 流れとしてはBTS→BTS+プロジェクト管理　となっていくと思います。 ---------↑引用終了↑---------- BTSのチケ

「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理　にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント