Git・構成管理

2017/04/03

チケット管理システムは作業の構成管理と同じ

Redmineのようなチケット管理システムは「作業の構成管理」という機能を提供しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【1】2000年頃に「達人プログラマー」という黒本を買った。
当時は一流のプログラマになるためのバイブル本だった。

その中の一節に「ソースコード管理システムは、ソースのUnDo機能を提供するシステムである」という文言があり、すごく印象に残った時があった。

実際のプログラミングでは、自分の思考内容をソースコードに表すが、最初から一番良いソースが書けるわけではない。
試行錯誤しながら、ロジックを切り貼りしたり、分割したり、いじくったりする。
すると、その履歴を残したくなる。
途中で、テキストエディタでUndoやRedoするように、ソースコードも過去に遡ったり、途中のソースに戻りたくなるからだ。

つまり、ソースコード管理システムは「プロジェクトレベルでのタイムマシンというべき一つの巨大なUnDoキー」なのだ。

特に、昨今は、GitHubやGitを使っていると、masterとは別に、ブランチ上で新しい機能を実験しやすくなった。
また、たくさんのブランチを派生させても、あるタイミングでマージするためにプルリクエストを送ればいい。

【2】チケット管理システムがないプロジェクトで、作業管理を見ていると、作業の履歴やUnDo、ReDoが欲しくなる時がある。
ISO9001のQMSの運用を行なっている現場で、そんな状況を見た時がある。

ISO9001の品質管理マネジメントシステムでは、全ての作業は記録として残さなければならない。
普通は、作業依頼書のようなExcel帳票に、作業発生から作業終了までの履歴を記録する。

しかし、普通は作業依頼書だけでは話は終わらない。
Excel帳票としては、作業依頼書と、仕様変更の設計書やリリース手順書のような作業手順書とペアが必要になる。
実際の細かな仕様、詳細なリリース手順は、作業依頼書には書ききれないからだ。

それら2個のExcel帳票を、作業状況ごとに管理する必要があるが、これが結構面倒だ。
普通は、作業中のステータスで滞留しがちで、なかなか終了しにくい。
依頼する人と作業する人は別々なので、作業連携がすごく悪いからだ。
今、どの作業ステータスにあるのか、最新状態が反映できていない。

この問題の原因は、作業のステータス管理ができていない点にある。
それは、Excelの作業依頼書には判子欄があるが、それはRedmineのチケットのステータスと同じだ。
Redmineでやれば、すぐに解決できる。

また、Excel帳票の版管理で、依頼する人と作業する人が混乱する場合もある。

依頼する人は設計書を用意するが、割り込みの要望や考慮漏れで設計書を書き直したりする。
すると、どの設計書が最新版なのか、作業する人は混乱しがち。

この問題の原因は、設計書の版管理、つまり設計書のバージョン管理ができていない点にある。
結局、Excelの設計書もSVNやGitでバージョン管理すべき対象なのだ。

Excel帳票で作業依頼書と設計書をやり取りしているISO9001の運用では、プロジェクト数が増えるほど、混乱しがちになる。

【3】そんな状況を見ると、Redmineのようなチケット管理システムは、設計書のバージョン管理と同じように、作業のバージョン管理を提供しているように思える。

設計書のバージョン管理が必要な理由は、設計書の最新版がどれなのか、を明確にする必要があるからだ。
リポジトリを見れば、タグ付けされた設計書が作業対象だ。
設計書の履歴は、リポジトリのリビジョン履歴を見ればいい。

同様に、作業依頼がチケットとして発行されれば、チケットのログに全ての作業履歴が記録される。
作業中に課題が発生したり、設計者と実装手段を議論したり、間違った実装を障害として把握して直したり、色々あるだろう。
そういう履歴があるからこそ、作業依頼書の内容に記載された「作業」は、過去にいつでもさかのぼれる。

つまり、チケットは「作業内容のタイムマシン」だ。
「昔にさかのぼって、どんな作業が行われたのか、を追跡できる」点がチケット管理システムの最大のメリットだ。
これは「トレーサビリティ」という機能を提供している。

