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

Changes between Version 20 and Version 21 of pne-book-9-4


Ignore:
Timestamp:
Mar 31, 2008, 9:08:57 PM (14 years ago)
Author:
ebihara
Comment:

開発について気がついたところを修正

Legend:

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

    v20 v21  
    270270
    271271
    272    ==== レポートの作成 ====
    273    再現されたチケットや、バグと認められたあと、チケットとして作成されます。[[BR]]
    274    そのチケットはすべてView Ticketsに集められます。[[BR]]
    275    収集されたバグはTypeがdefectとなっているので、Custom Queryでソートします。[[BR]]
    276    この時、Kyewordsに「再現待ち」「再現せず」「PNEMonster」を設定し、バグでないものを表示しないようにしておきます。[[BR]]
    277    
    278    [[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/11.png,650)]]
    279    
    280    このチケットの一覧から、ユーザーが不便だと感じたり急ぐ必要があるものを開発者の判断で安定版のチケットに変更します。[[BR]]
    281    そのチケットを開き、KeywordsとMilestoneを変更します。[[BR]]
    282    ここにバージョンを入れることで、このバージョンに対して修正しますということを宣言します。[[BR]]
    283    Milestoneは修正されるバージョンを表します。このMilestoneを集めたものをレポートと呼びます。[[BR]]
    284    例えば、MilestoneにOpenPNE2.10.4と入れると、OpenPNE2.10.4に修正するバグがレポートとして一覧で表示されます。[[BR]]
    285    
    286    [[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/11.png,650)]]
    287    
    288    安定版のレポートは基本的にdefect(不具合)が多いですが、開発版になると、enhancement(対応済みの機能追加・改善)もあります。[[BR]]
    289    基本的には開発者はこのレポートを見ながら、次にどの不具合を修正するかを決めています。[[BR]]
    290    レポートがある程度完成した段階で、他のOpenPNE開発版チームに見てもらったり、OpenPNEコミュニティに見てもらいながら、レポートを完成させます。[[BR]]
    291    
    292    
    293    ==== 修正チケットの選定 ====
    294    レポートが完成したら、修正チケットの選定に入ります。[[BR]]
    295    レポートは基本的に上からPriotity(優先順位)が高いものから並んでいます。[[BR]]
    296    
    297    基本的には、Priotityが高いものから修正に入ります。[[BR]]
    298    始めはCriticalから修正し、次にmajorを修正していきます。[[BR]]
    299    しかし、majorにすぐ修正できるバグがある場合は開発者の判断で修正していきます。
    300    
    301    次に、実際にこのチケットを修正したいと思った時にはそのチケットを開き、自分がチケットを修正することを宣言します。[[BR]]
    302    具体的には、そのチケットの下のaccept ticketのラジオボタンを選択して「Submit changes」を押すと自分自身がこのチケットをやりますと宣言したことになります。[[BR]]
    303    
    304    [[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/13.png,650)]]
    305    
    306    「Submit changes」を押すと、誰から誰にこのチケットの担当が移ったのかがChange Historyとしてチケットに記入されます。[[BR]]
    307    誰も担当していないチケットはnobodyとなっています。[[BR]]
    308    また、このChange Historyが残ることで、以前は誰が担当しているのかなど分かるようになります。[[BR]]
    309    また、reassign toにユーザ名を入れたら自分以外にも他の人にチケットを担当してもらうことも出来ます。例えば、一度やって見たけど、分からなかったので他の出来る人に担当してもらうなどすることも可能です。[[BR]]
    310    しかし、OpenPNEでは基本的に自分がやりたいチケットを自分で担当する方法をとっています。[[BR]]
    311    それでは、次は実際にバグの修正をしながらどのようにバグを修正していくかを解説していきます。
    312    
    313    
    314   ==== コーディング ====
    315   ここで、バグと判断されたものに対して修正を加えていきます。[[BR]]
    316  
    317   [[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/14.png,650)]]
    318  
    319   まずはじめに、開発するチケットを決めたらその現象、原因、関連情報を見ます。[[BR]]
    320   このバグはOpenPNE公式SNSからのバグ報告のようです。[[BR]]
    321   そして、そのバグをローカル環境で動作させてみて確かめます。[[BR]]
    322   今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者の中にはローカル環境にVMwareを使う人もいます。[[BR]]
    323 
    324   バグを確認したらコーディングに入ります。[[BR]]
    325  
    326   実際にコードを修正したら、ローカル環境でテストします。[[BR]]
    327   ローカル環境で正常に動くようであれば、テスト環境にコミットします。[[BR]]
    328  
    329   その後、Tracでバグの修正が完了したことを報告します。
    330  
    331   ここではチケットのkeywordsに確認中と入力します。[[BR]]
    332   また、どのリビジョンで修正を加えたかを書いておきます。[[BR]]
    333   このリビジョンのリンクを貼る場合にTracはr5000とするだけでリビジョン5000にリンクを貼ってくれます。
     272==== レポートの作成 ====
     273再現されたチケットや、バグと認められたあと、チケットとして作成されます。[[BR]]
     274そのチケットはすべてView Ticketsに集められます。[[BR]]
     275収集されたバグはTypeがdefectとなっているので、Custom Queryでソートします。
     276   
     277[[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/11.png,650)]]
     278   
     279このチケットの一覧から、対応するバグのチケットを安定版の対応項目とします。MilestoneとKeywordsに修正予定のバージョンを指定します。[BR]]
     280対応項目がわかりやすいように、これらのチケットをまとめたレポートを作成します。レポートにはチケットの一覧が表示されるので、実際の開発・テスト時にはこのレポートを見て対応項目を確認しながら進めていきます。
     281   
     282[[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/11.png,650)]]
     283   
     284レポートがある程度完成した段階で、他のOpenPNE開発版チームに見てもらったり、OpenPNEコミュニティに見てもらいながら、レポートを完成させます。
     285
     286==== 修正チケットの消化作業 ====
     287レポートが完成したら、修正チケットの消化作業に入ります。[[BR]]
     288レポートではチケットがPriotity(優先順位)の高いものから順に並んでいます。[[BR]]
     289   
     290基本的には、Priotityが高いものから修正に入ります。[[BR]]
     291始めはCriticalから修正し、次にmajorを修正していきます。[[BR]]
     292しかし、majorにすぐ修正できるバグがある場合などは、先にそのバグを修正することもあります。
     293   
     294対応するチケットが決まったら、そのチケットを開き、ページ下部のaccept ticketのラジオボタンを選択することで自分がバグを修正することを宣言したことになります。[[BR]]
     295   
     296[[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/13.png,650)]]
     297   
     298==== コーディング ====
     299ここで、バグと判断されたものに対して修正を加えていきます。[[BR]]
     300 
     301[[Image(source:prj/pne-book/pne-book-9/pne-book-9-4/14.png,650)]]
     302 
     303まずはじめに、開発するチケットを決めたらその現象、原因、関連情報を見ます。[[BR]]
     304このバグはOpenPNE公式SNSからのバグ報告のようです。[[BR]]
     305そして、そのバグをローカル環境で動作させてみて確かめます。[[BR]]
     306今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。[[BR]]
     307
     308バグを確認したらコーディングに入ります。[[BR]]
     309 
     310実際にコードを修正したら、ローカル環境でテストします。[[BR]]
     311ローカル環境で正常に動くようになったら、修正内容をよく確認し、問題がなければテスト環境にコミットします。[[BR]]
     312 
     313その後、Tracでバグの修正が完了したことを報告します。
     314 
     315また、どのリビジョンで修正を加えたかを書いておきます。[[BR]]
     316このリビジョンのリンクを貼る場合にTracはr5000とするだけでリビジョン5000にリンクを貼ってくれます。
    334317 
    335318 
     
    360343  (スクリーンショット)
    361344 
    362   OpenPNE開発者はローカル環境にVMwareを使う人とcoLinuxがいます。
    363   どちらを使うかは開発者が好みで判断しています。
    364   ただ、初めてOpenPNEのローカル環境を作る場合は、VM4PNEが公開されているので、VMwareの方が比較的簡単にローカル環境を作ることが出来ると思います。
    365  
    366345  }}}
    367346 
     
    383362 
    384363 
    385  
    386   ==== コードの確認 ====
    387  
    388   次に、実際にコーディングが終わったらソースコードを小川さんに確認してもらいます。[[BR]]
    389  
    390   このソースコードの確認ではコードが正常に動作するかなど基本的な確認はもちろん、コードの設計やセキュリティ面での抜け漏れなども確認してもらっています。 
    391  
    392   確認してソースに不具合があった場合などは確認中のkeywordsが削除され、不具合を修正をします。[[BR]]
    393  
    394   そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入った後に動作テストされます。[[BR]]
    395  
    396  
    397  === まとめ ===
    398  このような流れで、OpenPNEのバグは修正されています。[[BR]]
    399  以前はバグを修正するのもすごく時間がかかったり、小さなミスがありました。しかし、SVNを使ったり、バグをチケットで管理することで効率が上がると共にミスが少なくなくなりつつあります。[[BR]]
    400  このようにあらゆるツールを使うことで効率よくOpenPNEを開発することを心がけています。
    401  
    402  また、この開発で重要なことはソースコードの品質を保つことだと考えています。[[BR]]
    403  一人で開発をするのではなく、ソースコードの確認や動作確認を何人もの人の目を通すことで、ソースコードの品質が保たれています。[[BR]]
    404  このようにしてOpenPNEはソースコードの品質を保ちながら効率よく開発を進めています。 [[BR]]
     364==== コードの確認 ====
     365 
     366次に、実際にコーディングが終わったらソースコードを小川さんに確認してもらいます。[[BR]]
     367このソースコードの確認ではコードが正常に動作するかなど基本的な確認はもちろん、コードの設計やセキュリティ面での抜け漏れなども確認してもらっています。 
     368確認してソースに不具合があった場合などは確認中のkeywordsが削除され、不具合を修正をします。[[BR]]
     369そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入った後に動作テストされます。[[BR]]
     370
     371=== まとめ ===
     372このような流れで、OpenPNEのバグは修正されています。[[BR]]
     373以前はバグを修正するのもすごく時間がかかったり、小さなミスがありました。しかし、SVNを使ったり、バグをチケットで管理することで効率が上がると共にミスが少なくなくなりつつあります。[[BR]]
     374
     375このようにあらゆるツールを使うことで効率よくOpenPNEを開発することを心がけています。
     376
     377
     378また、この開発で重要なことはソースコードの品質を保つことだと考えています。[[BR]]
     379一人で開発をするのではなく、ソースコードの確認や動作確認を何人もの人の目を通すことで、ソースコードの品質が保たれています。[[BR]]
     380このようにしてOpenPNEはソースコードの品質を保ちながら効率よく開発を進めています。 [[BR]]
    405381
    406382== 動作テスト ==