Veuillez noter que la technologie utilisée pour notre site web n'est pas supportée à 100% par Internet Explorer 6 ou inférieur !

Produkte R-Release R-release FAQ

Produkte


R-release FAQ

Häufig gestellte Fragen zu den R-Releases

Wie werden die neuen Features in den R-Releases entwickelt?

Jedes neue Feature wird ausschließlich im aktuellen Hauptentwicklungszweig (Main) erstellt. Dabei wird jedes Feature so entwickelt, dass es einzeln im Bedarfsfall deaktiviert werden kann. Für jedes Feature werden Tests erstellt, die automatisiert und/oder manuell ausgeführt werden, je nach Art des Features (Dabei bevorzugen wir automatisierte Tests, da diese jederzeit identisch wiederholbar sind).

Da jedes Feature einzeln entwickelt und getestet wird, können wir es auch einzeln in 4D aktivieren oder deaktivieren. Warum das für Sie von Vorteil ist, lesen Sie im Anschluss.

Alle 3-4 Monate erstellen wir von der aktuellen Main-Version einen neuen 4D vxx Rx Zweig. Bei Erstellung des Zweigs werden ausschließlich fertige Features ausgewählt, d.h. die zu 100% getestet sind. Wir deaktivieren alle Features, deren Tests nicht vollständig abgeschlossen sind, selbst wenn diese fast fertig sind. Diese Features werden bis zum nächsten R-Release zurückgestellt.

R-Versionen sind auf Stabilität und Sicherheit ausgelegt. Es werden keine unfertigen Features ausgeliefert, nur um Liefertermine einzuhalten.

R-Releases und Bug Fixes: Sind dieselben Bug Fixes in 4D v15.x und in 4D v15 Rx enthalten?

Nein. Natürlich enthalten R-Releases auch Bug Fixes. Da die Versionen zu unterschiedlichen Zeiten veröffentlicht werden, enthalten Sie auch eine unterschiedliche Anzahl Bug-Fixes. Des weiteren läuft der Entwicklungsprozess der R-Releases anders ab.
 
Sowohl für R-Releases wie für Minor Releases werden Release Notes mit der Auflistung der behobenen Fehler veröffentlicht.
 
Um dies näher zu verdeutlichen, nachfolgend in welchen Schritten ein Fehler in 4D v15.x (oder auch 4D v14.x) behoben wird:

  • Ein Fehler wird z.B. in 4D v15.x gemeldet
  • Der Fehler wird nachvollzogen und in Main korrigiert (4D v15.x).
  • Die Fehlerbehebung wird dann in Main durchgetestet und von unserem Test Team überprüft. Der Test kann einige Tage in Anspruch nehmen, abhängig vom Fehlertyp und seiner möglichen Auswirkung.
  • Wenn nach Abschluss der Tests diese Fehlerbehebung frei gegeben wurde, wird sie in die Version 4D v15.x integriert und am nächsten Tag ein Nightly Build im Nightly Build Forum veröffentlicht.


Sobald die Auslieferung eines Minor Release ansteht, wird der Zweig eingefroren. Dieser Zustand dauert normalerweise 3-5 Wochen. In dieser Zeit erfolgen keine Portierungen von Bugfixes mehr, es werden nur noch manuelle Tests durchgeführt. Nur wenn eine vorausgegangene Fehlerbehebung zu bisher unentdeckten Folgefehlern führt, die von den automatisierten Tests nicht gefunden wurden, wird entweder ein Bugfix zum Bugfix durchgeführt oder der Code des Bugfix wieder entfernt. Dann erst wird die Version als Minor Release freigegeben.

Jede Code-Änderung kann wieder neue Fehler verursachen, deshalb benötigen wir diese 3 Wochen manuelles Testen bzw. zwei zusätzliche Wochen, falls Fehler auftreten (die Änderungen müssen ja wieder getestet werden).

Wie anfangs erläutert, wird die Entwicklung von neuen Features nur im Main-Zweig vorgenommen. So wird zum Beispiel 4D v15 R2 als neuer Zweig vom Main-Zweig erstellt. Somit enthält sie alle neu implementierten Features, sowie alle Fehlerbehebungen, die in Main bis zu diesem Datum durchgeführt wurden.

Funktionen, die zu diesem Zeitpunkt nicht stabil oder fertig waren, wurden deaktiviert und der Zweig anschließend eingefroren. Danach kommt absolut nichts weiteres mehr in diese R-Version (keine last-minute Aktionen, auch keine winzigen Code-Änderungen), außer Fehlerbehebungen für die neuen Features oder Behebungen für große Fehler (wie Showstoppers, Daten-Verluste, etc.). Zwischenzeitlich wird die Version bereits produktiv in unseren internen Systemen eingesetzt. So sichern wir die Stabilität der R-Releases.

Nach diesem Konzept entwickelte Google z.B. Chrome. Lieber ein Update mit bekannten Problemen ausliefern, als eine schlecht getestete Version mit möglicherweise neuen, unbekannten Fehlern. Das ist der große Unterschied zur bisherigen Vorgehensweise, bei der so viele Fehler wie möglich in so kurzer Zeit wie möglich behoben wurden.