チケット管理システムが持つトレーサビリティは、本番稼動後の派生開発や障害修正で、大きな威力を発揮する。
本番稼動中の汚いソースコードには、過去の障害修正によるパッチの意図がある。
その変更の意図を無視して、ソースを勝手に弄ってはいけない。

また、プログラマは派遣契約で出入りが激しい。
3年前に書いたプログラマがいなくなれば、そのソースコードは、どんな意図で書かれたのか、その仕様はどういう経緯で決まったのか、誰も分からなくなる。
しかし、チケットにその作業履歴が残っていれば、その作業履歴に紐付くソースの変更履歴を辿ることで、パッチの意図を把握することができる。

ソフトウェア構成管理は、ソースコードのバージョン管理だけでは足りない。
作業の構成管理というべきチケット管理システムも必要だ。

IT化されていないISO9001のQMSで、作業依頼書と設計書という2種類のExcel帳票が運用上必要であるという事実は、ISO9001の背後にある構成管理には、成果物のバージョン管理と作業の履歴管理(トレーサビリティ)という2種類の構成管理が必要なのだ、という思想が背後にあるように思う。

【追記】以前、岡本さんから、「Gitポケットリファレンス新版」を頂きました。
構成管理の仕組みを理解する上で、Gitが分かれば、過去のバージョン管理ツールも分かるだろうし、チケット管理システムの必要性も見えてくるのではないか。
Gitポケットリファレンス新版」は、Gitを知る上でとても読みやすい本でお勧めです。

| | コメント (0)

2016/09/15

GitHubにかんばんライクなチケット管理機能が付いたらしい

GitHubにかんばんライクなチケット管理機能が付いたらしいのでメモ。

【参考】
[速報]GitHub、かんばんライクな新機能「Projects」発表。GitHub Universe 2016 - Publickey

[速報]GitHub、コードレビューのための新機能を発表。コードの行ごとや課題ごとにコメント可能。GitHub Universe 2016 - Publickey

Chrome Extension - GitHub をより便利にしてくれる『ZenHub』の使い方 | phiary

akipiiさんのツイート: "プルリクできる構成管理とカンバンが使えるタスク管理で十分かもしれない。RT @kyon_mm: なんかわからないけど、RedmineでできることをどんどんGitHubがやっていくのをみていて、おもしろい。そんなもんなんだろうなぁ。みたいな。"

Kさんのツイート: "GitHubにカンバンができたことで、ソフトウェア開発のみに特化した小規模なチームは、RedmineやJIRAやTracやTrelloなどの他のツールで管理する必要がより無くなるのかもしれないなぁ。"

Kさんのツイート: "@Will_meaning インフラ周りやプロジェクト管理としてのRedmineやJIRAなどの利用はまだまだ残ると思います。"

【1】GitHubはやっぱりプルリクエストが気軽にできるのがすごくいい。
ソース管理がソーシャルなやり取りになっているのがいい。
Wikiも使いやすい。

しかし、GitHubはIssue管理がしょぼかった。
タスクがどんどん出てくると、Issueが埋もれてしまうし、タスクのステータスが見えづらい。
チケットのワークフロー、チケット一覧のビュー、チケットの階層化などをやりたくなってくる。
チケット管理で全てのタスクの見通しを良くしたいと思うと、Redmineのチケット管理のような機能が欲しくなってくる。

プルリクエストが使える構成管理と強力なチケット管理の連携機能が欲しいのだ。

GitHubにかんばんのようなIssue管理機能が付けば、Redmineほどの厳格なチケット管理が不要ならば、十分だろうと思う。
今、プロジェクトがどの程度のタスクが滞留していて、今誰がどのIssueを担当しているか、見えれば十分と思う。

【2】チケット駆動開発が当たり前の環境になるまで普及した現在、チケット管理は今後どの方向に進化していくべきか?
僕の直観では、一つはアジャイル開発に適したビューの提供、もう一つは大規模な作業管理に向いたビューの提供だろうと思う。

アジャイル開発に適したビューとして、タスクかんばんとプロダクトバックログの2つがあり、スプリント管理ができて、アジャイル開発で使うメトリクスをリアルタイムに出力する。

