OTAP ontwikkelomgevingsarchitectuur

[Xymox]

Ik zou hier graag wat meningen willen horen, mogelijke implementaties (ideaal of pragmatisch) hoe de verschillende omgevingen voor software ontwikkeling vorm gegeven kunnen worden.

Je ziet nu steeds vaker, vooral bij de grotere bedrijven dat men overstapt op OTAP omgevingen, waarbij de software ontwikkeling plaatsvindt in O (Ontwikkel), module/component tests in T (Test), acceptatie tests in A (Acceptatie) en uiteindelijk bij de eindgebruiker in productie wordt genomen P (Productie).

Door het scheiden van functies en omgevingen wil men duideljke procedures opstellen zodat software ontwikkeling het OTAP model volgen. Echter wat ik ook vaak zie is dat men vanuit een glazen huis van bovenaf oplegt wat iedereen mag en kan in de verschillende omgevingen en een zo standaard mogelijke omgeving ontwerpt.

Wat omgevingsarchitecten ook vaak niet meenemen in hun ontwerp is dat niet elke ontwikkelomgeving of eindgebruiker dezelfde is. Een Java/Web ontwikkelomgeving is fundamenteel anders dan het ontwikkelen van Windows applicaties die niet server based werken. Een web applicatie draait binnen een webbrowser en staat eigenlijk los van het workstation waar de webbrowser instantie draait. Een windows applicatie is veel meer afhankelijk van de specifieke workstation eigenschappen en de daarop geinstalleerde applicaties.

Ook deployment naar de verschillende omgevingen en uiteindelijk de manier waarop de eindgebruiker het gebouwde product aangeboden krijgt kan erg verschillen tussen de ontwikkelstraten. Een webapplicatie wordt op een server gedeployed, een eindgebruiker connect via een webbrower naar die server en heeft in princiepe weinig te maken met locale installaties.
Een windows binary draait lokaal op een workstation, vanaf een fileserver of geinstalleerd via een kopieer proces van een deployment server of is gepackaged om via bijvoorbeeld SMS te worden gedeployed.

Ik ben een software ontwikkelaar die Windows binaries bouwt. Het is puur Client/Server, geen web/html/java etc.

Het probleem waar ik nu tegenaan loop is dat de omgevingsarchitecten een Web/Java OTAP omgeving hebben ontworpen die wellicht voor Web/Java ontwikkeling prima past. Bijvoorbeeld het ontwikkel workstation is een erg gestripte versie van een echte productie machine. Er staat lokaal een ontwikkel omgeving op en men kan alleen in de ontwikkel architectuur werken. Geen connecties naar andere omgevingen en geen productie applicaties (zoals een email client). Deployment gaat via een deployment server. Zo'n ontwikkel workstation is dus een erge simpele machine met alleen tools voor de ontwikkelaar. Voor de beheerders lekker goedkoop beheer !

Jammer genoeg heeft men nooit onderzoek gedaan wat de andere ontwikkelstraten precies nodig hebben voor de ontwikkeling van hun software en deployment van binairies. Dat was wellicht te moeilijk of te duur om op te pakken en heeft het gelaten bij de Web/Java straat.

Men praat nu dus over DÈ ontwikkelomgeving. Er is geen andere en de andere ontwikkelstraten dienen nu ook in die omgeving te werken.

Ik kan nu reeds al zeggen dat zo'n overstap niet gaat werken. Onze software ontwikkeling heeft andere eisen aan de omgeving. Het grappige is dat het veel energie kost om uit te leggen dat er überhaupt een verschil is tussen te ontwikkel straten.

Een voorbeeld :

Als men uitgaat van een gestript workstation, zonder enige applicaties die ook op een echte productie machine staan en die alleen connecties mag maken naar ontwikkelservers, hoe kan een Windows ontwikkelaar dan een integratie bouwen tussen een applicatie en de gebruikte email client ?

Zonder lokale installaties van productie software kan dat gewoon niet. Geen installatie geen API !!!

In mijn ogen moeten wij productie-like machines hebben die uiteraard wel verbindingen maakt met ontwikkel achterlanden, maar wel qua architectuur zo volledig overeenkomt met de productie situatie.
Ik heb al regelmatig meegemaakt dat bepaalde applicaties elkaar bijten zodra ze samen op één workstation gedraait worden. Ik kan dat alleen detecteren/debuggen als ik al die applicaties tot mijn beschikking heb. Het kan toch niet zo zijn dat een applicatie door ons gebouwd prima draait in OT en A, maar niet in P ? Dit zou opgelost worden door de A omgeving vrijwel gelijk te stellen aan P wat architectuur betreft. Dat de A omgeving een eigen A achterland heeft is duidelijk, maar het workstation moet zoveel mogelijk 1:1 te zijn met een productie machine.

Nu ben ik erg benieuwd hoe men dat elders opgelost heeft. Hoe zien de gekozen omgevingen daar uit ?
Wat kan een ontwikkelaar wel en niet en wat zijn de voor en nadelen van een bepaalde architectuur ?

Let wel, ik heb het dus over Client/Server Windows binairy applicaties. Geen Web/Java/HTML !!!

[Gé Brander]

De ontwikkelaars zouden prima uit de voeten moeten kunnen met 1 workstation met daarop virtual pc, virtual server of vmware like applicatie, waarbij je verschillende servers na kan bootsen. Dat is een ideale oplossing, ook omdat je met images, makkelijk een nieuwe verse omgeving op kan bouwen als project 1 klaar is. Zo hou je geen oude configuraties over die eigenlijk niet een kopie zijn van de productie omgeving. Je hebt dan ook een duidelijke scheiding tussen een client virtual pc en de server virtual pc.

Waarom je geen beschikking hebt over de applicatie, verbaast mij wel. Hoe kan je dan testen of, datgene wat je bouwt ook werkt?

Bij veel Microsoft producten, geldt de regel, dat je alleen de licenties vol moet betalen in een productie omgeving, en dat er in acceptatie, test en ontwikkeling omgevingen een veel lager bedrag aan licentie kosten betaald dient te worden. Vraag dat eens na voor kostenbesparingen...