4D

R-RELEASE FAQ

Rリリースについてよくある質問

warning: file_get_contents(http://www.telize.com/geoip/54.90.207.75) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /var/www/www.4d.com/docs/includes/common.inc(1762) : eval()'d code on line 4.

Rリリースに含まれる新機能はどのようなもの?

新しい機能はそれぞれメインの開発ブランチ(分派)で開発されました。各機能ごとに使用しない選択ができるように開発されています。また、それぞれの機能はそのタイプによって、自動および手動によるテストを行っています(自動テストを優先し、いつでも再実行できるようにしています。)

 

例えば、3-4ヶ月ごとに新しい4D v15 Rxブランチをメインの開発ブランチから作ります。ブランチが作られたときに、"ready"(つまりすべてテスト済み)の機能のみキープされます。他のテストが完了していない機能はまもなく終わるとしても、すべて無効にします。「完了間近」の機能は次のRリリースに延期されます。

 

このコンセプトはバージョンが準備できた時にリリースするためであり、特定の日にリリースするために機能をカットする、あるいは質を落とすということではありません。 

 

Rリリースとバグ修正:4D v15.xと4D v15 Rxは同じバグ修正がされているのか?

答えはNOです。しかし、Rリリースにはもちろんバグ修正も含まれています。でもこれは同期の問題です。この非同期の理由はRリリースの開発プロセス自体にあります。

 

リリース・ノートはRリリースとマイナーリリース (v15.x)の両方について提供されます。提供されたリリースでどのバグが修正されたかが分かります。 

 

より詳細について、以下がv15.x(v14.xでも同様)のバグ修正時の異なるステップです:

  • 4D v15.xのバグがリポートされます。
  • バグが調査されて,修正版がメインの開発ブランチで実行されます。
  • 通常はメインの開発ブランチでのバグ修正がテストチームによってテスト・評価されます。テストはバグのタイプとその潜在的影響にもよりますが数日かかることがあります。
  • 修正が確認されると4D v15.xに統合されます。それからNightly BuildフォーラムにNightly Buildがリリースされます。

 

正式なマイナー・リリースのリリースが近くなるとそのブランチは固定されますー通常は3〜5週間。「固定」の意味は、これ以上のバグ修正をブランチに統合せず、手動によるテストのみ実行されるということです。もしどういうわけか以前の修正が第二の問題(自動テストでは調べられなかったもの)を発生させていたら、新しい修正を最初のバグ修正上で実行したり、最初のバグ修正コードを削除したりします。そしてそのバージョンはマイナー・リリースとしてリリースされます。

 

各コードの変更は潜在的に新しい問題へつながることがあり、それ故にこの3週間の手動テストがあります。(追加の2週間は、変更が必要となる障壁のある問題が発生した場合に、再度テストをするために予定されています。)

 

さて、新しい機能の実装について、開発はメインの開発ブランチで専門的に実行されます。たとえば、4D v15 R2ブランチは2014年2月にメインの開発ブランチから製作されました。したがってこのブランチには4D v15から実装されたすべての新しい機能が含まれていて、メインの開発ブランチで日々更新された新しいバグ修正はすべて実行されています。

 

機能の中で、安定・成熟に欠けるものは無効とされ、ブランチは固定されます。新機能に関するバグ修正もしくは重要なバグ修正(販売に影響するもの、データを破壊するものなど)を除いて、絶対に何も入らない(わずかなコードの変更さえもない)状態です。その一方で、バージョンは我々の内部システムで製品として運用されます。このようにしてRリリースの安定性を確実にしています。

 

これはたとえばGoogleがChromeで使っているコンセプトです。既知の問題とともにアップデートを配布するのは、不十分なテストしかしていないバージョンを他の未知の問題とともにリリースするよりも良いことです。これはできるだけ早く、できる限り多くの問題を修正するという通常の方法とは抜本的に異なります。このために短いサイクルが生まれました。

 

 4D v14 R5ブランチはそれまでメインの開発ブランチに含まれていたすべてのバグ修正を含みます。これらの修正は、4D v15.x (Nightly Build)のように2,3日ではなく、数ヶ月かけてテストされてきました。これは与えられたバグ修正は不安定ではないことをどれだけ確認しているかということを示しています。このバージョンは3ヶ月後にリリースが予定されます。

 

Nightly Buildsはどのように適合するのか?

Nightly Buildsへのアクセスを提供開始する前はHotfixバージョンを案内してきました。その時には、自動ビルド・プロセスがありましたが、基本的な自動テストだけしかありませんでした。

 

Hotfixバージョンの手動テスト期間は(マイナー・リリースでは3-5週間と比較すると)3-5日間でした。

 

2013 -2014年から、私たちは自動テストで厳しく調査し始めました。ビルド・プロセスは、1時間に1回実行しています。(コンピュータのクラスターから実行し、4D v13, 4D v14, 4D v14 Rx、メイン・バージョンなどを作成します。Wakanda, Mac OS X 32-bitと64-bit、Windows 32-bitと64-bit、Linux 32-bitと64-bitと、対応する言語として英語、フランス語、ドイツ語、日本語なども同様です。これらの作成されたバージョンは、自動的にテスト・コンピュータのクラスターに配給され、4Dアプリケーションを使ってユニット・テストだけではなく、多くの全自動テストも行われます。私たちはこの目的のために4Dを拡張し、FORM SCREENSHOTのような機能を追加しています。

 

結果として、Nightly Buildsは以前のHotfixに匹敵するレベルに達し、多くのケースではもっとよいレベルにあります。

 

もちろん、プロセスの拡張は継続します。また自動テストを簡単にしするために定期的に新コマンドもデザインしていて、自然とこれらはカスタマーも使えるコマンドとなります。

 

Nightly BuildsはRリリースにもある?

あります。Nightly Buildsは提供されますが、重要な問題(例えばデータ破損問題、重大なクラッシュなど)がRリリースに見つかったときのみです。

 

4D v14と4D v15のNightly Buildsとは異なり、RリリースのNightly Buildsは4Dフォーラムから配信されません。公式なRリリースと同様のダウンロード・リンクを使います。(リンクは4Dストアのアカウントからアクセスします。) 

Rリリースは実際に運用が可能か?

明確に「可能」です。Rリリースは次のメジャー・バージョンの新機能を見ることができ、それを試してフィードバックを報告いただくこともできますが、それだけではありません。

 

近年では、早くからベータ・テストを開始、開発サイクルの早い段階でフィードバックを得るようになりましたが、あまり使われていませんでした。開発者は新機能を少し見るだけだったのです。開発者は.2や.3リリースを待っていました。そこで新しい機能をテストして、自分たちのアプリケーションに有効なオプションなどを見過ごしていたら、いくつかの新機能はフルに使えるようにはならないことを学習し始めました。4Dは作業の95%をこなし、残りの5%のこれから先に使われる機能は使われていませんでした。 

 

この時点ではすでにTNV(The Next Version =次バージョン)のベータに近く、カスタマーのフィードバックをアカウントに入れるには遅すぎます。結果としてその 機能は2つあるいは3つ後のメジャー版でフルに使えるようになっていました。

 

このようにすべてを含んだ品質は完璧ではなく、あまりに多くの変更が一度に行われていました。

 

もしもコンピューター・ニュース・サイトやブログを見たら、最近は「継続的な供給」が主要なトピックであり、ほぼ誰もが同意するように、ドット・ゼロ問題(例:製品化する前に.2あるいは.3バージョンを待つ)を乗り越える質の改善がキーです。

 

「継続的な供給」のキーはエンドユーザーが、テストではなく、本当に製品を使うことにこそ意味があります。