一方、大規模な作業管理に向いたビューとしては、MSProjectのように、ガントチャート・リソースヒストグラム・EVMの3つのビューを交互に切り替えて操作できるような機能が欲しい。
さらに、PMBOKやITIL、ソフトウェア工学の観点のビューが付属していればなお良い。

その他に、サポートデスクのCRM、BPMのような事務処理ワークフロー管理の観点のビューもあれば、より汎用的に使えるだろう。
実装上は、入力されたチケットに対し、チケットのビューをRedmineプラグイン化するだけのことだ。

チケットのビューを誰がどんな時に、どんな目的で利用したいのか?

【3】実はRedmineは、日本の利用シーンとしては、アジャイル開発よりもWF型開発に向いているから、日本で普及しているのではないか、という仮説がある。
他の理由については下記に書いた。

Redmineが日本人好みのツールであるという仮説: プログラマの思索

その仮説とも合わせて考えてみたい。

| | コメント (0)

2016/04/28

WindowsOS上でbash環境を使うためのツールのリンク

WindowsOS上でbash環境を使うためのツールのリンクをメモ。

【参考1】
【レビュー】Windows OS上で超気軽にbash環境を楽しめる「clink」 (1) コマンドプロンプトとの互換性も十分 | マイナビニュース

Clink

clink/clink.md at master ・ mridgers/clink

mridgers/clink: Bash's powerful command line editing in cmd.exe

コマンドプロンプト派なら入れておくべき機能改善ツール『Clink』 | ライフハッカー[日本版]

【参考2】
Windows用のお手軽なUNIXシェル環境としておすすめなGit For Windows (Git Bash)

Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

WindowsにおけるGit利用環境は整った: Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

GitHub for Windowsの導入について(追記あり) - 鎌玉のよしなしごと

ちょっとした些細な作業をルーチン化したい時、Windows上でシェルスクリプトを書きたくなる。
bashのスクリプトをWindows上でそのまま動かしたくなる。

以前はCygwinを使うのが普通だったが、たくさんのライブラリをダウンロードする必要があるし、設定が結構面倒なイメージがある。

ネットで探してみたら、clinkというツールがあるらしい。
他には、Git For Windowsがいいらしい。
以前は日本語のパス名だとうまくcdできなかったが、GitHub for Windowsの導入について(追記あり) - 鎌玉のよしなしごとによれば、幾つかの設定を追加すれば使えるみたい。
実際、フォルダ上で右クリックして、GitBashを開くと、Unixコマンドも普通に使えて便利。
過去のシェルスクリプトをWindows上で動かしたりして試してみる。


| | コメント (0)

2016/01/03

技術的負い目の記事がすごい

技術的負い目の記事がすごいのでリンクしておく。

【元ネタ】
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。
そう簡単にリファクタリングしにくい。
そんな中で色んな対応をされている。
以下、自分が今後参考にしたいためにメモ。

【1】JDKが古い。

古いJDKはセキュリティホールもあるだろうから危険。
性能要件も低いだろう。

→JDK6からJDK8へバージョンアップ。
 Gradleでビルド環境を作る。
 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。

【2】コード重複率も多く、デッドプログラムも多い。

長年運用したシステムは、デッドプログラムが多い。
でも、リスクがあるから、デッドプログラムをうかつに消去できない。

→リファクタリング、Jenkinsで単体テスト自動化、Sonarでソース解析、Githubフローで開発プロセス改善で30万行を削除。
 その結果、その後の機能改善もやりやすくなった、と。

【3】エラーログ件数が3000件以上もあり、エラーが常態化している。

この状況もよくある。
エラーログが全く使いものにならないから、本来の障害を検知しにくいし、代わりのエラー検知の手作業が増えてしまい、システム運用のコストが大きくなる。

→エラーログ件数のグラフ化して見える化。
 エラー件数が多いエラーをパレート分析して、1つずつ対処していく。
 ログレベルをFatal~Debugまで整理。
 エラーログから検知した内容は、ChatWorkに通知する。
 その結果、一日平均50件ほどまで減らすした、と。

【4】デプロイによってシステムが一時的に壊れる

