Methodes van opzetten van Ontwikkelomgevingen

[neothor]

Voor mij afstuderen ben ik gestart met een onderzoek naar het opzetten van een ontwikkelomgeving. Ik bedoel dan niet iets als Visual Studio, Eclipse oid maar de fisieke omgeving waarin de ontwikkelaars gaan werken.

Ik ben begonnen met informeren bij Google en Collega's. Hieruit kreeg ik de term OTAP, Ontwikkelen-Testen-Acceptatie-Productie, maar meer dan dat krijg ik helaas niet.
Ik krijg veel informatie over ontwikkelomgevingen zoals Visual Studio, Eclise enz.

Mijn vraag is dan ook de volgende. Kennen jullie nog meer methodes voor het opzetten van ontwikkelomgevingen en waar moet ik aan denken. Termen, afkortingen. Alles is welkom zolang ik maar verder kan met zoeken

Als je ervaringen hebt met een bepaalde ontwikkelomgeving hoor ik die ook graag.

[Verwijderd]

Je bent dus op zoek naar processen om software ontwikkeling beter te stroomlijnen? Dan moet je eerder gaan kijken in richtingen als bijvoorbeeld RUP (Rational Unified Proces) wat je een heel framework biedt van initiële analyse tot post project processen.

[neothor]

Ik ben idd opzoek naar de processen. Maar ook naar hardware en software matige zaken. Alles wat erbij komt kijken om ontwikkelaars goed en efficient aan het werk te krijgen.

[ Voor 5% gewijzigd door neothor op 11-04-2008 10:04 ]

[Verwijderd]

Je moet ze los van elkaar zien. Er bestaan geen processen die beschrijven welke hardware en software je moet toepassen.

Hardware is irrelevant, bij software moet je denken aan onderdelen als versiebeheer (svn), trackers (mantis, jira), theme server, ant voor geautomatiseerde builds, tests, en deployment tools.

Ontwikkelprocessen zijn er in vele varianten, waaronder de eerder genoemde erg populaire rup. Dan heb je verder ook nog iteratieve methodes als scrum. Met een beetje zoekwerk is hier veel over te vinden.

Daarnaast zijn er ook net zoveel testmethodieken, voor zowel gestructureerd als ongestructureerd testen van software.

Er is niet echt een holy grail.

[ Voor 18% gewijzigd door Verwijderd op 11-04-2008 10:12 ]

[neothor]

Ik ben ook niet opzoek naar een holy grail omdat ik wel weet dat die er niet echt is

Verder wil ik hardware er toch bij betrekken. Het gaat me dan niet om welke processor enz maar meer om bijvoorbeeld de afweging tussen fysieke tegen virtuele servers enz.

Maar ik kan me iig inlezen over RUP.

[ Voor 7% gewijzigd door neothor op 11-04-2008 10:24 ]

[Hydra]

Wat betreft OTAP: dit gaat inderdaad om verschillende omgevingen met zowel hard- als software. We hebben verschillende klanten die met een dergelijk systeem werken, vooral zodat verschillende teams elkaar niet in de weg zitten.

Ontwikkelaars hebben hun eigen machines, vaak is er dan bijvoorbeeld een ontwikkelbackend waar ze eigen tables in kunnen maken, etc. Je wil over het algemeen niet als ontwikkelaar een enorme SQL server op je machine hebben draaien, in zulke gevallen is het handig een centrale ontwikkel database te hebben.

Testers hebben een eigen omgeving nodig waarop ze nieuwe releases kunnen installeren, als ze met een nieuwe iteratie bezig gaan knikkeren ze de oude over het algemeen weg (weg in de zin van niet live). Dit zou vervelend zijn voor ontwikkelaars als die op dezelfde omgeving werken.

Acceptatie omgevingen bevatten geteste software welke dan door een set 'gebruikers' getest moeten worden. Hierop worden vooral functionele testen gedaan. Dit is een ander set testers (er wordt veel meer black-box getest), die ook geen last moet hebben van het eerste team.

Tenslote is het duidelijk wat productie is, als de software de testen heeft doorstaan wordt het live gezet.

In veel gevallen zijn verschillende omgevingen gemixt, of overlappen ze elkaar (je kunt prima een DB server gebruiken voor Test en Acceptatie als de load niet te hoog is) om kosten te besparen.

[Verwijderd]

