nicht angemeldet
Aha,
nun gut dann lasse ich Dir Deine Ahnung.
In unserem Hause ist jedes System "Produktiv" welches in einem QS oder Produktionsprozess befindet.
Der Aufwand eine grössere Applikation die an verschiedenen Datenbankservern hängt sowie eine gewisse Infrastruktur vorraussetzt ist hier einfach nicht mehr realisierbar.
Nur mal schnell einen Testserver online zu bekommen würde hier mindestens 1 Monat dauern.
Freigabe durch die Security wäre das kleinste Problem.
Dass ich bestimmt nicht den für die Kunden drausen betriebenen Server als erstes migriere ist ja wohl keine Frage.
Jedoch ist aus Sicht der QS die Entwicklergruppen ebenfalls Kunde.
Die bezahlen dafür, dass die QS eine Testumgebung zu verfügung stellt die jetzt auf Bea 7 migriert werden soll. Par definition ist somit dieses System ebenfalls produktiv.
Mein Fragestellung war lediglich diese:
Was zu beachten ist und welche Probleme auf einen zu kommen.
Nicht ob ich dafür einen Testfall bauen muss.
Was soll den die Testsuite deines erachtens prüfen ob der Server hoch fährt und was er für Fehlermeldungen von sich gibt?
Dafür gibt es Logfiles und das Auge, das erkennt, dass der Server nicht hoch fährt. Mehr kannst du dabei nicht testen.
Danach muss so oder so getestet werden.
Die Frage was man vorher zu beachten hat kannst du nicht beantworten.
So fragen, können weiterhin war Archive deployt werden.
Müssen bestimmte konfigurationen geändert werden.
Teilweise weiss ich inzwischen, dass viele Konfigurationen angepasst werden müssen.
Ein deployment descriptor sieht völlig anderster aus.
Und wenn man das Domänen konzept von Bea seit V7 nützen möchte gibt es eine ganz hand voll zu beachten.
Die Realms von Bea haben sich stellen weise geaendert.
EJB 1.1 und 2.0 gleichzeitig zu deployen nicht ganz ohne Probleme.
Das Ziel alles auf 2.0 bringen.
Einfach mal behaupten hach dafür brauchst Du eine Testsuite ist ein prima Aussage ohne zu wissen was Du testen willst.
Und allein beim deployment und starten der Server macht eine Testsuite sehr viel sinn.....
Und danach ist es zu spät!!
Wenn der neue Server läuft. Der auch parallel zum alten betrieben werden könnte, will ich nicht erst dann oder beim starten die Probleme herausfinden sondern schon im vorfeld die gesammte Entwicklung davon informieren wo welche Änderungen notwendig werden.
Um den grössten Teil der Probleme... -> deployment.xml falsch
welche kleiner Ursache sind erschlagen.
Weil für spielchen Ach jetzt geht das nicht mehr und dieses...
haben wir und auch ich keine Zeit.
Deswegen ist eine evaluierung schon von vorne herein notwendig.
Und deswegen behaupte ich nochmals, Du bist bestimmt ein toller Entwickler aber von migrationen und deren notwendigkeiten hast du keine Ahnung. Und QS setzt eine gute Planung voraus.
Eine Testsuite ist an der Stelle zu spät.
Denn wenn dann muss die Testsuit nur noch schauen ob das was migriert wurde wieder läuft.
Dazu muss jedoch der APPserver auch hoch fahren.
Und damit der sicher hoch fährt ist es vorher schon wichtig möglichst alles auf dem Stand zu haben, dass es läuft.
Fehler tretten dann mehr als genug auf.
Weisst du wieviel Geld es kostet, wenn ein System steht und die Entwickler (in diesem Projekt 150) darauf warten weiter zu machen?
Da kann ich lange recherchieren dafür.