古いシステムほど、リリース作業のプロセスもデプロイツールも古いままなので、手間がかかりやすい。
その分、リスクも大きい。

→Tomcatを停止する前に、ロードバランサーにワーカーを切り離させる。
 trunkのみでの運用をやめ、プルリクエストベースの開発プロセスとした。
 Tomcatの起動後にアプリケーションがリクエストを処理できるようになるまで待機する処理を入れた。
 リリース内容はChatWorkに通知する、と。

他にも、認識されていない単一障害点、ワイルドなバッチ処理など、たくさんあって、技術とプロセスの両方で改善されたテクニックやプラクティスがすごく参考になる。

| | コメント (0)

2015/09/05

Excel管理台帳から今時の開発環境へ

大規模SIerの今時の開発環境の記事があったのでメモ。
すごく参考になる。

【元ネタ】
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ!! - そこに仁義はあるのか(仮)

受託開発でGitとmavenを使って開発をしている - そこに仁義はあるのか(仮)

はてなブックマーク - これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ!! - そこに仁義はあるのか(仮)

バージョン管理はファイル名に日付つけて残しといて、デプロイは紙の申請書に10個ぐらい判子もらって水曜日までに提出すると翌週には反映される。課題管理はもちろんEXCEL。これが大規模SIerの実際の開発スタイル はてなブックマーク - hobbiel55 のブックマーク - 2015年9月3日

【1】はてぶが1千以上も付いていて、皆の興味が向いているのが分かる。
環境は、GitBucket+Jenkins+Redmine+SonarQube+Artifactory。

GitHub Enerpriseを使わないなら、自社サーバーでこんな開発環境を作るのだろうと思う。
MS製品なら、TFSでほとんどカバーされるのだろう。
Jiraなら、アトラシアン製品でほとんどカバーされるのだろう。

以前の僕は、Redmine+Subversion+TestLink+StatSVNの環境を作っていたが、今なら、こういう環境の方がはるかに開発効率もいいだろう。
全てオープンソースなので、社内にサーバーさえ用意できれば、開発者自身で開発環境を全て構築できる。

【1-1】developブランチをニアショア・オフショアの開発チームごとに任せて、プルリクで日本拠点のチームが受入するやり方は確かに良い。

今までなら、このやり取りをExcel管理台帳にCVSやSVNリビジョンを指定して、ライブラリアンが管理台帳を参照してマージし、タグ付けする作業が必要だった。
そういう手作業が全てGit上でオンライン化されることで、作業履歴も残るし、プルリクがコードレビューや受入れ検査も兼ねるようになる。

【1-2】SonarQubeというツールも初めて知ったが、昔のSonarのグレードアップ版みたいなものかな。
ソフトウェアのメトリクスは、自動収集・自動集計して、いつでも開発者が見れる状態にした方がいい。
自分のコードがどのように客観的に見られているのか、と日本人の開発者は意外に意識するから。

SonarQubeでプログラムの品質管理をはじめる(概要) - Qiita

ユカイ、ツーカイ、カイハツ環境!(17):コード探知機「Sonar」でプロジェクトの深海を探れ! (1/4) - @IT

【2】もはやチケット駆動は当たり前であり、ソフトウェア開発の3種の神器も全てオープンソースで揃えることもできる。

こういう開発環境のネタは個人的に好き。
なぜなら、アジャイル開発の基本精神は、サーバーントリーダーシップのようなマネジメントよりも、現場でいかにプログラミングしやすくするか、という環境整備にあるような気がするから。

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索にも書いたけれども、頻繁にリリースできる開発インフラがあれば、プロジェクト管理を意識せずにコーディングだけに専念すればいい。

XPが生み出したソフトウェア技術のプラクティスは、オープンソースの各種ツールの一機能に実装され、最終的には、一つのプロジェクト管理サーバーのようなものに実現されるのだろう。

つまり、ソースの共同所有、継続的インテグレーション、ペアプログラミングによるコードレビュー、コーディングルールの標準化などは、上記の開発環境の一部に含まれることで、開発者はプラクティスを意識しなくても、ツールに慣れることで自然に良い習慣が身に付く。

