Toon posts:

[.NET] Ideale manier

Pagina: 1
Acties:

Verwijderd

Topicstarter
Beste tweakers,

Ik ben hier bezig met het opzetten van een .NET ontwikkelstraat. In principe eerst vooral gespecificeerd op ASP.NET. Ik vroeg mij af of jullie eventueel comentaar, kritiek of andere ideën hebben over het volgende principe:

1. We gebruiken Visual Studio .NET voor ontwikkeling aan ASP pagina's op de lokale IIS van de client PC's.
2. Perforce wordt gebruikt als versie en document beheer systeem.
3. NUnit, NUnit ASP en NUnit Visual studio plugin worden gebruikt om test classen in te bouwen op de ASP methoden.
4. NAnt compileert vanuit Perforce elke nacht een volledige test site wanneer deze goed door de Nunit tests heen komt. Dit wordt gepushed naar de test server.
5. Als iedereen een OK geeft dan wordt het productie schema van NAnt aangezet. Dit schema doet het volgende:

Breekt af + mailt de gebruiker die nog iets heeft uitgechecked van het project;

Als alles is ingechecked worden alle unit tests uitgevoerd met Nunit. Er wordt afgebroken als deze tests niet allemaal ok zijn. De teamleider krijgt hier dan een mailtje van het resultaat;

De huidige perforce versie wordt gelabelt;

De productieserver website wordt opgeschoont, eventueel maakt het NAnt script zelf de virtuele directory aan, stelt deze in en pushed de productieversie naar de productieserver.

De teamleider krijgt een mail met van het productieproces.

We zijn nog steeds aan het denken en verder aan het opzetten. Als iemand nog betere tools of manieren weet horen wij dat natuurlijk graag. Momenteel willen we NantPad gebruiken om het Nant script op te bouwen en is Nant uitgebreid met de Nant Contribute DLL. Het zou alleen mooier zijn als NAnt d.m.v. een sollution import al het grootste deel zelf zou kunnen configureren. Een tool die dit al kan hebben wij nog niet gevonden.

Daarbij is het voor ons fijn dat de NAnt en Nunit tools ook in een iets andere variant door onze Java afdeling wordt gebruikt.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Ik heb zelf alleen ervaring met single-programmer versie van dit verhaal, waarbij het build proces minder complex is. (Voornamelijk JUnit en ANT en ik ben de baas mbt releases). Maar ik ben voor java tegen 'continuous build servers' aangelopen zoals Cruise Control bv. Misschien dat er ook .NET oplossingen voor zijn en dat nuttig is voor jullie gang van zaken.

Goed om te zien trouwens dat ANT en Unit-testen gebruikt worden. Het bespaart zoveeel tijd (alhoewel ANT wel voor verbetering vatbaar is).

[ Voor 5% gewijzigd door Alarmnummer op 01-03-2004 11:10 ]


Verwijderd

Topicstarter
Alarmnummer schreef op 01 maart 2004 @ 11:08:
Ik heb zelf alleen ervaring met single-programmer versie van dit verhaal, waarbij het build proces minder complex is. (Voornamelijk JUnit en ANT en ik ben de baas mbt releases). Maar ik ben voor java tegen 'continuous build servers' aangelopen zoals Cruise Control bv. Misschien dat er ook .NET oplossingen voor zijn en dat nuttig is voor jullie gang van zaken.

Goed om te zien trouwens dat ANT en Unit-testen gebruikt worden. Het bespaart zoveeel tijd (alhoewel ANT wel voor verbetering vatbaar is).
De .NET variant van Cruise control lijkt mij Draco .net: http://sourceforge.net/projects/draconet/ Op hun homepage staat inderdaad "This tool was inspired by CruiseControl developed by ThoughtWorks". Omdat wij nu Nantscripts genereren en die ook 's avonds kunnen schedulen weet ik alleen nog niet zeker of Draco .net nog extra functionaliteit zal bieden.