Als weiteres Beispiel die 4D v14 R5: Sie umfasst alle Fehlerbehebungen, die bis Ende Mai 2015 in Main durchgeführt wurden. Bis zur Auslieferung wurden diese über mehrere Monate hinweg getestet und nicht nur ein paar Tage lang, wie die Nightly Builds von 4D v15.x. Nur so können wir sicherstellen, dass ein behobener Fehler nicht die nächste Instabilität verursacht. Die Version wird dann für die Auslieferung 3-4 Monate später geplant, also ca. im September 2015.

Wie passen Hotfix-Versionen und Nightly Builds in dieses Konzept?

Hotfix Versionen wurden eingeführt, noch bevor wir Nightly Builds zur Verfügung gestellt hatten. Damals hatten wir einen automatisierten Build Prozess, aber nur einfachere automatisierte Testverfahren.

Eine Hotfix Version wurde ca. 3-5 Tage lang manuell getestet (verglichen zu 3-5 Wochen eines Minor Releases).

Seit 2013 investieren wir massiv in automatisches Testen. Der Build Prozess läuft jetzt stündlich, ausgeführt von einem Cluster von Computern, die automatisch 4D v13, 4D v14, 4D v14 Rx, Main und so weiter erzeugen. Auch Wakanda, das jeweils für Mac OS X 32- und 64-Bit, Windows 32- und 64-Bit, Linux 32- und 64-Bit erzeugt wird. Jedes dieser Builds wird dabei in Englisch und für alle unterstützten Sprachen, wie z.B. Französisch, Deutsch, Japanisch erzeugt. Die erstellten Versionen werden automatisch an ein Cluster von Testcomputern verteilt, wo sie nicht nur Unit Tests, sondern auch viele vollautomatische Tests mit 4D Anwendungen durchlaufen. Wir haben 4D dazu mit verschiedenen Features erweitert, z.B. wurde FORM SCREENSHOT für diese Vorgehensweise entwickelt.

Als Ergebnis haben die Nightly Builds mittlerweile eine Qualität, die mit früheren Hotfixes vergleichbar ist, in vielen Fällen sogar besser.

Wir bauen das natürlich weiter aus. Wir entwickeln weiterhin neue Befehle, um das automatisierte Testen zu vereinfachen und selbstverständlich werden diese neuen Befehle auch unseren Kunden zur Verfügung gestellt.

Wird es Nightly Builds auch für R-Releases geben?

Ja. Nightly Builds wird es geben, aber nur, wenn ein größeres Problem in einem R-Release gefunden wird: z.B. Datenverluste, schwerwiegende Abstürze, etc.

Anders als Nightly Builds in 4D v14 und 4D v15, werden Nightly Builds für R-Releases nicht über das 4D Forum veröffentlicht, sondern über den gleichen Download-Bereich, wie die offiziellen R-Releases (zu dem Link gelangen Sie über Ihr 4D Store Account).

Sind R-Releases zum Produktionseinsatz geeignet?

Unbedingt, Ja! R-Releases liefern Ihnen neue Features, die im nächsten Major Release enthalten sein werden. Verwenden Sie diese Features schon vorab und geben Sie uns Feedback. R-Releases sind viel mehr!

In den letzten Jahren hatten wir früh Beta-Versionen veröffentlicht und gehofft, im frühen Entwicklungsstadium Feedback zu bekommen. Das funktionierte leider nicht. Entwickler schauten nur kurz auf die neuen Features und das war's. Viele Entwickler warteten typischerweise auf die .2 oder .3 Version und begannen erst dann, die neuen Features zu testen und sich näher damit zu befassen. Erst sehr spät hat sich dann herausgestellt, ob die Features wirklich voll einsetzbar waren oder ob Optionen fehlten, die in ihrer Anwendung nützlich wären.

Zu dem Zeitpunkt waren wir dann immer schon kurz vor Beta des nächsten Major-Release. Es war somit schon zu spät, um die Rückmeldungen der Kunden zu berücksichtigen. Dadurch waren manche Features erst zwei bis drei Major Releases später voll einsetzbar.

Letztlich war oft die Qualität nicht voll zufriedenstellend, da so viele Änderungen gleichzeitig erfolgten.

Wie Sie in Computer-Zeitungen (gedruckt oder online) und in Blogs lesen, ist "Continous Delivery" aktuell ein vorrangiges Thema. Die weitgehend übereinstimmende Meinung ist, dass dies die Lösung ist, um die Qualität dauerhaft zu verbessern und von dem .Null Problem weg zu kommen (das Problem, dass alle auf .2 oder .3 warten, bevor sie eine Version produktiv einsetzen).

Und der Schlüssel zu "Continous Delivery" ist wiederum, dass es nur funktioniert, wenn Endanwender das Produkt wirklich im Produktionsmodus einsetzen und nicht nur testen.