よりアジャイルに開発していくために、そういう開発基盤が必要。
そこにアジャイル開発が概念的に生み出したプラクティスを注入することで、プログラマにプロジェクト管理が不要な環境を提供する。
Excel管理台帳による煩雑なコミュニケーションはそもそも不要。

その辺りもまとめてみたい。

| | コメント (0)

2015/06/11

GitHubはオープンソースのプロセスを標準化した

「GitHubはオープンソースのプロセスを標準化した」記事の感想をメモ。

【参考】
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015 - Publickey

akipiiさんはTwitterを使っています: "そうなのか?RT @koyhoge: Redmine にパッチを投げる不便さを解決するところから GitHub は生まれたのか。 #awssummit #key02"

akipiiさんはTwitterを使っています: "ふむー。RT @toshihirock: Github以前、svnにもアクセスできないからソースコードをダウンロードして、パッチ作ってみたいな大変。そしてやりとりをredmineで。そして個人的な功績は残らない。しんどい #AWSSummit"

akipiiさんはTwitterを使っています: "同感。RT @mesaka2009: 昨日のGithubの人の講演。たった10年でこれだけ変わった。と言う事の一つに、Redmineでやり取りしていたのがGithubになった。とあったけど、日本の企業にはまだまだRedmineは現役だぞい!"

GitHubの偉大さは、Publickeyの記事の通り、オープンソースの開発プロセスの事実上のデファクトスダンダートになったことだろう。
オープンソースで何かしらの貢献をしたい開発者は、GitHubにアカウントを持ち、フォークしてパッチを送る方法をプルリクするやり方を学ぶ必要がある。
GitHubにないソースの保守は、とても面倒だ。

上記の記事の通り、以前は、diffコマンドを作り、patchコマンドでtrunkにDiffパッチを取り込むやり方を行なっていた。
そして、メーリングリストでダラダラとやり取りしていた。

あるいは、ReviewBoardというコードレビューWebシステムがあったが、その機能は、Subversionのtrunkに対し、patchを添付するとWeb上でDiffが表示されて、そのDiffを中心にコミッタと開発者がコメントし合うやり方だった。

ReviewBoardでプレコミットレビュー: プログラマの思索

ReviewBoardを使うプロセスとは?: プログラマの思索

でも、GitHubのおかげで、全てはプルリク駆動の開発プロセスで標準化された。
好きなだけフォークして、ブランチを作り、マージ依頼をプルリクすればいいだけ。
このやり方で、より高速な開発が可能になったし、ソースに関するすべての作業がWeb上で公開されているので、開発プロセスの透明化にもつながった。

但し、Redmineを過去の遺物で紹介されたのはちょっと違和感があった。
RedmineとGitHubは、利用シーンも使い方も目的も全く違う。

GitHubはソース中心のプルリク駆動開発であり、Issue管理の機能は正直弱い。
チケット集計機能もないし、Issueにコメントをやり取りするのが中心で、ステータス管理もシンプル。
チケットはフロー型。
チケットは完了したら捨てる。
チケット管理の機能はそもそも不十分だし、それでいいと割り切っている。

逆に、Redmineはチケット管理機能がすごく充実している。
Redmineのチケットはストック型。
チケットに作業や課題、障害などの情報を記録し、後で検索できるように蓄積していくべきもの。
Redmineは「チケット駆動開発」が本来の使い方だと僕は思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

つまり、RedmineとGitHubの違いは、チケット駆動開発とプルリク駆動開発の違いであり、その優劣を言い合っても意味が無い。
使う用途が全く違うのだから、利用シーンに応じて使い分ければいい。

| | コメント (0)

2015/04/25

Gitでやらかさないための事前予防策や奥義のTIPS

Qiitaに掲載されていた「Gitでやらかさないための事前予防策や奥義のTIPS」が参考になったのでメモ。

【参考】
Gitでやらかした時に使える19個の奥義 - Qiita

Gitでやらかさないための事前予防策 - Qiita

Gitはコマンドが奥深い。
コミットの歴史を改変できるから、masterに取り込む時に、綺麗なコミット履歴になるように修正できるのが良い。

