プログラマの思索プログラマの思索IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。長沢さんのモダンなチーム開発環境のフリー利用可能な資料が素晴らしいと思った。長沢さんのJira資料を読むと、RedmineよりもJiraの方がチケット管理の環境が一歩進んでいる印象を持った。その理由を書いてみる。【1】JiraでもRedmineでもチケット管理の手法は同じだし、SVNやGitのような構成管理ツールとチケットを連携する機能も手法も同じ。JiraがRedmineよりも優れている点は、Git連携の機能強化の部分にあると思う。換言すれば、Gitからのブランチ派生、Gitのmasterへプルリクエストする機能が、JiraはRedmineよりも優れていると言える。Jiraでは、Git上でトピックブランチを作ると、チケット画面にブランチのリンクが作られる。障害修正やちょっとした仕様変更が発生したら、トピックブランチを派生させるが、そのトピックブランチがチケットに自動で連動されている。トピックブランチを派生させるタイミングで、チケットへブランチにリンクする機能をフックしているわけだ。Jiraのチケット画面を見ると、ステータスが「提案済み」「オープン」では「ブランチを作成」リンクがあるので、チケット画面上でワンクリックでトピックブランチを関連付けることができる。fork」の運用が、Jiraではチケットの一機能に含まれているので、開発者にトピックブランチの運用を強制できるし、開発プロセスを標準化することもできる。fork」に相当する。トピックブランチは必ずチケットにリンクさせて、相互追跡可能にする。この機能と運用の利点は、トピックブランチの修正が全てチケットに記録されること。Work」の運用のGitブランチ版と言える。fork」をサポートする機能はない。プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインを使うのが良いだろうと思う。fork」をRedmineの一機能に実現できる。Redmineチケットにブランチのリンクを貼ってくれる機能はない。【2】そして、ブランチを作成後、Jiraチケットのステータスが「進行中」ならば、「1個のブランチ」というリンクが表示される。トピックブランチ上の修正は、自動でチケットに記録され、「1件のコミット」というコミットログが残る。Commit」の運用ルールによって、相互リンクされている。この運用によって、なぜこんなIF文の多い修正をしたのか、なぜこんなパッチを作ったのか、という変更理由や本来の要件を追跡できるようになり、その後の機能追加や障害修正で役立つ。#12」のように書く運用を義務付ける必要がある。できれば、Redmineでも、チケット番号をコミットログに書く運用をしなくても、自動でチケットにリビジョンが紐づけられるような機能があればよい。Jiraでは、そのような機能が実現されているのだから。【3】また、Jiraチケットでは、ビルドが終了して通過できれば「1件のビルド」という履歴が残る。Jiraでは、Bambooというビルド管理ツールを組合せて実行するようだ。Pluginで実現できるだろう。Pluginを使えば、チケット履歴にビルド履歴が表示され、ビルド番号とチケットを紐付けることができる。チケット欄に、ビルド成功・ビルド失敗も表示されるので、ビルド失敗ならば、すぐに対処するような運用を課しても良い。r-labs【4】さらに、Jiraのトピックブランチ上で修正が終わり、masterへマージしたい時、プルリクエストを送ることができる。Jiraでは、プルリクエストを送ると、Stashというコードレビューツールでコードレビューが行われ、それがOKなら、masterにマージされるという運用になっているようだ。プルリクエストは必ずコミッタまたはライブラリアンのレビューを通過するという運用が、ツール上で実現されている。Jiraチケットでは、ステータスが「レビュー中」にプルリクエストを送ると、「1件のプルリクエスト」というリンクが貼られる。僕がまだ理解できていない部分は、Jiraのプルリクエスト機能はJiraのどの画面から送信するのか?、ということだ。Gitのトピックブランチへコミットした後、プルリクエスト対象のリビジョンを指定した時に、プルリクエストのボタンがGitリポジトリ画面にひょうじされるのではないか、と想像する。GitのCherry-pickによるマージ作業を実施している時に、プルリクエストを送信できるようにしているのだろう。すれば、Git画面上でプルリクエストを送ると、Jiraチケット画面に「1件のプルリクエスト」リンクを表示するような機能がフックされる仕組みを実現すればいい。そのプルリクエストが承認されて、検証環境へデプロイされれば、Jiraチケットのステータスは「解決済み」へ変わる。最終的に本番環境へデプロイされれば、Jiraチケットは「完了」ステータスになる。Merge」と呼ばれる。プルリクエストを送り、そのプルリクエストが承認されれば、マージされてチケットもCloseする運用だ。Jiraが優れている部分は、プルリクエスト機能を持ち、プルリクエストが承認されるタイミングで、チケットのステータスが自動的に変更される機能を持つことだ。Merge」はデフォルトの機能では実現されていない。プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインが、プルリクエスト相当に似た機能を持っている。@ITにも、その運用方法が一部記載されている。mikoto20000/redmine_git_branch_hookredmine_git_branch_hookでは、チケットIDを含むトピックブランチをマージした時に、自動的にチケットをクローズする機能を持つ。マージするタイミングで、チケットのステータスを「解決」または「完了」へフックして自動で変更してくれる。これは「プルリクエストに似た機能」としか言えない。コミッタまたはライブラリアンがプルリクエストを受け付けて、承認するかReject(差し戻し)するか、という機能は実現されていない。本来なら、この部分もRedmineで実現されるべきだ。本来のプルリクエストは、「リビジョン指定→チケットの自動発行」であり、「チケット発行→リビジョンを指定してパッチを添付」の流れではないのだ。残念だが、redmine_git_branch_hookプラグインは、「リビジョン指定→チケットの自動発行」まで実現してはいない。【5】以上のように、JiraとRedmineのGit連携の機能を比較すると、Jiraの方が優れている機能がある。このようにチケット管理ツールのGit連携に力を注ぐべきなのか?その理由は、モダンなチーム開発環境のフリー利用可能な資料を公開で長沢さんが書かれている。換言すれば、最大の利点は、チケットと構成管理配下のソースのコミット履歴を連携することで、トレーサビリティを完全に実現することだ。(引用開始)したがって、ウォーターフォールだからとか、アジャイルだからとかではなく、追跡可能性が常に維持されている環境にしたいわけですが、そのためには、開発者をはじめとしたチームメンバーにかなりの負担を強いることになります。それこそ、本業よりも、情報収集や更新作業に費やさなければならないくらいに。これをやっておかないと、バグ1件ですら満足に対応できない事態にすぐに陥ります。よい開発環境にすることはとても重要になってきています。(引用終了)WF型開発でも、設計書とソースのトレーサビリティを重視する動きは過去も今もあるが、普通は、Excelの設計書の変更履歴や、Excelのリリース管理台帳で管理しがちだ。それでは、過去の履歴を検索したり、調査するのに、Excelの山から逐一検索する手間がかかる。ソースや設計書は頻繁に修正するから、トレーサビリティを維持するために、Excelの設計書や管理台帳を保守するコストもかなり大きい。変更履歴の入力ミスは結構あるし、修正履歴やリリース履歴が多くなるほど、保守が面倒になって、最終的に誰も保守しなくなる。アジャイル開発では、開発環境をツールでできるだけ自動化し、成果物の構成管理やトレーサビリティをツールで実現する方向へ進化している。Commit」の運用ルールによって、成果物とソースのトレーサビリティを自然に運用できる開発基盤を提供した。【6】しかし、TracやRedmineは、Subversionを前提としているため、Gitのようなブランチ管理とマージ方法とチケット管理ツールを連携する機能が貧弱だ。トピックブランチのように一時的に生成され、その修正パッチをプルリクエストで送り、コミッタの承認を得るという仕組みが、RedmineやTracでは実現されていない。したがって、GitHubで皆が普通に使っているプルリクエストがRedmineで使えない現状があるために、Redmineが最近の開発環境の進化から遅れているようにも見受けられる。JiraはGit連携を強化しているように思える。そもそも現代の開発では、プログラマはGitで構成管理するのが普通であり、タスクをチケット管理するのも普通だ。RedmineではGitとうまく連携できていない課題がある。"最近の開発プロセス事情がすごく参考になる。RedmineやJenkinsはもう古いのかもしれない。非エンジニアが多い環境だと、Redmineは充分有効だと感じています。PRどうやって紐づけるかが悩み。ご指摘の通り、RedmineでもGitHubやJiraのように、チケットにブランチのリンクを付けて、プルリクエストをRedmineのUI上で操作できるようにすべきだと思います。Redmineをもっとアジャイルな開発環境にしたいんですよね。#redmineosaka(2019.01.26)チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)「Agile」カテゴリの記事Scrum@Scale入門のリンク(2019.11.09)Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか(2019.07.03)「アジャイル時代の開発」スライド資料のリンク(2019.06.15)法律のケース問題をモデル化するアイデア(2019.02.11)「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い(2018.07.05)コメントいつもブログを楽しく購読させて頂いております。リンクしてるだけなんですよね。プルリクエストは便利に使えますよー。20:40てつやさん、ご指摘ありがとうございます。プルリクエストはJiraではなく、Stashの機能なのですね。21:14コメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。License:このBlogに書いてある内容を実践する場合、すべて自己責任で行ってください。日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。Redmineによるタスクマネジメント実践技法Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。実践ソフトウェアアーキテクチャソフトウェアアーキテクチャとは何か、アーキテクトの役割は何か、という命題について解説した本。ソフトウェア開発を突き進めると、目に見えない秩序、つまりソフトウェアアーキテクチャの存在にぶち当たる。ソフトウェアアーキテクチャは必ずソフトウェアプロダクトラインにぶつかるように、この本の内容の背後にもソフトウェアプロダクトラインが隠れている。selection)データベース設計を具体例を元に、物理設計や論理設計、データモデルパターンなど網羅的に解説した本。IDEF1のER図はやや取っつきにくいが、一般的なDOAの設計手法はこの本1冊で十分と思う。SELECTION)SEの観点で業務システムに関する業務ノウハウをまとめた本。め、支払サイト、EB連携などの日本特有の業務ノウハウを、SEにとって必要な内容として網羅的にまとめられている。ソフトウェア開発の実践)アジャイル開発におけるテスト管理、リリース管理、ビルド管理などの観点を詳しく解説した本。アジャイルテストの4象限の図は、とても分かりやすい。変化に強い大規模開発を成功させる14のベストプラクティス」と共に、Agile2.0時代においてアジャイル開発に関する必読の書籍の一つ。Archive)XPが出た2000年初頭に出現した初期のAgile開発では、その利点は受け入れられたものの、スケールアップが難しいなどの弱点を言われ続けてきた。Agile開発を大規模プロジェクトへ応用してみようとする動きがある。この本はまさに「アジャイル開発をスケールアップするには何が必要なのか」というプラクティスを具体的に説明しているのが秀逸。手続き型言語と発想が全く異なる点を詳細に説明している。Haskellのプログラムを書く前にこの本で思想を押さえておくと良い。Archive―ソフトウェア開発の課題)構成管理のパターン集。メインラインモデルに関して唯一説明されている構成管理の本。要求をどのようにまとめていくか、解説した本。第5章「変更への対応に関する選択肢」では、結局、アジャイル開発とメインラインモデルで運用している場合はタスクブランチが最適な解決策だと詳しく説明されている。【第2版】PMBOKを初心者向けに解説した本だが、中身はとても詳しく説明されているのでお勧め。プロジェクト管理のノウハウはアジャイル開発に簡単に応用できるので、知っていると理論的に補強できて強みになる。入門Git分散バージョン管理Gitの解説本。Gitの使い方だけでなく、オープンソースの主流の開発手法であるパッチベースの開発フローについても詳しく説明されているのでお勧め。分散バージョン管理Mercurialの唯一の解説本。MercurialのWindowsクライアントTortoiseHgを使いこなすなら、この本は必須。家計簿、プロジェクト管理、医療などの実例をDOAで解説した本。Railsで作れば、業務設計のノウハウも理解できるだろう。開発のプロジェクト管理本の中で3本の指に入る本。マイクロソフト社でのプロジェクト管理の実体験を通じて、プロジェクト管理のライフサイクルに沿ったノウハウが説明されている。本番用ソフトウェア製品の設計とデプロイのためにリリース作業や本番運用、スケールアップに関する技術書。アジャイル開発では頻繁にリリースできる技術力を前提とするため、この本に書かれているノウハウはとても貴重。小規模リリースが何故優れているのか、技術面だけでなくビジネス面でも説明されています。―アジャイルとオブジェクト指向によるソフトウェアイノベーションM.ファウラーが在籍するThoughtWorks社のエッセー。随筆のように書かれていて分かりにくい部分があるが、それらのアイデアは非常に優れていると思う。オブジェクト指向の次に来るIT技術の将来性を語っている。~価値あるソフトウェアを育てる概念と技法~Scrumを実践する時の必読書。イテレーション計画や工数見積もりのノウハウが書かれている。――ソフトウェア開発・プロジェクト管理活用ガイドTracをプロジェクト管理としてどのように使うか、挿話を交えて分かりやすく説明されています。Linux/Windows対応Redmineのインストール方法について詳細に説明されています。-もっと手軽にプロジェクト管理!RedmineをAmazonEC2で稼働する技術が説明されています。現場リーダーや開発者の観点でRedmineをどのように運用すべきか、少し触れられています。PerlはJavaやCと違い、短く書くことを洗練する方向が向いている。ファウラーが業務系Webシステムの設計思想を語り尽くした本。Javaと.NET共に解説しているのが大きな特徴。.NETの本質を理解したいなら、この本が一番いい。(自己実現編))ドラッカーの経験談も含まれた自己実現のための本。現代の全てのホワイトカラーの仕事にマネジメントが必ず含まれているという指摘は鋭い。Language)古いけど、Rubyの生みの親が書いたRuby解説書。書き方の初歩や実行の仕方から、デザインパターンや設計手法、Rubyの隠された機能まで解説している。デザインパターンはRubyのAPIに組み込まれているため、Javaよりもはるかに理解しやすい気がする。最高のチームづくりと革新的な製品の法則アジャイル開発の手法を取り入れた製品開発に関する本。キャリアを考える技術・つくる技術ビジネスリーダーになる人のための転職術の本。キャリア戦略を考える時、担当者、ミドルマネジメント、トップマネジメントにはマネジメントという仕事の断層があるという指摘はどこの業界でも通用する。プロジェクト提唱者の羽生さんが書いた本。後半のプロジェクト管理の章は経験に裏打ちされた話で重みがある。リーンソフトウエア開発~アジャイル開発を実践する22の方法~トヨタ生産方式をソフトウェア開発に応用させた本。「決定をできるだけ遅らせる」「プロセスの無駄を徹底的に省く」等の主張は目から鱗が落ちる。Foundations)数々のユースケース解説本の中で内容がピカイチ。ユースケースの粒度や詳細化の方法が詳しく書かれている。(ブルーバックス)意図を正しく伝えるための表現テクニックを解説した本。プレゼン資料の構成のヒントになる。(朝日文庫)分かりやすい日本語の文章を書くためのテクニックを解説した本。時代を超えたプログラミングの基本原則を説明している唯一の本。Principleやコンポーネントの基本原則も解説されている唯一の本。agile!)日本人が書いたテスト駆動の紹介本。Injectionやトヨタ生産方式の比較などにも触れている。頁数だけでなく内容も分厚い本です。アンチパターン―ソフトウェア危篤患者の救出プログラミング、アーキテクチャ、プロジェクト管理で頻繁に経験する失敗例をアンチパターンとしてまとめたカタログ本。気軽に読めて笑えるが、我に戻ると悲しくなる時がある。デッドライン―ソフト開発を成功に導く101の法則ガモフが書いた物理学の物語を真似て書かれたプロジェクト管理の空想物語。ソフトウェアを開発するチームの運営手法について考えさせられる物語。Series)オブジェクト指向モデリングを突き詰めると結局読まざるを得なくなる。手軽に理解できるらしい。使いがC言語を理解するための本。プログラミング言語の進化の歴史を垣間見る事ができる。オブジェクト指向における再利用のためのデザインパターン言わずと知れたデザインパターン元本。再利用絡みの話は全てこの本のアイデアを元にしている。添付CDにあるhtml化されたデザインパターンカタログが意外と役立つ。Series)ファウラー本で最も読みやすく実践的な本。Javaでオブエジェクト指向プログラムを書くなら、この本をバイブルにすべし。オブジェクト指向分析設計と反復型開発入門プログラマが最も悩む「メソッド配置」は「GRASPパターン」で解決できる。実践UMLは初版で勉強したが、版を重ねるほど内容が濃くなっている。業務別データベース設計のためのデータモデリング入門DOAの観点で書かれた業務設計・データモデリングの本。渡辺さん独特の説明がとても分かりやすい。Railsが流行して更にDOAの必要性が高まったように思う。DBさえできればすぐにWebアプリを作れるから。システムのためのデータモデリング日本人が書いたアナパタ。(日経ITプロフェッショナルBOOKS)やっと出た!まともに使えるUMLモデリング本RSSを表示する。