OpenPNE 開発チームの海老原です。

@openpne_irc で一部お届けしましたが、 10/12 (火) に OpenPNE 3.6.0 のリリース検討会議をおこない、リリースまでの課題の洗い出しや対応スケジュールの決定などをおこないました。

新しいリリーススケジュール

以前告知したとおり、 OpenPNE 3.6.0 のリリース予定日を 10/15 (金) とする前提で進めていましたが、検討の結果、 11 月末まで延期することになりました。

OpenPNE 3.6beta7

10 月末

OpenPNE 3.6beta8

11 月第 1 週 から 第 2 週

OpenPNE 3.6beta9

11 月第 2 週 から 第 3 週

OpenPNE 3.6 RC1

11 月第 3 週

OpenPNE 3.6.0

11 月末

まだまだお待たせしてしまいますが……、ご理解と、開発へのご協力をどうぞよろしくお願いします！

OpenPNE 3.6.0 開発のスケジュール

現状のタスクを話し合いのなかで整理し、各タスクとスケジュールについて、以下の画像にまとめました。

各タスクの具体的な内容などは、次の「話し合ったことまとめ」をご覧ください (ちょっと長いです)。

話し合ったことまとめ

目次

• 3.6.0 に向けての課題
  • バンドルプラグインのバグの優先順位づけができていない
  • バグ収集を動かす
  • 優先度「高」の、再現できていないバグチケットが 2 件残ったままなのが気がかり
  • 現状のすべてのコードが、セキュアコーディングガイドラインに沿ったものになっているかどうかを確認して回る
  • 最低限度のプログラマテストが機能しているような状態にしていきたい
  • いまコードレビューとかで頑張ってチェックしていっているものの一部を、チェックツールを使うことでカバーしていけるようにする
  • 「OpenPNE 3.6 標準環境」を作る
  • OpenPNE 3.6 標準環境で、「全機能」に関する正常動作の動作テストを実施する
  • 「仕様バグ」
  • リリースに合わせてドキュメント群を更新する必要がある
  • OpenPNE 3.6.0 の告知（新機能など）を練る必要がある
• おまけ: MTG 中に生じた疑問
  • プラグインの導入状況等によりプログラマテストの成否が変わりそうな場合にどうするか
  • コーディング規約自体の変更が生じそうな場合にどうするか

3.6.0 に向けての課題

バンドルプラグインのバグの優先順位づけができていない

• http://www.openpne.jp/archives/5361/ のチケットの優先度の基準にあわせて、バンドルプラグインのチケットの優先度の見直しをおこなう
• コア側のチケットについては実施したが、バンドルプラグイン側のチケットについては着手できていなかった
• 10/17 までに ebihara, ogawa でやりたい

バグ収集を動かす

• 現状追いついていないのでまずい
• imamura さんに毎朝 15 分くらいで確認してもらうことにした (10/13 スタート)

優先度「高」の、再現できていないバグチケットが 2 件残ったままなのが気がかり

• http://redmine.openpne.jp/issues/589 と http://redmine.openpne.jp/issues/1527
• 引き続き調査を続ける。再現や情報収集に kiwa さんをアサインする

現状のすべてのコードが、セキュアコーディングガイドラインに沿ったものになっているかどうかを確認して回る

• 11/14 の beta9 までに、 ebihara, ogawa (, kawahara) で実施する

最低限度のプログラマテストが機能しているような状態にしていきたい

• 少ないリソースのなかで、開発のスピードを上げていくため

• 少なくとも functional test で CSRF と XSS に脆弱でないかどうかのテストがおこなえているようにする

• 少なくとも unit test で XSS に脆弱でないかどうかのテストがおこなえているようにする

• unit test は最低限フォームと、 HTML の出力に直接関わるような OpenPNE 独自のクラスに対しておこなう

• functional test は最低限 PC 版の全アクションに対しておこなう

  • 携帯の functional test は過去まともに機能せず、ハマったという経験がある。いまもちゃんと動くかどうかわからない
  • 幸い、携帯のみのアクションは少ない (基本的には PC と共通のコードである) ので、携帯の functional test が難しい、という事態に陥ってしまっても、今回はよしとする

• プログラマテストを迅速に整えていくため、 3.6beta6 リリース以降、 ebihara と nagasawa で 10/24 までに体制を整える

  • テストのひな形を作る、作成の手順を固める、など

  • あとは人海戦術で一気に整えていくだけ、というような状態に持って行きたい

    • 協力者を熱烈募集する

いまコードレビューとかで頑張ってチェックしていっているものの一部を、チェックツールを使うことでカバーしていけるようにする

• 自動化できるものをツールに逃がすことによってスピードアップを図る
• 「URL 生成時にルーティングルールちゃんと指定しているかどうかチェックツール」は既に作ってもらっているものがあったはずなので、それが使える
• 「コーディング規約チェックツール」は ebihara が作りかけているものがあるので、 10/27 くらいで整えていく
• CI ツールは ogawa が 10/17 から 1 週間くらいで整える

「OpenPNE 3.6 標準環境」を作る

• 少なくとも、「OpenPNE 3.6 標準環境」での動作だけでも保証できるような状態に持っていきたい
• 「OpenPNE 3.6 標準環境」を作り、動作テストなどはそこでおこなうようにする
• この環境の情報についてはセットアップドキュメント等に明記しておく
• 「OpenPNE 3.6 標準環境」については 10/24 までに用意できるように、 ogawa などが動く

OpenPNE 3.6 標準環境で、「全機能」に関する正常動作の動作テストを実施する

• リソースの関係で OpenPNE 3.0 の開発を開始してからいままで、一度もすべての機能に関する動作テストがおこなわれていない (一度もテストがおこなわれていない機能が存在する)

• この状態では安定動作を保証することはできない

• 今度こそ「安定した OpenPNE 3」として OpenPNE 3.6 を出したい

• 少なくとも、正常動作については「全機能」に関する動作テストをおこなう (設定変更等も考慮)

• 異常系の試験は 3.6 の新機能を除いてはやらなくてもいいが、正常系は一通りの機能をカバーしたい

• テストする「全機能」を明確にする作業を tajima が 10/24 までにやる

  • アクションのリストや設定項目のリストなどの洗い出し
  • それ以外のポイントがありうるかどうかの検討

• テスト計画は 10/24 までに imamura が立て、 11/7 までに kiwa, imamura などが実施する

「仕様バグ」

• 「仕様バグ」のパターンと、 3.6 開発期間中に修正するべきものの基準を、 10/24 までに明確にできるような動きを kiwa さんが起こす

リリースに合わせてドキュメント群を更新する必要がある

• OpenPNE 2 からのアップグレードタスクのドキュメントの更新など
• RC までに完了させる

OpenPNE 3.6.0 の告知（新機能など）を練る必要がある

• 目立つ機能追加が少ないので、パフォーマンスの改善は確実にアピールしたい
• なので、パフォーマンス測定をなんとか時間取ってやる
• 「OpenPNE 標準環境」でパフォーマンス計測をおこなう動きにしていく
• RC までには完了させる

おまけ: MTG 中に生じた疑問

プラグインの導入状況等によりプログラマテストの成否が変わりそうな場合にどうするか

• バンドルプラグインについてはテストコード側で考慮をする (テストをパスする、追加でテストするなど)

コーディング規約自体の変更が生じそうな場合にどうするか

• 「慣習でこういうルールになっていたが、ルールとしては定義されていなかった」というものについては、規約の変更とコードの変更をおこなう
• コードの一括置換の必要がありうるなどショックの大きい変更は 3.6 開発期間中にはやらない