上記の記事で参考になったのは、コミットメッセージの書き方の解説。
コミットメッセージのフォーマット、コミットメッセージで使用する英単語をあらかじめ決めておく点はすごく参考になった。
確かに、あまり気にせずにコミットログを書いていて、後から自分でも理解不能になる時があるから。

CVS、SVN、Gitというバージョン管理の歴史を振り返ると、たかがバージョン管理といえども、開発環境はどんどん進化している。
その進化と共に、開発プロセスもどんどん変わってきて、もはやアジャイル開発はオープンソースでは当たり前。
先日のAgileJapanで参加者を話していて、つくづく感じた。

その辺りも今後追いかけていく。

| | コメント (0)

2015/04/05

チケット駆動開発の理想と現実

知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。
あくまでもメモであり、主張はない。

【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。
しかし、実際の数多くの現場はそうではないですよ、と。
丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。

【1-1】チケット駆動開発はXPに影響を受けすぎているのでは?、と。
世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。
Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。

全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。
WF型開発の現場では、そうではない。
チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。

【1-2】チケット駆動開発のプラクティスは実際の現場では使いづらい時がある、と。

たとえば、No Ticket, No Workは確かに理想だけれども、実際は、チケット管理の対象は進捗管理だけでない。
また、Redmineというツールに頼りすぎるのも問題だ、という認識が現場にはある。

たとえば、No Ticket, No Commitもプログラマにとって評判は良くない時がある。
コミットログに逐一チケットNoを書くのが億劫だ。
また、ちょっとしたリファクタリングのコミットにもチケットNoを紐付けるべきなのか。
頻繁にコミットする場合、チケット一覧のコミット履歴が多すぎて、結局あまり使えない、と。

特に、GitHubのようなプルリクが使えないのもいまいちだね、と。

【2】僕が思っているチケット駆動開発は、理想にすぎないのかな。
「ソフトウェア開発の基本原理は、XPの小規模リリースと同じ」「頻繁にバージョンアップしながら、品質も機能も向上させていくのがソフトウェア開発の王道」と僕は思っているけど、違うのかな。

日本のソフトウェア開発は、製造業の成功体験を引きずりすぎていて、一度決めたら進路変更できない計画主導の開発プロセスにこだわり過ぎている、と思っているのは違うのかな。

僕の考えでは、チケット駆動開発は、アジャイル開発を実装する一プロセスであり、最も自然にアジャイル開発を実践できるプロセスの一つと思っているけど、そうではないのかな。

【3】チケット駆動開発は、フロー型プロセスでもあり、ストック型プロセスでもある二面性が利点を増幅させていると思っている。
チケットはカンバンでもあり、作業指示書や障害管理票のような記録できる帳票の二面性を持つ。
その部分の相互作用がすごく面白い。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【3-1】「Issue」を「チケット」と訳したRedmineは偉いと思う。
チケットはメタな概念。
「Issue」を「問題」「課題」に訳してしまったら、タスク管理に使う発想は無かっただろう。
Redmineを障害管理やタスク管理だけでなく、ヘルプデスク管理、インシデント管理、台帳管理、議事録の管理、農作業の予実管理などに使おうという発想すら出現しなかっただろう。

akipiiさんはTwitterを使っています: "問題以外のスコープも含まれるからね。チケットはメタな概念かな。RT @g_maeda: @cyber_yoshida 当初は「問題」と訳されていましたがよい訳語がみつからず「チケット」になりました。先行して普及していたTracやMantisなどのBTSを参考にしたと思われます。"

akipiiさんはTwitterを使っています: "課題以外の用途があるからね?。台帳管理や農作業、議事録、などなど。チケットはメタな概念かな。RT @nmrmsys: @g_maeda @kawanishi_ameya issueって、やっぱ課題ではダメなんですか?"

【3-2】ソースそのものに修正履歴を残すのではなく、コミットログやチケットに記録することで、ソースは常に最新で綺麗な形に残せる。
そして、コミットログやチケットというメタな概念に修正履歴や変更理由が残るので、メタな開発プロセスをチケット上に実現できる。
さらには、蓄積されたコミットログやチケットを集計したり検索することで、エンピリカルなソフトウェア工学の知見を適用して、メトリクスの採集による傾向分析ができる。