Hardware kun je bij je ontwikkel process betrekken in de zin dat je b.v. identieke hardware wilt hebben voor de test omgeving en voor je productie omgeving (als het om server-side software gaat, waar het in zo'n beetje 80% van de gevallen om gaat tegenwoordig, bijna niemand maakt nog desktop apps).

Eventueel valt er op die manier ook iets te zeggen over de hardware van de workstations van de developers. Een afweging kan zijn om ook die hardware redelijk gelijk te trekken aan wat je in de productie draait. Stel b.v. dat je in productie draait met 4 cores en 16GB memory, dan zou je kunnen willen dat er ook ontwikkeld wordt om hier gebruik van te maken. Als de workstations van de developers maar 1 core hebben en 512MB memory, dan is het developen voor 4 cores een stuk rottiger te doen.

Aan de andere kant wordt het ook wel eens gedaan dat de workstations juist expres langzamer zijn dan de productie servers. Dit om ervoor te zorgen dat wat snel genoeg lijkt tijdens development -zeker- snel genoeg is in productie. Het zou namelijk 'per ongeluk' wel eens kunnen voorkomen dat een workstation van een developer toch sneller is; een server die al een aantal jaren draait en een developer wiens machine kapot gaat en waarvoor een nieuwe gekocht wordt. Zo'n workstation kan dan een stuk sneller zijn dan de huidige servers.

[Punkie]

Er bestaat geen "for dummies" boek hiervoor, net zomin als er een handboek bestaat ala "hoe je eigen ruimteprogramma opzetten, van sticks and bones tot intergalactisch contact". Je kan wel vele processen, best practices en dergelijke vinden die elk hun niche hebben. Sommigen beschouwen een groot perspectief, anderen beschouwen enkele een stukje. Je zal veel van deze processen moeten uitkiezen (of delen eruit) en ze samenpassen tot je eigen unieke werkwijze. Je zal moeten experimenteren en zelfs beslissen.

[Hydra]

Verwijderd schreef op vrijdag 11 april 2008 @ 10:53:
Aan de andere kant wordt het ook wel eens gedaan dat de workstations juist expres langzamer zijn dan de productie servers. Dit om ervoor te zorgen dat wat snel genoeg lijkt tijdens development -zeker- snel genoeg is in productie. Het zou namelijk 'per ongeluk' wel eens kunnen voorkomen dat een workstation van een developer toch sneller is; een server die al een aantal jaren draait en een developer wiens machine kapot gaat en waarvoor een nieuwe gekocht wordt. Zo'n workstation kan dan een stuk sneller zijn dan de huidige servers.

Ik denk dat een gemiddeld workstation sowieso het niet gaat halen bij een server, een quad-core is vaak voor developen nogal overkill, maar het lijkt me enorm suf om dat om die reden te gaan doen. Grote multi-tier applicaties halen hun snelheid echt niet uit dat developers 'voelen' dat het wel snel genoeg is. Die halen hun snelheid uit mensen die weten wat de pitfalls zijn in een dergelijke multi-tier multi-threaded applicatie. Dat kun je niet testen door simpelweg serieel requests te doen.

Punkie schreef op vrijdag 11 april 2008 @ 11:32:
Er bestaat geen "for dummies" boek hiervoor, net zomin als er een handboek bestaat ala "hoe je eigen ruimteprogramma opzetten, van sticks and bones tot intergalactisch contact". Je kan wel vele processen, best practices en dergelijke vinden die elk hun niche hebben. Sommigen beschouwen een groot perspectief, anderen beschouwen enkele een stukje. Je zal veel van deze processen moeten uitkiezen (of delen eruit) en ze samenpassen tot je eigen unieke werkwijze. Je zal moeten experimenteren en zelfs beslissen.

Het lijkt mij vooral nuttig om een aantal casussen op te stellen (stuk of 3, van een simpele website tot een groot systeem) en daar een set best practices bij te zoeken en toe te lichten hoe deze toegepast worden. Er is inderdaad absoluut geen simpel antwoord op de vraag hoe een project te beginnen zonder de scope te weten.

[ Voor 29% gewijzigd door Hydra op 11-04-2008 11:50 ]

[neothor]

Zoals ik nu zie is het idd handig om een scope te defineren om het wat makkelijker te maken om de juiste afwegingen te kunnen maken.

Punkie schreef op vrijdag 11 april 2008 @ 11:32:
Er bestaat geen "for dummies" boek hiervoor, net zomin als er een handboek bestaat ala "hoe je eigen ruimteprogramma opzetten, van sticks and bones tot intergalactisch contact". Je kan wel vele processen, best practices en dergelijke vinden die elk hun niche hebben. Sommigen beschouwen een groot perspectief, anderen beschouwen enkele een stukje. Je zal veel van deze processen moeten uitkiezen (of delen eruit) en ze samenpassen tot je eigen unieke werkwijze. Je zal moeten experimenteren en zelfs beslissen.

Ik zoek ook geen handboek oid. ik zoek juist die processen, best pratices enz om een eigen beeld te vormen.

[Verwijderd]

Hydra schreef op vrijdag 11 april 2008 @ 11:48:
[...]
Ik denk dat een gemiddeld workstation sowieso het niet gaat halen bij een server, een quad-core is vaak voor developen nogal overkill

En 640kb is voor altijd genoeg? Een quadcore kost +-220,-. Velen eenvoudige PCs die je amper een workstation kan noemen komen al met een quadcore. Daarnaast is het voor developen zeker geen overkill. Ik draai hier bijvoorbeeld Eclipse die regelmatig background builds doet, daarnaast deploy ik naar een lokale tomcat en maak ik gebruik van een lokale postgres DB. Geloof me, die cores worden lekker bezig gehouden en mijn development PC met quadcore is absoluut sneller en soepelder in het gebruik dan de dual core die ik hiervoor had.

, maar het lijkt me enorm suf om dat om die reden te gaan doen. Grote multi-tier applicaties halen hun snelheid echt niet uit dat developers 'voelen' dat het wel snel genoeg is.

Je snapt niet wat ik bedoel. Ik zeg toch nergens dat het performance testen -alleen- op de workstations van de developers gebeurd en dat het alleen om het 'gevoel' van de developer gaat? Ik noemde expliciet een test omgeving die je in de regel nagenoeg van dezelfde hardware wilt voorzien als je productie omgeving. Indien je productie omgeving heel erg groot is (neem een Hyves ofzo) dan kun je altijd een op een proportioneel geschaalde omgeving terugvallen.

Daarnaast, op het moment dat ik een stuk code parallel schrijf, dan wil ik wel zeker dit ook op mijn workstation kunnen testen en niet een complete deployment moeten doen naar de test omgeving voor code die half in ontwikkeling zit.

Die halen hun snelheid uit mensen die weten wat de pitfalls zijn in een dergelijke multi-tier multi-threaded applicatie. Dat kun je niet testen door simpelweg serieel requests te doen.

En wie zegt dat ik alleen serieel requesten doe? Zo hebben we bijvoorbeeld intern een eigen performance test systeem ontwikkeld, gebasseerd op The Grinder, en ja die kun je gewoon lokaal op je workstation draaien. Dat geeft een goede indicatie in welke richting je moet kijken voor de performance. De ECHTE performance test komt natuurlijk pas bij de deployment naar de test omgeving, maar het is gewoon niet realistisch om dat zelfs met een klein team (+- 12 man) telkens te doen met code die midden in de ontwikkeling zit.

[Boss]

Qua fysieke omgeving moet je maar eens zoeken op bionic office. Het kantoor van FogCreek in New York. Ingericht met de programmeurs in gedachten!

[Hydra]

Verwijderd schreef op vrijdag 11 april 2008 @ 14:15:
En 640kb is voor altijd genoeg? Een quadcore kost +-220,-. Velen eenvoudige PCs die je amper een workstation kan noemen komen al met een quadcore. Daarnaast is het voor developen zeker geen overkill. Ik draai hier bijvoorbeeld Eclipse die regelmatig background builds doet, daarnaast deploy ik naar een lokale tomcat en maak ik gebruik van een lokale postgres DB. Geloof me, die cores worden lekker bezig gehouden en mijn development PC met quadcore is absoluut sneller en soepelder in het gebruik dan de dual core die ik hiervoor had.

Nouja, bedrijven nemen een prijs/prestatie over het algemeen mee in het bepalen welke systemen mensen krijgen. Hoe zwaar je systeem is, is nogal afhankelijk van wat je moet draaien. Ik ga er vanuit dat een bedrijf je, als je hard kan maken dat je het nodig hebt, best een quad-core wil geven.

Je snapt niet wat ik bedoel. Ik zeg toch nergens dat het performance testen -alleen- op de workstations van de developers gebeurd en dat het alleen om het 'gevoel' van de developer gaat? Ik noemde expliciet een test omgeving die je in de regel nagenoeg van dezelfde hardware wilt voorzien als je productie omgeving. Indien je productie omgeving heel erg groot is (neem een Hyves ofzo) dan kun je altijd een op een proportioneel geschaalde omgeving terugvallen.

Je had het over een workstation van een developer. Het lijkt me logisch dat je een testomgeving wilt inrichten die 'nut' heeft. Een volledige productieomgeving dupliceren zal over het algemeen niet gebeuren vanwege de kosten, maar je kunt wel een 'poot' dupliceren. Of dat een systeem oplevert dat te vergelijken is met je productie omgeving is een 2e.

Waar het me om ging is dit:

Aan de andere kant wordt het ook wel eens gedaan dat de workstations juist expres langzamer zijn dan de productie servers. Dit om ervoor te zorgen dat wat snel genoeg lijkt tijdens development -zeker- snel genoeg is in productie

Jij had het over workstations, ik zie dat als de machines waar op de developers werken, de O in OTAP dus, de T en A omgevingen zijn over het algemeen veel groter geschaald. Een klant van ons gaat z'n A omgeving op 1/4e van de P omgeving schalen, en dat is voor dat bedrijf al een enorme investering.

Daarnaast, op het moment dat ik een stuk code parallel schrijf, dan wil ik wel zeker dit ook op mijn workstation kunnen testen en niet een complete deployment moeten doen naar de test omgeving voor code die half in ontwikkeling zit.

Hmmja? En?

En wie zegt dat ik alleen serieel requesten doe? Zo hebben we bijvoorbeeld intern een eigen performance test systeem ontwikkeld, gebasseerd op The Grinder, en ja die kun je gewoon lokaal op je workstation draaien. Dat geeft een goede indicatie in welke richting je moet kijken voor de performance. De ECHTE performance test komt natuurlijk pas bij de deployment naar de test omgeving, maar het is gewoon niet realistisch om dat zelfs met een klein team (+- 12 man) telkens te doen met code die midden in de ontwikkeling zit.

Ik zeg toch niet dat jullie het verkeerd doen? Ik heb het alleen vaak genoeg verkeerd zien gaan. Bedrijf als Sogeti dat het voor mekaar krijgt een applicatie in productie te zetten welke botweg crashed als de load hoger wordt dan de backend aankan. Nooit gehoord van graceful degradation.

[elhopo]

m.b.t de architectuur kan je kijken naar de volgende onderdelen:

• Functioneel
• Code
• Structuur
• Concurrency
• Oplevering
• Gebruiker
• Business

dit geldt althans voor het ontwikkelen van applicaties. Wellicht kan je hier ook wat mee doen voor de hardware. Ik zou denken (in een ideale wereld) aan een virtual pc: je richt 1 x een compleet "image" in en vervolgens kan je die voor iedere developer gebruiken. Scheelt een hoop installeerwerk per developer. Bij ons hebben ze aparte ghost images hiervoor, maar voor een kleiner bedrijf is dat minder handig lijkt me. Een ontwikkelomgeving optuigen is vaak lastig (IDE, webserver, database, ... + sources uit de repository halen, version control systeem, enz) je bent zo een dag kwijt.

Wanneer je een virtuele PC optuigt hoef je dat maar eenmaal te doen, en alle ontwikkelaars kunnen e dan zo mee aan de slag. Tevens kan je zo'n image voor een deployment / continous build systeem gebruiken...

succes in ieder geval!

[JKVA]

Een stukje OTAP ervaring/persoonlijke frustratie van mijn kant. Zorg dat je A omgeving volledig gelijk is aan je P omgeving (behalve dat het niet voor de hele wereld openstaat).

Verschillen zoals Load balancers, firewalls, routers, DMZ's, clustering, distributie en security settings worden vaak over het hoofd gezien of gewoon negeerd, waardoor vaak problemen optreden bij de livegang.

Qua performance zijn A en P vaak sterk overeenkomstig (geheugen/processor), maar infrastructureel zie je ontzettend veel verschillen. En daar treden vaak problemen op, zeker bij grotere bedrijven met langere/complexere ketens.

Zo heb ik al meerdere projecten gezien waarin software een paar maanden live draait en de business mensen zich maar afvragen waarom er geen [vul product in] in de database komen.

[Hydra]

JKVA schreef op vrijdag 11 april 2008 @ 16:09:
Een stukje OTAP ervaring/persoonlijke frustratie van mijn kant. Zorg dat je A omgeving volledig gelijk is aan je P omgeving (behalve dat het niet voor de hele wereld openstaat).

Dat gaat je, gewoon vanuit financiele overwegingen, vaak niet lukken in echt grote systemen. Neem nou iets als Hyves bijvoorbeeld, die kunnen moeilijk hun hele P omgeving spiegelen Idealiter zou je het graag doen natuurlijk, alleen al om toch je bijdrage aan het broeikaseffect te leveren, maar het kost gewoon heul duur

Daarnaast is een goeie A omgeving geen voorwaarde dat er goed getest wordt. Een klant van ons heeft net een 3e A omgeving opgetuigd. Ik weet niet wat die testers precies uitvoeren, maar veel bijzonders is het niet.

[flowerp]

Hydra schreef op vrijdag 11 april 2008 @ 14:42:
Nouja, bedrijven nemen een prijs/prestatie over het algemeen mee in het bepalen welke systemen mensen krijgen. Hoe zwaar je systeem is, is nogal afhankelijk van wat je moet draaien. Ik ga er vanuit dat een bedrijf je, als je hard kan maken dat je het nodig hebt, best een quad-core wil geven.

Ik vind het een beetje raar dat er bedrijven zijn die kennelijk een paar tientjes op de workstation van een developer zitten te besparen? Een beetje vreemd, want developers zijn tegenwoordig aardig duur en schaars. Bij ons zijn ze ook zeker niet super gul, maar krijgt elke nieuwe developer default een vrij standaard Dell Precision T3400 met een Q6600 (dat is dus een quadcore) en 2GB ram. Vrij basic en recht toe recht aan ding. Net even opgezocht wat zo'n machientje kost, en dat is 862,-.

Ik proef een beetje uit jouw verhaal dat jij dat een overdreven zware machine vind voor een developer, maar als je op zo'n marginaal bedrag nog gaat lopen te besparen dan weet ik het ook niet. Dit is bij ons echt de basic config. Voor specialistische taken worden er wel zwaardere workstations ingezet.

Ook in mijn ervaring geeft een quad voor veel ontwikkeling taken voordelen. Je local DB, je local AS, je unit testen op de achtergrond, de real-time compilation die telkens op de achtergrond plaats vind, etc etc. Alles gaat een stuk soepeler en je developers zitten minder lang te wachten op een traag systeem. Als de IDE na een save van je file net even die seconde eerder reageert en je local AS een paar seconden sneller gerestart is , dan geeft dat al een enorme winst. En dan voor dat luttle bedrag als hierboven genoemd? Waar hebben we het helemaal over?

Je had het over een workstation van een developer. Het lijkt me logisch dat je een testomgeving wilt inrichten die 'nut' heeft. Een volledige productieomgeving dupliceren zal over het algemeen niet gebeuren vanwege de kosten

Het hangt natuurlijk sterk af van de grote van het system wat in productie draait. Zo hebben wij b.v. 1 applicatie in productie draaien waar goed mee verdient wordt, en waarvan de servers waar het op draait bescheiden zijn. 1 oct core DB, slechts 1 quad core web front end, en 2 eveneens quad core 'business logic' servers. Ik meen dat ik de systeembeheerder wel eens bedragen heb horen noemen van rond de 15.000 voor deze config. Deze kan dus exact gedupliceerd worden, tot op de versies van de firmware in de controllers aan toe.

Bij andere applicaties die in producties op een hele farm van servers hangen is het inderdaad niet mogelijk. Daar hebben wij een (veel) kleinere test omgeving voor die wij testen met een navenant lagere load. Als je echt de grote van een Hyves hebt dan zit je sowieso tegen hele andere getallen aan te kijken. Geen idee hoe die jongens dat doen, maar met hun load kunnen de flauwste dingen er opeens uit klappen in productie.

Jij had het over workstations, ik zie dat als de machines waar op de developers werken, de O in OTAP dus, de T en A omgevingen zijn over het algemeen veel groter geschaald.

Ik weet dat het bijna niet meer voorkomt, zeker niet in Nederland, maar er bestaat (bestond?) ook nog zoiets als desktop software development. Daar heb je het veel sterker dat de machine waarop je wilt ontwikkelen het liefst juist wat langzamer is dan de gemiddelde machine waar jouw klanten je pakket op gaan draaien.

Daarnaast zijn lang niet alle systemen volledig gericht op publieke web applicaties met een hoog bezoekers aantal of op transactie systemen met miljoenen transacties. Wij maken ook b.v. specialistische (web) applicaties voor intern (intranet) gebruik, b.v. bij laboratoria. Op zo'n systeem zit dan hooguit een mannetje of 20 te werken, in de avond uren en 's nachts nog minder (sommige laboranten schijnen nog als eens de hele nacht door te werken). Voor dergelijke applicaties komt de snelheid van 1 single request die ik op mijn workstation doe wel zeer zeker in de buurt van wat een gebruiker van zo'n applicatie zal ervaren.

[... quadcores gebruiken voor testen parallelle software...]
Hmmja? En?

Ik snap deze comment van jou niet helemaal. Iemand stelt dat een quadcore voordelen heeft bij developen, jij zegt dat dit onzin is, dan komt er een usecase waar het nodig is om parallelle software te testen, en dan reageer jij met "En?" ???

Zie ook het topic op got wat hier speciaal over gaat, maar zoals je weet worden enkele cpus amper meer sneller en moeten we het in de nabije toekomst voornamelijk van steeds meer cores gaan hebben. Software ontwikkelaars moeten hier op in spelen door hun software expliciet te parallelliseren. Het is lang niet bij elk systeem zo dat de aanwezige hardware volledig kan worden beziggehouden door de veelvoud aan requesten. Soms heb je gewoon te maken met systemen die in plaats van veel goedkope requesten, enkele zware requesten krijgen.

Op mijn werk hou ik me oa bezig met het ontwikkelen van parallelle algoritmen, en die zal ik toch echt op een multi-core telkens moeten testen. Als workstation heb ik dan ook een oct-core staan, zodat ik eenvoudig tijdens ontwikkeling makkelijk kan testen hoe de code schaalt van 2 cores, naar 4 cores en dus ook naar 8 cores. Af en toe een lockje net wat anders inrichten en het schaalt weer een stuk beter van 4 naar 8, terwijl dit effect van 2 naar 4 helemaal niet zichtbaar was. En voor je helemaal uit je dak gaat over hoe overdreven zwaar een oct core is voor development; het is gewoon de standaard Mac Pro config van Apple

[JKVA]

Hydra schreef op vrijdag 11 april 2008 @ 16:14:
[...]


Dat gaat je, gewoon vanuit financiele overwegingen, vaak niet lukken in echt grote systemen. Neem nou iets als Hyves bijvoorbeeld, die kunnen moeilijk hun hele P omgeving spiegelen Idealiter zou je het graag doen natuurlijk, alleen al om toch je bijdrage aan het broeikaseffect te leveren, maar het kost gewoon heul duur

Daarnaast is een goeie A omgeving geen voorwaarde dat er goed getest wordt. Een klant van ons heeft net een 3e A omgeving opgetuigd. Ik weet niet wat die testers precies uitvoeren, maar veel bijzonders is het niet.

Het probleem van een P omgeving is dat je daar niets op kunt doen, tenminste niet als er al een draaiende applicatie staat. En bij bedrijven met wat grotere ketens en grotere, meer bedrijfskritische systemen (zoals financiele organisaties) merk je dat je een productiename veel soepeler kunt laten verlopen als je in een vergelijkbare A omgeving de boel goed getest hebt.

De punten uit mijn vorige post zijn zijn problemen die je regelmatig bij dergelijke organisaties tegenkomt, vaak veroorzaakt omdat niemand de hele infrastructuur met alle quirks kent.

Gevolg, problemen zoals bij de Belastingdienst. En dat kost meer geld (en imago) dan een fatsoenlijke teststraat.

Maar je hebt gelijk dat een goede infrastructuur niet meteen een goede test betekent. Maar het wordt wel stukken gemakkelijker en voorspelbaarder.

[Alex]

Leuk, praten over Hyves, maar daar heeft onze TS weinig aan. Een dergelijke omgeving heeft veel meer haken en ogen als onze TS wat aan heeft. Je loopt tegen limieten aan die zelfs infrastructuur technisch niet te overbruggen zijn.

Ontwikkelomgevingen:
Ik onderscheid over het algemeen 2 dingen:
1. Q&A omgeving. Dit is de ene keer een OTAP/DTAP(gangbare engelse term). Of een OAP(of dit wenselijk is of niet laat ik in het midden). Of een OTACP(Content stage er tussen, zeer gangbaar bij hedendaagse websites).
2. Ontwikkelstraat. Tooling, quidelines en best practices voor ontwikkeling.

Q&A omgevingen draaien voornamelijk om processen. Hoe goed is alles ingeregeld? Wat denkt men van preiodieke database refreshes(P -> O). Hoe is een database update geregeld? Wat zijn de stappen van een individuele backupslag en restore slag? Waarin verschilt deployment op O van P?
Er komt hier ook een organisatorisch perspectief bij kijken: wie regelt dit? Wie is er verantwoordelijk tot waar, de Infrastructuur boys of development team(incl Q&A team)?

Q&A omgevingen worden vaak gevalueerd op basis van representativiteit. Dus een geclusterde Productie betekent idealiter een geclusterde Ontwikkel omgeving. Dit levert ook altijd leuke taferelen op.

Mooi voorbeeld:
Een developer maakt een apart project van zijn Business en Data-layer, maar als je hem vraagt op welke 'Node', dit subsysteem draait, krijg je als antwoord: Maar ik hoef toch niets te weten van infrastructuur?
Mijn standaard antwoord(sluit aan bij flowerp's gedachten gang): Leuk, maar ooit een technisch ontwerp gemaakt? Dan heb je waarschijnlijk het kopje hardware mapping over het hoofd gezien .


Dan de ontwikkelstraat. eigenlijk denk ik dat dat iets is wat je start is. Hierin maak je met een team beslissingen over hoe je software ontwikkeling aan pakt. Wat de processen zijn(RUP,SCRUM, MSF, etc), welke onderdelen je onderscheid(Architectuur keuzes als software, middle ware, frameworks, architectuur patterns). Daarna komen development afspraken. Dit zijn dus code guidelines. Maar ook dingen als Agile development, XP, code reviews, etc.

Een laatste dingetje is documentatie. Deze past overal. Echter er dient een zwaarte punt te liggen. Dit verschilt per organisatie en vooral per indeling van proces. Ook verschilt dit per project methode en ontwikkel methode. Als daar de beheermethodes nog bij komen snap je dat de poppen aan het dansen zijn.

TS: dit is jouw stage opdracht. Leuk, maar uhmmm waar begint het en waar stopt het? Dit hele verhaal kost grote organisaties als bijv Atos Origin, Logica en InfoSupport tussen de 12 en 36 maanden om uit te rollen. De organisatie analyse en PvA(om maar een mooie schoolterm te pakken) kosten bij deze organisaties minstens evenveel tijd. Ik ben dus benieuwd:
- Wat is je opdracht?
- Waar stopt het?
- En hoe de f*&^#@$ heeft jouw school zoiets goed kunnen keuren

[Verwijderd]

JKVA schreef op zaterdag 12 april 2008 @ 12:29:
Gevolg, problemen zoals bij de Belastingdienst. En dat kost meer geld (en imago) dan een fatsoenlijke teststraat.

Als je niet weet waar je over praat, zeg dan niets. Dit komt zo over als "mag ik ook wat zeggen, mag ik, mag ik, ik wil ook meedoen". De problemen bij de belastingdienst hebben totaal niet te maken met staging, test- en productieomgevingen. ... en ja, ik weet wel waar ik over praat.

[NetForce1]

Verwijderd schreef op maandag 14 april 2008 @ 09:58:
[...]


Als je niet weet waar je over praat, zeg dan niets. Dit komt zo over als "mag ik ook wat zeggen, mag ik, mag ik, ik wil ook meedoen". De problemen bij de belastingdienst hebben totaal niet te maken met staging, test- en productieomgevingen. ... en ja, ik weet wel waar ik over praat.

Dan is het misschien wel aardig om daar wat meer over te zeggen, want nu moeten we jou maar op je woord geloven... (dan nog steeds natuurlijk, maargoed) Of is het allemaal 'confidential information'?

[Janoz]

Het is maar net hoe je 'problemen' interpreteert. Interpreteer je dit als een benoeming van wat er binnenin de organisatie gebeurd, dan zou je inderdaad gelijk kunnen hebben. Daarvoor heb je inderdaad inside information nodig.

Ik vermoed echter dat JKVA met 'problemen' bedoeld, wat wij als buitenstaander zien. Het al tijden in productie hebben van niet werkende code op een redelijk triviaal onderdeel is een typisch gevolg van een niet goed ingerichte OTAP straat. Los van of dit bij de belastingdienst ook het geval is zijn het problemen die normaalgesproken bij de ketentest al naar boven komen.

[Alex]

Wederom praat men alleen maar over ver gevorderde processen. En de gevolgen van Ontwikkel omgevingen. De TS vraagt wat anders...

[BCC]

Janoz schreef op maandag 14 april 2008 @ 10:42:
Ik vermoed echter dat JKVA met 'problemen' bedoeld, wat wij als buitenstaander zien. Het al tijden in productie hebben van niet werkende code op een redelijk triviaal onderdeel is een typisch gevolg van een niet goed ingerichte OTAP straat. Los van of dit bij de belastingdienst ook het geval is zijn het problemen die normaalgesproken bij de ketentest al naar boven komen.

Dat mis ik in dit verhaal een beetje: Unit tests, Functional tests, Integretion tests, Nightly Builds / tests, gebruikers/selenium tests. Dat is imho de enige manier om goede en onderhoudbare software te ontwikkelen.

Dit testproces ondersteun je vervolgens met een bak tools (versioning, bug-tracking, etc etc), maar die tests is waar je basis moet liggen.

[Janoz]

Alex schreef op maandag 14 april 2008 @ 11:02:
Wederom praat men alleen maar over ver gevorderde processen. En de gevolgen van Ontwikkel omgevingen. De TS vraagt wat anders...

Hoezo vergevorderd? Een otap straat schaalt zelfs terug naar een omgeving waar maar 1 developer zit (alhoewel het dan vaak wordt teruggebracht tot een oap straat). Gevolgen van de keuze voor een specifieke ontwikkelomgeving zijn precies de argumenten om wel, of juist niet voor die omgeving te kiezen.

Ik zie niet waarom dat niet bij de vraag van de topicstarter aansluit.

[neothor]

Alex schreef op maandag 14 april 2008 @ 00:09:
TS: dit is jouw stage opdracht. Leuk, maar uhmmm waar begint het en waar stopt het? Dit hele verhaal kost grote organisaties als bijv Atos Origin, Logica en InfoSupport tussen de 12 en 36 maanden om uit te rollen. De organisatie analyse en PvA(om maar een mooie schoolterm te pakken) kosten bij deze organisaties minstens evenveel tijd. Ik ben dus benieuwd:
- Wat is je opdracht?
- Waar stopt het?
- En hoe de f*&^#@$ heeft jouw school zoiets goed kunnen keuren

Een onderdeel van het afstuderen is een onderzoek. Hiervoor heb ik dit onderwerp voor gekozen omdat het mij intereseerd. Ik hoef het niet uit te rollen en het hoeft geen volledig stappenplan of pva te zijn.

Verder zijn dit grotendeels hele nuttige posts. Het geeft mij genoeg input om op te zoeken.

[maxtrash]

google ook eens op CMM en CMMi

[valdi]

Allereerst excuus voor het omhoog schoppen van dit topic. Dit is echter het enige relevante topic waar ik in de search tegenaan liep en m'n vraag is in mijn ogen niet groot genoeg voor een eigen topic.

Waar het om gaat, we hebben hier een aantal (30+) applicaties die de OTAP doorlopen. We lopen op het moment alleen tegen wat versiebeheer aan. Wat ik eigenlijk zoek is een applicatie waar ik per stage kan aangeven welke versie er op dat moment geïnstalleerd is.

Ideaal zou zijn om een package in "start" (hier "packaging" geheten) in te typen, en die vervolgens na deplyment met een klik op de knop naar de volgende stage door te kunnen zetten in de applicatie. In een onderliggend niveau zouden we vervolgens per package kunnen specificeren wat er dan in de package zit en welke veranderingen er doorgevoerd zijn, welke developer ze gemaakt heeft etc.

Het gaat me dus niet zozeer om ook de source files in deze tool te bewaren, maar meer om de procedures omtrent het releasen inzichtelijk te maken.

Mijn vraag; is iemand bekend met software die dit kan? Google is hier normaal wel behulpzaam is, maar ik kom er dit maal echt niet uit.

edit: Wat ik me nu net nog bedenk, wat nog genialer zou zijn; ik upload een package naar de tool, die plaatst hem dus in packaging, als ik vervolgens op "deploy to test" klik, doet 'ie dat ook daadwerkelijk zelf en houdt vervolgens ook bij dat dat gebeurd is.

Een soort automatische release tool die ook versies bijhoudt.

edit 2: Aan de TS: Gaat het onderzoek dat je gedaan hebt/mee bezig bent ook gepubliceerd worden, ik zou het graag willen inzien!

[ Voor 16% gewijzigd door valdi op 20-08-2008 15:50 ]

[BCC]

Er zijn op dit moment volgens mij geen bekende (opensource) deployment tools. De meeste bedrijven gebruiken inhouse tools, ook omdat het vaak nogal om specifieke wensen / eisen gaat.

Het enige wat mij zo te binnenschiet is locomotion, maar dat is zo alfa, dat je er voorlopig nog niets aan hebt: http://github.com/micheljansen/locomotive/

[whoami]

> DTE