Het wordt hier inderdaad ingericht voor grotere projecten waar meerdere programmeurs gelijktijdig aan een project werken. Wanneer 1 persoon verantwoordelijk is voor de ontwikkeling tot de in productie name dan zal een dergelijke ontwikkelingstraat als deze zijn doel volgens mij inderdaad een beetje voorbij schieten.

  • Dennis van der Stelt
  • Registratie: Januari 2000
  • Laatst online: 23-05 22:47
Het meeste klink wel goed, hoewel ik zelf niet zoveel ervaring heb met nAnt. Maar ik heb wel één opmerking.

Waarom wordt het proces afgebroken en een gebruiker gemailed als hij/zij een file ingecheckt heeft? Hier hebben we meer ontwikkelaars het over, maar waarom zou je overnacht niet een file ingecheckt kunnen houden?

Als ik aan een stukje functionaliteit bezig ben en daar ben ik een week mee bezig, houd ik dat graag uitgecheckt. Van tijd tot tijd check ik een werkende versie in, maar het kan héél goed zijn dat ik een niet-werkende versie heb tegen de tijd dat ik naar huis ga. Ik vind het dan heel storend om die compileerbaar te maken, terwijl dat eigenlijk niet hoeft.
Je kunt op die manier ook een nUnit test enorm verkloten waardoor het hele proces ook afgebroken wordt.

Just my thought...

Doe maar gewoon, dan doe je al gek genoeg.


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op 02 maart 2004 @ 08:42:
[...]


De .NET variant van Cruise control lijkt mij Draco .net: http://sourceforge.net/projects/draconet/ Op hun homepage staat inderdaad "This tool was inspired by CruiseControl developed by ThoughtWorks". Omdat wij nu Nantscripts genereren en die ook 's avonds kunnen schedulen weet ik alleen nog niet zeker of Draco .net nog extra functionaliteit zal bieden.
Ik geloof dat bij een continuous integration server steeds sources ingechecked kunnen worden en daarbij gaat het systeem fijn alles builden en testen (vandaar de naam). Deze manier van werken verschil dus van jullie opzet doordat je veel vaker integreert (updaten naar de site hoeft niet iedere keer). ANT en junit testen kunnen hierbij geloof ik volledig geintegreerd worden. Het is al een tijd geleden dat ik ernaar heb gekeken, dus mijn kennis hierover is intussen wat mistig geworden.

[ Voor 12% gewijzigd door Alarmnummer op 02-03-2004 09:03 ]


  • Annie
  • Registratie: Juni 1999
  • Laatst online: 25-11-2021

Annie

amateur megalomaan

Verwijderd schreef op 01 maart 2004 @ 10:56:
De productieserver website wordt opgeschoont, eventueel maakt het NAnt script zelf de virtuele directory aan, stelt deze in en pushed de productieversie naar de productieserver.
Je verhaal is duidelijk en klinkt mij goed in de oren. Alleen deze stap zet ik persoonlijk mijn vraagtekens bij. Misschien begrijp ik het toch niet helemaal goed, maar dit klinkt als een automatische, ongecontroleerde (als in: er kijkt niemand mee om eventuele problemen te verhelpen) update van een productieserver. Persoonlijk (me = control-freak ;)) zou ik niet voor deze oplossing kiezen.

Today's subliminal thought is:


  • Riegstar
  • Registratie: Februari 2003
  • Niet online

Riegstar

Wadapatja!

Verwijderd schreef op 01 maart 2004 @ 10:56:
2. Perforce wordt gebruikt als versie en document beheer systeem.
Ken ik niet. Is dat een alternatief voor Visual Sourcesafe? Werkt het prettiger dan VSS en zijn er nog andere goede alternatieven?

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Annie schreef op 02 maart 2004 @ 09:09:
Persoonlijk (me = control-freak ;)) zou ik niet voor deze oplossing kiezen.
Ik ben het wel een beetje met je eens. Een update proces kan om de stomste redenen mislukken zoals bv een ondeletebare directory omdat een of ander proces er nog een lock op heeft. Het zou jammer zijn als het systeem er dan half op zou staan :)

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Het verhaal klinkt goed, ik heb alleen mijn vraagtekens bij het waarom.