さらには統計学やビッグデータを適用して、仮説に基づくプロセス検証ではなく、データ主導によるプロセス検証もできるかもしれない。

SCMコミットログはファイルのメタ情報: プログラマの思索

チケット駆動開発の展望part2: プログラマの思索

akipiiさんはTwitterを使っています: "良い記事。僕もPrivateファイルはMercurialで管理している。コメントや履歴のようなファイルのメタ情報はコミットログで保持すべき。重要ファイルはSubversionで管理する - Basic http://t.co/kpARpCMu"

【3-3】チケット駆動開発のもう一つの側面として、パッチ駆動開発の顔もある。
パッチをチケットに添付して、コードレビューのやり取りをする。

Redmineによるチケット駆動開発はパッチ駆動開発と同じ: プログラマの思索

パッチ駆動が重要である理由は、「ソフトウェア開発は頻繁なバージョンアップで品質も機能も改善していく」手法が基本原理ならば、変更管理や構成管理が非常に重要になるからだ。
でも、この開発プロセスは、GitHubのプルリクエストが普及した現在、正直古くなっている部分もある。

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

チケット駆動開発にGitの良さも組み込んで、もっとアジャイルな開発基盤にしてしまいたい妄想を今後も考えてみる。

| | コメント (0)

2014/11/24

書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク

実践反復型ソフトウェア開発」の著者の方がフィードバックの資料をまとめていたのでメモ。

【1】「実践反復型ソフトウェア開発」は、アジャイルな開発環境作りに興味のある開発者にお勧めだと思う。
理由は、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念が整理されてまとまっているからだ。

SIの現場では、「実践反復型ソフトウェア開発」に書かれているような概念が暗黙知になっており、本来はベストプラクティスないし守るべき規律としてチームが実践すべきルールが徹底されていない場合が多い。
あるいは、10年以上も以前の古い技術に固執しすぎて、アジャイルな開発を阻害している原因になっている時も多い。

だから、そんな現場には、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念や、ベストプラクティスから得られた形式知をチームで共有して実践すべきだと思う。

僕の感想は以前書いた。

実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索

実践反復型ソフトウェア開発の読書会ログ: プログラマの思索

実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理: プログラマの思索

「反復型ソフトウェア開発」はソフトウェア工学の良書: プログラマの思索

【1】「実践反復型ソフトウェア開発」の良い所の一つは、ブランチ管理のポリシーやメインラインモデル、マージ手法について一通りの説明がされていることだ。
構成管理はソフトウェア開発者なら誰もが必要とするお作法なのに、構成管理に関する本は「実践反復型ソフトウェア開発」以外には「パターンによるソフトウェア構成管理」ぐらいしかまともな本がない。

【2】また、「実践反復型ソフトウェア開発」では、チケット駆動開発という言葉は明示していないが、チケット駆動開発に必要な概念やプラクティスが暗黙的に紹介されている点も良い。

例えば、障害管理の下記の運用ルールは、チケット駆動開発のプラクティスにそれぞれ対応している。

・バグを発見したらすぐに起票する→バグをタスク全般に拡張すれば、「Ticket First」
・一件一葉の原則(バグ1件に対し1枚のバグ票を起票する)→「One Matter, One Ticket」
・バグ報告票というボールでキャッチボール→「ペア作業」
・コミットして完了にするタスクは、そのチェンジ番号をタスク票に記入して閉じる→「No Ticket, No Commit」
・バグ報告票がなければ作業を開始しない→「No Ticket, No Work」

【3】個人的には、バグ追跡システム(BTS)が仕掛けかんばんの構造に似ている(P.204)という指摘が一番役立った。
「かんばんがなければ部品の製造を開始しない」「かんばんを通じて、部品や工程の作業実績と追跡する」という仕組みは、まさにチケット駆動開発そのものだ。

とはいえ、仕掛けかんばんがBTSと全く似ているわけではない。
TPSの仕掛けかんばんが、かんばんの流通量で在庫を制御するのに対し、BTSでは、障害票はふやしたくもないのに、いくらでも後から湧き出てくるから、障害の件数を人為的に制御することはできない。

