ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Changes between Version 3 and Version 4 of pne-book-9-4


Ignore:
Timestamp:
Feb 27, 2008, 5:17:22 PM (12 years ago)
Author:
imoto
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • pne-book-9-4

    v3 v4  
    11= OpenPNEのチーム開発 =
    2 
    32
    43解説:小川、海老原、酒井[[BR]]
     
    65
    76 === 概要 ===
    8 
    9 
     7 現在、OpenPNEは基本的にチーム開発で開発を進めています。[[BR]]
     8 その理由としては、OpenPNE開発の場合はバグ修正、ドキュメント、開発など仕事が多岐に渡り個人がバラバラに動くよりチームとして役割を決める方が開発の効率が上がるということが挙げられます。しかし、チーム開発をする上でいくつかの障壁もあります。[[BR]]
     9 中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れなければ、開発効率も落ちチーム開発をして開発を行うメリットは少なくなります。[[BR]]
     10 そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNE流のチーム開発を見て行こうと思います。[[BR]]
     11
     12
     13 === 目次 ===
     14 
     15 
     16== リリースガイドライン ==
     17実際のOpenPNEのチーム開発を見る前に、まずはOpenPNEのリリースガイドラインを一部参照しながら、OpenPNEのリリース方針を見てみましょう。
     18
     19OpenPNEには現在「開発版」「安定板」という2つの製品があります。[[BR]]
     20今回は、安定版の開発を中心に見ていくので開発版のガイドラインは割愛します。もし開発版のガイドラインを参照したい方は「OpenPNE開発のガイドライン(http://trac.openpne.jp/wiki/pne-guidelines)」の開発版リリースガイドラインを参照してください。[[BR]]
     21それでは簡単に安定版リリースガイドラインを見ていきましょう。[[BR]]
     22
     23
     24 === 安定版リリースガイドライン ===
     25 OpenPNEには、リリースガイドラインがあります。基本的に、このガイドラインに則ってOpenPNEの開発を進めています。
     26
     27 OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のから3ヵ月ごとから6ヵ月ごとに変更になったことによってこのリリースガイドラインも大きく見直されました。[[BR]]
     28 中でも大きく見直された部分は機能追加条件です。3ヶ月から6ヶ月になったことで、製品の信頼度は上がるが、新たな機能の追加まで期間が長くなるというデメリットも出てきました。そこで、この機能追加条件をリリースガイドラインに追加し、機能追加条件を満たしたものであれば、安定版にも機能が追加されるようにしました。この機能追加条件を導入したことによって、OpenPNE開発版のバージョンアップが3ヶ月から6ヶ月に変更になっても機能追加がされ常に新しいOpenPNEを使うことが出来る様になりました。
     29
     30 また、OpenPNEはメンテナンス期間が長いというのも特徴です。OpenPNEでは常に2つのバージョンをメンテナンスしています。[[BR]]
     31 例えば、OpenPNE2.12のベータ版がリリースされる時には、OpenPNE2.8のメンテナンスが終了します。この様にある程度長い期間安定版のメンテナンスしているので、安心してOpenPNEを利用出来るのも特徴です。[[BR]]
     32
     33
     34  ==== リリーススケジュール ====
     35 * 原則として、月に一度リリースする
     36 * リリース日は基本的に第3水曜日とする
     37 * 緊急のバグが見つかった場合は、上記日程に関係なく緊急リリースを行う
     38
     39  ==== 機能追加条件 ====
     40 * リリース2週間前までに開発版としてリリースされている(コミットされているだけでは不十分)
     41 * DB構造変更の必要がないもの
     42 * 安定動作に支障がないと判断されたもの
     43
     44  ==== メンテナンス期間 ====
     45[[Image(http://sc.pne.jp/cmd/200801082334.png)]]
     46
     47
     48
     49{{{
     50OpenPNE開発のガイドライン
     51http://trac.openpne.jp/wiki/pne-guidelines
     52}}}
     53
     54
     55== チームと開発の流れ ==
     56それでは、いよいよOpenPNE安定版のチームと開発の流れについて見ていきましょう。[[BR]]
     57まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。[[BR]]
     58
     59
     60 === チーム ===
     61 現在OpenPNE安定版はチーム小川という小川さん率いるチームが開発をしています。現在チーム小川は数名のメンバーがいますが、今回は小川さんも含めこの安定版リリースに関わる3人のチームメンバーの紹介をします。[[BR]]
     62 
     63 
     64 {{{
     65 小川 倫平
     66 (画像)
     67 自己紹介
     68 }}}
     69 
     70 {{{
     71 海老原 昂輔
     72 (画像)
     73 自己紹介
     74 }}}
     75
     76 {{{
     77 酒井 希和
     78 (画像)
     79 自己紹介
     80 }}}
     81 
     82 === 開発の流れ ===
     83 それでは、OpenPNEの安定版がどのような流れで開発されリリースされているか基本的な流れを見ていきましょう。[[BR]]
     84 基本的には以下の様な流れで開発しています。しかし、この流れで常に開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。[[BR]]
     85 それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのようにコミュニケーションをとりながら開発を進めているかを解説して頂きます。[[BR]]
     86
     87
     88 1. バグ、要望収集(酒井)
     89 1. バグ再現(酒井)
     90 1. 開発(海老原)
     91 1. リリース(小川)
     92
     93
     94== バグ、要望収集 ==
     95 === 概要 ===
     96 それでは「バグ、要望収集」は酒井がバグ収集の解説をしていきます。[[BR]]
     97 まずは、バグ収集の流れを説明してその後、実際にどこでどのようにバグを収集しているかという説明をしていきます。[[BR]]
     98 
     99 === 流れ ===
     100 
     101 1. OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認
     102 1. 収集する日記数・トピックコメント数を計算
     103 1. 日記・OpenPNE開発談義にて収集開始報告
     104 1. 管理画面内でIDの古い順から日記・トピックコメントを確認
     105 1. バグを発見
     106 1. チケット作成
     107 1. バグ報告者へお礼のコメント(ループが終われば7へいく)
     108 1. トピックで報告
     109 
     110 http://trac.openpne.jp/attachment/wiki/pne-member/%E3%83%90%E3%82%B0%E8%A6%81%E6%9C%9B%E5%8F%8E%E9%9B%86%E6%89%8B%E9%A0%86.png
     111 
     112 バグ収集はおよそこの様な流れで進んでいきます。[[BR]]
     113 バグや要望の収集というのは安定版リリースのためにやるというのではなく、OpenPNE品質向上のために常に行っています。[[BR]]
     114 
     115 以前バグ収集はwikiを用意してこちらに書いてくださいという形で場所を用意する形をとっていましたが、実際あまり収集できていない状況でした。しかし、実際は何らかのバグがあったり、「OpenPNEにこんな機能を入れて欲しい」という要望は頂いていました。そこでいろいろな方法を考えているうちに、日記でバグや要望について書いている人が多いことに気づき、ここでバグ収集や要望の収集をしようという結論に至りました。[[BR]]
     116 この方法でバグ収集や要望収集をすることによって以前より報告するという行為の敷居が下がり報告の件数も増加しています。[[BR]]
     117
     118
     119 === 収集方法 ===
     120 
     121 基本的にはOpenPNE.jp~OpenPNE公式SNS~の中でバグ収集や要望収集を行っています。[[BR]]
     122 OpenPNE.jp~OpenPNE公式SNS~の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。ですので、以前バグがどのように収集されたか知りたい人はこちらを参考にしてみてください。[[BR]]
     123 
     124 それでは、先ほどの流れ通り上から見ていきたいと思います。[[BR]]
     125 
     126 
     127 (「バグ・要望吸い上げチーム」のスクリーンショット)
     128 
     129 {{{
     130 OpenPNE.jp~OpenPNE公式SNS~
     131 http://sns.openpne.jp/
     132   
     133 バグ・要望吸い上げチーム
     134 http://sns.openpne.jp/?m=pc&a=page_c_home&target_c_commu_id=393
     135 }}}
     136
     137
     138  ==== OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認 ====
     139  まずは、OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認します。
     140 
     141  (スクリーンショット)http://sns.openpne.jp/?m=pc&a=page_c_topic_detail&target_c_commu_topic_id=3210
     142 
     143  基本的に前回バグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。
     144 
     145  {{{
     146
     147【最終確認ID】
     148日記:*****
     149トピック:*****
     150トピックコメント:*****
     151
     152-----------------------------
     153収集したバグのタイトル
     154収集したバグのURL
     155
     156  }}}
     157 
     158 
     159  ==== 収集する日記数・トピックコメント数を計算 ====
     160  次に、集計する日記の数とトピックコメント数を計算します。[[BR]]
     161  これは、次のOpenPNE開発談義で報告するためです。[[BR]]
     162
     163
     164  ==== 日記・OpenPNE開発談義にて収集開始報告 ====
     165  次に、Skypeのオープンチャット「OpenPNE開発談義『雑談』」で収集開始を報告します。[[BR]]
     166  このOpenPNE開発談義『雑談』はOpenPNE開発者の雑談を行う場所です。[[BR]]
     167  仕様策定についての議論など、リアルタイム性が必要なコミュニケーションをこのチャットルームで行っています。Skypeといえば音声通話と言うイメージがありますが、ここでは音声通話機能は利用せず、テキストベースのチャットルーム機能を利用しています。Windows MACの最新Skypeはオープンチャットに対応しているので興味があればぜひ参加してみてください。
     168 
     169  OpenPNE開発談義『雑談』に報告するときは、以下のフォーマットで開発談義に報告しています。一言コメントなどを入れてコミュニケーションを図ることを心がけています。[[BR]]
     170 
     171 
     172  {{{
     173【確認件数】
     174日記:***件
     175トピック:***件
     176トピックコメント:***件
     177一言コメント
     178}}}
     179 
     180  (収集開始コメントSkypeスクリーンショット)
     181 
     182  {{{
     183ツール紹介
     184   
     185  Skype公式サイト
     186  http://www.skype.co.jp/
     187 
     188  (Skypeのスクリーンショット)
     189
     190OpenPNEでは、コミュニケーションの手段としてSkypeを活用しています。
     191現在オープンチャットとして、OpenPNE開発談義『雑談』を公開しています。
     192参加方法は、OpenPNE.jp~OpenPNE公式SNS~(http://sns.openpne.jp/)の右サイドバーの「OpenPNE開発談義Skypeチャットルーム」をクリックすると、参加することが出来ます。
     193(OpenPNE開発談義Skypeチャットルーム スクリーンショット)
     194
     195OpenPNEを開発するときも、プロジェクトのグループチャットを作ったりとさまざまな活用をしています。
     196  }}}
     197 
     198 
     199  ==== 管理画面内でIDの古い順から日記・トピックコメントを確認 ====
     200 
     201  (管理画面のスクリーンショット デモ)
     202 
     203  管理画面内で一つ一つ目で見て確認していきます。[[BR]]
     204  基本的にはすみつきカッコ(【バグ】)で覆われているものだけに注目して収集していきます。要望がある場合も、すみつきカッコ(【要望】)を収集しています。[[BR]]
     205 
     206 
     207  ==== バグを発見 ====
     208 
     209  (バグ発見の日記スクリーンショット)
     210 
     211  バグ報告の日記を発見しました。[[BR]]
     212  次に、このバグをOpenPNEのTracにチケットを作成します。[[BR]]
     213 
     214  {{{
     215ツール紹介
     216   
     217The Trac Project
     218http://www.edgewall.com/trac/
     219
     220  (Tracのスクリーンショット)
     221 
     222Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理もできます。
     223 
     224現在OpenPNEプロジェクトにはTracを使っています。以前はwikiやCVSでバグやバージョンの管理を行っていました。しかし、現在はこのTracにすべての情報を集約してOpenPNEを管理しています。
     225また、OpenPNEでは社内の業務などもTracのチケットと呼ばれるバグ追跡システムを利用して管理しています。チケットでTODO管理を行っているチームもあります。
     226チーム小川では報告連絡などもこのチケットのやり取りで行っています。このように、OpenPNEのチーム開発だけではなく、手嶋屋ではTracを十二分に活用し、チーム開発やプロジェクトを進めています。
     227 
     228  }}}
     229 
     230  ==== チケット作成 ====
     231  次に、先ほど発見したバグのチケットを作成します。
     232 
     233  チケット作成にはある一定のフォーマットを設けてあり、誰がチケットを作ってもそのチケットの品質を保つことが出来る様にしています。[[BR]]
     234 
     235 
     236  {{{
     237チケット作成フォーマット
     238   
     239=== ■現象 ===
     240発生した現象を記入
     241
     242=== ■発生バージョン ===
     243バグが発生したバージョンを記入
     244
     245=== ■再現手順 ===
     246バグを再現するための手順を記入
     247(手順をかきようがない場合は空欄でかまわない)
     248
     249=== ■環境 ===
     250バグが発生した環境を記入
     251 * OS
     252 * ブラウザ
     253 * 携帯キャリア・機種
     254 * サーバ環境
     255など
     256
     257=== ■関連情報 ===
     258報告元へのリンク・関連するチケットなどの補足情報を記入
     259
     260
     261  }}}
     262 
     263  チケット作成の詳しい情報はOpenPNEのチケット作成はOpenPNE開発のガイドライン(http://trac.openpne.jp/wiki/pne-guidelines)の「チケット作成ガイドライン」にまとめられていますのでこちらを参照してください。
     264 
     265  (チケット作成ガイドラインのスクリーンショット)
     266 
     267 
     268  ==== バグ報告者へお礼のコメント(ループが終われば7へいく) ====
     269 
     270  このバグ報告者へお礼のコメントは私がバグ収集をしている中で大切にしているところです。確かに、バグを収集するだけでコメントはいらないという意見もあると思いますが、私は必要だと考えています。なぜなら、OpenPNEはコミュニティで作り上げていくもとだと考えているからです。
     271 
     272  実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。ですので、OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからやっています。
     273
     274
     275  まだ、日記やコミュニティのコメントなど収集する場所が残っていれば、「管理画面内でIDの古い順から日記・トピックコメントを確認」まで戻ってまた収集を始めます。[[BR]]
     276  この一連の流れを続けます。[[BR]]
     277  そして、収集が終了すれば、次のトピックで報告します。[[BR]]
     278 
     279
     280  ==== トピックで報告 ====
     281  さて、最後のトピック報告です。報告する場所はOpenPNE.jp~OpenPNE公式SNS~(http://sns.openpne.jp/)のバグ・要望吸い上げチームコミュニティです。
     282 
     283  バグ収集と要望収集を分けて、コミュニティトピックを立ち上げます。[[BR]]
     284  次回の収集開始場所が分かるように、一定の形式で書き込みます。[[BR]]
     285  これでバグ収集の一連の流れは終わりです。[[BR]]
     286 
     287 {{{
     288
     289【最終確認ID】
     290日記:*****
     291トピック:*****
     292トピックコメント:*****
     293
     294-----------------------------
     295収集したバグのタイトル
     296収集したバグのURL
     297
     298  }}}
     299 
     300 
     301 === まとめ ===
     302 OpenPNEでは随時バグ収集や要望収集を行っていますが、まだまだ収集しきれていない現状もあります。[[BR]]
     303 そこは試行錯誤して収集していければいいと思っています。しかし、やはりコミュニティの中でOpenPNEをより良いものにしていきたいという軸があるのでその軸がぶれないようにしていきたいと考えています。[[BR]]
     304 
     305 以前は要望収集も日記では行っていませんでしたが、日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。[[BR]]
     306 
     307
     308
     309
     310== バグ再現 ==
     311 === 概要 ===
     312 それではまた酒井がこのバグ再現を解説していきます。[[BR]]
     313 このバグ再現にもある程度手順は決まっています。こちらのバグ再現手順と共に、今回は普段使っているツールも紹介しながらバグ再現を紹介していきます。[[BR]]
     314
     315 === 流れ ===
     316 
     317 (バグ再現手順画像)
     318 
     319 手順としてはこのような流れでバグ再現を行います。[[BR]]
     320 バグはやはり危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。[[BR]]
     321 
     322 (再現待ちのスクリーンショット)
     323 
     324 また、収集したバグの中には環境に依存するものや、情報不足なものもありバグの再現が難しい場合もあります。そのような場合は、なるべくバグ情報をもとに直接コミュニティで聞いたり日記でコメントしてどのような状況でそのバグが発生したかなどの原因を追究するようにしています。
     325 
     326
     327 === 実際のバグ再現方法 ===
     328それでは実際にバグ再現の方法を見てきましょう。[[BR]]
     329ただ、バグはそのバグによってその再現方法が違うので、今回はツールを紹介しながらバグの再現方法を解説していこうと思います。[[BR]]
     330バグによって使うツールはさまざまですが、私が多く使っているのが、「Selenium IDE」「Web Developer」を主に使っています。数多くある中から今回はOpenPNEに良く使うこの2つのツールを紹介したいと思います。[[BR]]
     331この2つのツールはどちらもFirefoxのアドオンです。[[BR]]
     332Selenium IDEは主に繰り返し処理を行うときに使っています。特にOpenPNEはページングの処理が日記、コミュニティ、管理画面などに多く使われています。このように繰り返しの処理でバグなどが発見された場合には、このSelenium IDEを使って自動化しています。
     333
     334(Selenium IDE の使用スクリーンショット)
     335
     336次に、Web Developerですが、これは主にフォームの値チェックやバリデーション関係のバグ再現で使用しています。OpenPNEには日記やコミュニティトピックなどフォーム入力が多くあります。そのようなフォーム入力でのバグなどにはこのWeb Developerを使用します。[[BR]]
     337
     338(Web Developer の使用スクリーンショット)
     339
     340
     341{{{
     342  ツール紹介
     343 
     344  Selenium IDE :: Firefox Add-ons
     345  https://addons.mozilla.org/ja/firefox/addon/2079
     346 
     347  OpenPNEでは主にバグ再現やテストツールとして使用しています。
     348  このSelenium IDEはFirefoxのアドオンとして提供されているため、非常に簡単に導入できるという特徴もあります。
     349  OpenPNEのバグ再現にはあまりしない機能ですが、テストケースをHTMLやPHPなどさまざまな形式でエクスポートできるのも特徴です。
     350
     351}}}
     352
     353{{{
     354  ツール紹介
     355 
     356  Web Developer :: Firefox Add-ons
     357  https://addons.mozilla.org/ja/firefox/addon/60
     358 
     359  このWeb Developerは普通はCSSの編集やテーブル表示などに使うことが多いと思いますが、OpenPNEのバグ再現やテストをするときにはではフォーム関連の機能を使うことが多いです。その他にもWEBページを作っていく上で便利な機能が満載です。
     360 
     361
     362}}}
     363
     364
     365
     366 === まとめ ===
     367 バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でコミュニティとコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。[[BR]]
     368 そして、バグ収集、バグ再現を効率よく進めてより良いOpnePNEを作り上げたいと思います。
     369 
     370
     371== 開発 ==
     372 === 概要 ===
     373 次は、海老原が再現されたバグを修正をしていく開発流れを解説していきます。[[BR]]
     374 開発と言ってもさまざまなバグ修正の方法があるので、具体的なバグ修正は割愛します。[[BR]]
     375 まず全体の流れを確認して、その後それぞれについて詳しく見ていきましょう。[[BR]]
     376 
     377 === 流れ ===
     378 1.レポートの作成[[BR]]
     379 1.修正チケットの選定[[BR]]
     380 1.コーディング[[BR]]
     381 1.コードの確認[[BR]]
     382 1.テスト[[BR]]
     383
     384
     385   ==== レポートの作成 ===
     386   再現されたチケットや、バグと認められたあと、チケットとして作成されます。[[BR]]
     387   そのチケットはすべてView Ticketsに集められます。[[BR]]
     388   収集されたバグはTypeがdefectとなっているので、Custom Queryでソートします。[[BR]]
     389   この時、Kyewordsに「再現待ち」「再現せず」「PNEMonster」を設定し、バグでないものを表示しないようにしておきます。[[BR]]
     390   
     391   (画像 Custom Query)
     392   
     393   このチケットの一覧から、ユーザーが不便だと感じたり急ぐ必要があるものを開発者の判断で安定版のチケットに変更します。[[BR]]
     394   そのチケットを開き、KeywordsとMilestoneを変更します。[[BR]]
     395   ここにバージョンを入れることで、このバージョンに対して修正しますということを宣言します。[[BR]]
     396   Milestoneは修正されるバージョンを表します。このMilestoneを集めたものをレポートと呼びます。[[BR]]
     397   例えば、MilestoneにOpenPNE2.10.4と入れると、OpenPNE2.10.4に修正するバグがレポートとして一覧で表示されます。[[BR]]
     398   
     399   (画像 OpenPNE2.10.4レポート)
     400   
     401   安定版のレポートは基本的にdefect(不具合)が多いですが、開発版になると、enhancement(対応済みの機能追加・改善)もあります。[[BR]]
     402   基本的には開発者はこのレポートを見ながら、次にどの不具合を修正するかを決めています。[[BR]]
     403   レポートがある程度完成した段階で、他のOpenPNE開発版チームに見てもらったり、OpenPNEコミュニティに見てもらいながら、レポートを完成させます。[[BR]]
     404   
     405   
     406   ==== 修正チケットの選定 ===
     407   レポートが完成したら、修正チケットの選定に入ります。[[BR]]
     408   レポートは基本的に上からPriotity(優先順位)が高いものから並んでいます。[[BR]]
     409   
     410   (画像 OpenPNE2.10.4レポート)
     411   
     412   基本的には、Priotityが高いものから修正に入ります。[[BR]]
     413   始めはCriticalから修正し、次にmajorを修正していきます。[[BR]]
     414   しかし、majorにすぐ修正できるバグがある場合は開発者の判断で修正していきます。
     415   
     416   次に、実際にこのチケットを修正したいと思った時にはそのチケットを開き、自分がチケットを修正することを宣言します。[[BR]]
     417   具体的には、そのチケットの下のaccept ticketのラジオボタンを選択して「Submit changes」を押すと自分自身がこのチケットをやりますと宣言したことになります。[[BR]]
     418   
     419   (reassign 画像)
     420   
     421   「Submit changes」を押すと、誰から誰にこのチケットの担当が移ったのかがChange Historyとしてチケットに記入されます。[[BR]]
     422   今回は誰もチケットを担当していなかったのでnobodyとなっています。[[BR]]
     423   また、このChange Historyが残ることで、以前は誰が担当しているのかなど分かるようになります。[[BR]]
     424   また、reassign toにユーザ名を入れたら自分以外にも他の人にチケットを担当してもらうことも出来ます。例えば、一度やって見たけど、分からなかったので他の出来る人に担当してもらうなどすることも可能です。[[BR]]
     425   しかし、OpenPNEでは基本的に自分がやりたいチケットを自分で担当する方法をとっています。[[BR]]
     426   それでは、次は実際にバグの修正をしながらどのようにバグを修正していくかを解説していきます。
     427   
     428   
     429  ==== コーディング ====
     430  ここで、バグと判断されたものに対して修正を加えていきます。[[BR]]
     431 
     432  (チケットの画像)
     433 
     434  まずはじめに、開発するチケットを決めたらその現象、原因、関連情報を見ます。[[BR]]
     435  このバグはOpenPNE公式SNSからのバグ報告のようです。[[BR]]
     436  そして、そのバグをローカル環境で確かめます。[[BR]]
     437  今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者はローカル環境にVMwareを使う人もいます。[[BR]]
     438
     439  バグを確認したらコーディングに入ります。[[BR]]
     440  以前はEclipseを使っていましたが、現在はviを使ってコードの修正をしています。[[BR]]
     441 
     442  (開発画像)
     443 
     444  実際にコードを修正したら、ローカル環境でテストします。[[BR]]
     445  ローカル環境で正常に動くようであれば、テスト環境にコミットします。[[BR]]
     446 
     447  その後、Tracでバグの修正が完了したことを報告します。
     448 
     449  ここではチケットのkeywordsに確認中と入力します。[[BR]]
     450  また、どのリビジョンで修正を加えたかを書いておきます。[[BR]]
     451  このリビジョンのリンクを貼る場合にTracはr5000とするだけでリビジョン5000にリンクを貼ってくれます。
     452 
     453 
     454  {{{
     455ツール紹介
     456VMware
     457http://www.vmware.com/jp/
     458
     459現在OpenPNEではVM4PNEとしてOpenPNEの開発を支援するための開発用バーチャルマシンのイメージファイルを配布しています。このイメージを使えばすぐにOpenPNEの開発環境をローカルに作ることが出来ます。VM4PNEの構成は以下の通りです。
     460
     461VM4PNE
     462http://www.openpne.jp/docs/vm4pne/
     463
     464VM4PNEの構成
     465【OS】CentOS ServerCD4.4最小インストール
     466【ミドルウエア】PHP、MySQL、Postfix
     467【アプリケーション】OpenPNE2.8RC2、TRAC、Subversion
     468【初期ID】admin / VM4PNE root / VM4PNE
     469
     470  }}}
     471 
     472  {{{
     473  coLinux
     474  http://www.colinux.org/
     475 
     476  OpenPNE開発者はローカル環境にVMwareを使う人とcoLinuxがいます。
     477  どちらを使うかは開発者の好みで判断しています。
     478  ただ、初めてOpenPNEのローカル環境を作る場合は、VM4PNEが公開されているので、VMwareの方が比較的簡単にローカル環境を作ることが出来ると思います。
     479 
     480  }}}
     481 
     482  {{{
     483  PuTTY
     484 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html 
     485 
     486  PuTTYjp
     487  http://hp.vector.co.jp/authors/VA024651/PuTTYkj.html
     488 
     489  SSHでローカル環境に接続する時、テスト環境に接続するときに使用しているSSHクライアントです。
     490  OpenPNE開発者はPuTTYの他に、Tera TermやVaraTermを使う人もいます。
     491 
     492  }}}
     493 
     494 
     495 
     496  ==== コードの確認 ====
     497 
     498  次に、実際にコーディングが終わったソースコードを確認してもらいます。[[BR]]
     499  このソースコードの確認は小川さんにお願いします。[[BR]]
     500 
     501  確認してソースに不具合があった場合などは確認中のkeywordsが削除され、またバグの修正をします。[[BR]]
     502 
     503  そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入りテストされます。[[BR]]
     504 
     505  (testing defect 画像)
     506 
     507 
     508  ==== テスト ====
     509  最後に、テストをして正常に動作すれば、resolveをfixedにします。[[BR]]
     510 
     511  この一連の流れをレポートのチケットがなくなるまで続けます。[[BR]]
     512 
     513
     514 === まとめ ===
     515 このような形で、OpenPNEのバグは修正されています。[[BR]]
     516 以前はバグを修正するのもすごく時間がかかっていたり、小さなミスがありました。しかし、SVNを使ったり、バグをチケットで管理することで効率が上がったりミスがなくなりつつあります。[[BR]]
     517 また、開発ツールも今後のOpenPNE3を見越してコンソールで開発する人も増えています。[[BR]]
     518 
     519 
     520 
     521 
     522
     523== リリース ==
     524
     525
     526
     527
     528== OpenPNEチーム開発まとめ ==
     529
     530