Hoe groot moet je website zijn, zodat je voordeel haalt bij zo'n setup? Het lijkt me nl. dat punt 4 binnen 10 minuten toch wel klaar is. Is dat niet wat overkill? Ik bedoel, csc compileert 40.000 regels code een tiental seconden op mijn machine.

Verder zie ik niets over testdata voor je tests. unit-testing van database gebruikende code levert een database op die in een toestand wordt achtergelaten die een volgende test kan beinvloeden.
Ken ik niet. Is dat een alternatief voor Visual Sourcesafe? Werkt het prettiger dan VSS en zijn er nog andere goede alternatieven?
Perforce is een duur sourcecontrol systeem. Ik ken het verder ook niet. Alternatieven zijn bv Subversion, dat niets kost (http://subversion.tigris.org). Ik gebruik het sinds het weekend voor een aantal projects en ik vind het meesterlijk werken.

[ Voor 13% gewijzigd door EfBe op 02-03-2004 09:28 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

EfBe schreef op 02 maart 2004 @ 09:27:
Verder zie ik niets over testdata voor je tests. unit-testing van database gebruikende code levert een database op die in een toestand wordt achtergelaten die een volgende test kan beinvloeden.
Daarom is het ook handig om databases per unit tests te hebben. Dan weet je zeker dat er niets kapot gaat en je weet exact welke data je tot je beschikking hebt. Voor het unit testen gebruik ik zelf een kleine in-memory database die volledig te beheren is met tekstbestanden. Perfect voor unit testen. Hoe lossen jullie dat met .NET op omdat daar de koppeling naar een concrete database geloof ik groter is.

[ Voor 6% gewijzigd door Alarmnummer op 02-03-2004 09:35 ]


  • EfBe
  • Registratie: Januari 2000
  • Niet online
Alarmnummer schreef op 02 maart 2004 @ 09:33:
Daarom is het ook handig om databases per unit tests te hebben. Dan weet je zeker dat er niets kapot gaat en je weet exact welke data je tot je beschikking hebt. Voor het unit testen gebruik ik zelf een kleine in-memory database die volledig te beheren is met tekstbestanden. Perfect voor unit testen. Hoe lossen jullie dat met .NET op omdat daar de koppeling naar een concrete database geloof ik groter is.
Nou, als je echt wilt kun je natuurlijk met een sqlserver job een testdatabase restoren naar een toestand die je verwacht.

Ik vind unit-testen op dit moment niet zo interessant, omdat het me veel tijd kost om de tests te schrijven, ik niet weet of de tests bugfree zijn en het belangrijkste: ik moet veelal database logic testen, en het kost dus erg veel tijd om die tests dus goed te krijgen (telkens databases restoren etc. )

Semantisch testen (testroutines maken die resultaat opleveren en waarbij je zelf de testresultaten controlleert) is IMHO voor database code het beste, althans het kost het minste tijd.

Daarom mistte ik ook database-gerelateerde zaken mbt de unit-tests, omdat die nogal wat tijd kosten.

Ik wil ook nog toevoegen dat unit-tests maar een beperkt gebied testen. Het eigenlijke testen (doet app wat de functionele omschrijving beloofd) is dan nog compleet niet getest.

[ Voor 12% gewijzigd door EfBe op 02-03-2004 10:30 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

EfBe schreef op 02 maart 2004 @ 10:27:
[...]
Nou, als je echt wilt kun je natuurlijk met een sqlserver job een testdatabase restoren naar een toestand die je verwacht.
Dat is idd handig.
Ik vind unit-testen op dit moment niet zo interessant, omdat het me veel tijd kost om de tests te schrijven
Dit is een vrij bekend argument tegen unit testen. Een paar voordelen van unit testen waar ik zelf veel waarde aan hecht is dat je de testen ook kan blijven uitvoeren en ze dus voor altijd (nouja) je systeem verrijken. Je steekt er dus eenmalig extra tijd in maar mijn persoonlijke ervaring is dat deze tijd zich in een veelvoud terug verdient. Verder kan je met unit testen ook geteste subsystemen maken zonder hiervoor eerst het hele systeem klaar te hebben.
, ik niet weet of de tests bugfree zijn
Tja.. mijn ervaring is dat unit tests meestal minder gecompliceerd zijn dan het gene wat je test.
en het belangrijkste: ik moet veelal database logic testen, en het kost dus erg veel tijd om die tests dus goed te krijgen (telkens databases restoren etc. )
Database onderdelen zijn lastig te testen, zeker als je een gecompliceerde database structuur voor de kiezen hebt.
Ik wil ook nog toevoegen dat unit-tests maar een beperkt gebied testen. Het eigenlijke testen (doet app wat de functionele omschrijving beloofd) is dan nog compleet niet getest.
Unit tests zijn idd de 'laagste' tests in je systeem. Maar ik vind ze daarom niet minder belangrijk. Ze besparen me te veel tijd uit om nog zonder te werken. Verder heb ik ANT ook zo ingesteld dat hij mijn source directories afscant naar bestanden die eindigen op TestSuite en hij gaat ze automatisch testen. Ik plaats de testcode dus eenvoudig in het systeem (in apart unittest source directories) en verder heb ik er eigelijk geen omkijken meer naar.


[edit]
Ik zal trouwens die topic niet langer verzieken met mijn unittest verhaal ;)

[ Voor 23% gewijzigd door Alarmnummer op 02-03-2004 11:15 ]


Verwijderd

Topicstarter
Ik wil ook nog toevoegen dat unit-tests maar een beperkt gebied testen. Het eigenlijke testen (doet app wat de functionele omschrijving beloofd) is dan nog compleet niet getest.
Behalve dan met NunitASP http://nunitasp.sourceforge.net een uitbreiding op Nunit die je in staat stelt om een test classe te schrijven voor je ASP pagina's waarbij je dus echt kan zeggen: "Ik klik op die knop, dan moet er dit in het datagrid staan, die knoppen moeten zichtbaar zijn, etc... dan klik ik nu op..." dat alles weer leuk in je Nunit GUI of naar de Nunit gegenereerde XML waar je dan weer rapportjes etc uit kan genereren.

Voor het unit testen gebruik ik zelf een kleine in-memory database die volledig te beheren is met tekstbestanden.
Wij wilden hiervoor MOCK objecten gaan gebruiken http://www-106.ibm.com/de...s/library/j-mocktest.html Ik moet mij hier nog in verdiepen.

Perforce lijkt overigens behalve een mooie source control ook een goed documenten revisiesysteem te zijn. Omdat deze behoorlijk goed integreert in bijna elke IDE (zoals die van Visual Studio .NET), maar ook direct in office, kan dit door iedereen overal voor worden gebruikt. Branching en merging doen ze ook behoorlijk goed. Je kan een trial versie downloaden van www.perforce.com.

Verwijderd

Topicstarter
Heeft iemand ervaring met "SlingShot"? Deze zit in de Nant Contribute tools en wat ik er zo van lees kan deze al een hele build file maken van je solution bestand. Dit is voor ons natuurlijk ideaal, alleen bij ons crashed de SlingShot applicatie.

  • Nexopheus
  • Registratie: Juni 2001
  • Laatst online: 28-01 13:50
Upje!
Erg intressant hier, marre nog meer info ??

Wat niet kan is nog nooit gebeurd


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 10:31

gorgi_19

Kruimeltjes zijn weer op :9

Nexopheus schreef op 17 juni 2004 @ 11:43:
Upje!
Erg intressant hier, marre nog meer info ??
Wat is het nut van deze kick? :? Geef tenminste je eigen mening als je mee wilt doen met een discussie, maar ga niet nodeloos een topic omhoog schoppen... :)

Digitaal onderwijsmateriaal, leermateriaal voor hbo

Pagina: 1