だから、障害票の優先順位付けやチケットのトリアージ、担当者のアサインポリシーで制御する必要がある、という指摘は全く同意する。

トヨタのかんばん方式とバグ追跡システムの密接な関係: プログラマの思索


| | コメント (0)

2014/10/24

開発環境に関する最近の動向

開発環境に関する最近の動向について、リンクしておく。

【元ネタ1】
1分でわかるJIRAの現在と進化

夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ

KDDI Cloud Blog | アジャイル開発を支える舞台装置、最適な開発ツールを求めて

アジャイルな現場になるためのツール環境【ET West】

序盤、中盤、終盤、隙がないよねさんはTwitterを使っています: "Redmine/Jenkins とか使ってる方たちはどうやって追跡できるようにしてるのか気になる / “KDDI Cloud Blog | アジャイル開発を支える舞台装置、最適な開…” http://t.co/CQZtge6sVW #development #atlassian"

Jira+GitBucket+Stash+Bambooの製品群を見ると、Jiraチケットが起点になって、人と成果物が密接に関連付けられている。
そのおかげで、トレースするのが非常に簡単になっている。
障害の影響調査、変更理由の調査などで、Jiraのトレーサビリティが非常に役立つ。

同様の環境は、Redmine+GitLab+Jenkinsでも可能だと思う。
但し、Jiraに比べると、トレーサビリティの保証が弱いと思う。

RedmineチケットとGitのソースは相互リンクできるし、Jenkinsのビルドログからも追跡できる。
しかし、GitHubのような仕組みの実現は多分弱い。
Gitでプルリクエスト、フォーク、マージ(Pull)のイベント操作で、チケット発行やチケットCloseも自動で実現したいのだ。

RedmineをGitHub化するアイデア: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

【元ネタ2】
JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこね

インフラの継続的デリバリー - naoyaのはてなダイアリー

伊藤直也氏の記事のリンク: プログラマの思索

akipiiさんはTwitterを使っています: "テスト環境はDockerでビルド単位に作っては使い捨て。時代はこのレベルまで進んできたのか。JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこね http://t.co/x8gFT5rirk"

「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」 チャド・ファウラー氏 - Publickey

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

アジャイル DevOpsの記事: プログラマの思索

アジャイル開発を実施するための開発基盤の最新動向を抑えたいなら、最近は伊藤直也さんの言動に注目すればいいだろうと思う。
Webの記事を読むと、非常に示唆に富む内容が書かれている。

単に、GitHubを使ったアジャイル開発だけではない。
インフラ構築も自動化したり、TDD+CIをサーバーインフラ構築にも適用してしまう。

インフラの継続的デリバリー - naoyaのはてなダイアリーによれば、「DNS レコードを Pull Request を merge した契機に自動で更新」するとか、こんな所までインフラ構築はプログラミング化されているのか!と驚かされる。

「イミュータブル・インフラストラクチャ」という言葉も、伊藤直也さんのWebのどこかの記事で知ったし、インフラ構築の自動化周辺は要注目。

JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこねでは、さらに、テスト環境はDockerでビルド単位に作っては使い捨てしている。
ここまで進化できれば、もはや開発環境と本番環境の違いはないに等しい。
本番環境もすぐに作れるから。

本番環境が重くなったら、Dockerで新規に作ってリリースするだけでいい。
本番環境は、データ移行はのぞいて、環境が綺麗な状態から稼働できるわけだ。

以前から、クラウドやインフラ構築の技術をアジャイルな開発環境へ適用する動向にずっと着目していたが、もはや今となっては当たり前みたいだ。

さらに、伊藤直也さんのWebの記事を読むと、単にアジャイル開発を導入するだけでなく、チーム運営をオープンソースに似た活動にする考えを持っている点に興味が惹かれる。
ツールを使ってアジャイルに開発するのではなく、開発チームの組織化にも有効に使っているわけだ。
チーム内のコミュニケーションをいかに活発化し、見える化し、透明化していくか、にすごく力点を置いている。
その辺りに僕はすごく興味がある。

この辺りの動向も注目していく。

| | コメント (0)

より以前の記事一覧