[linux] Re: cross-machine mounts

[Jelle Boomstra]

On Sunday 01 May 2005 22:29, Gerard wrote:
> > > Er zijn vast betere manieren.
> >
> > klinkt als nfs? maar dan moet je wel zorgen dat je aparte
> > configfile buiten de
> > nfs mount staat (symlink?)
>
> NFS! Dat zocht ik ja, ik wist dat ik ergens van iets beters had gehoord.

Als ik zo de rest van je post lees denk ik niet dat je NFS goed zult kunnen 
gebruiken. je wil een versiebeheer systeem, geen filesysteem. 

> CVS en SVN zijn overwogen, maar in dit geval niet echt relevant. Dat soort
> dingen zijn grappig voor users thuis -> opslag server, maar lijken niet
> echt toepasbaar in dev server -> produktie server. Bovendien moet er nog
> een webbased locking systeem komen, want we zitten niet alleen met files,
> maar ook met bijbehorende tables. Voor table sync zullen we zeker zelf
> aan de slag moeten...

Dat CVS niet lockt is met een rede, namelijk dat het in de praktijk niet nodig 
is. over het algemeen remt locking van files development behoorlijk af, en 
nieuwe SCM's doen het dan ook niet meer.
Dat je geen CVS wil gebruiken kan ik mij wel voorstellen: het is namelijk geen 
Sourcecode Configuration Manager (SCM) maar een distributed history tool. 

> > Maken jullie al een test per wijziging, of zijn de wijzigingen
> > van het type:
> > alles wat die developer toen aan het eind van de dag gedaan had
> > (CVS stijl)?
>
> Het moet er zo uit gaan zien; de developer logged in, locked een aantal
> files en/of tables en werkt we aan. Na de wijzigingen geeft ie online
> aan dat de wijziging compleet is en wordt de hele boel gesynced met een
> staging server. 

Ja maar vertel je dus nog steeds niet hoe de wijzigingen samengesteld zijn. 
waar je MI naar toe zou moeten is om per wijziging maar een feature/bug te 
behandelen. daar schrijf je een test bij voor de regressie suite, zodat je 
zonder veel gevaar code kan refactoren: als alle test passeren heb je niets 
bekends gebroken.

> Op de staging zitten zo'n 1000 test users die ook 
> melding krijgen van de wijziging. 

Da's best veel. maar waar het om gaat is: wie neemt de beslissing om een 
wijziging goed te keuren en door te sturen naar productie? Het klinkt een 
beetje alsof je niet per wijziging wil testen, maar gewoon alles opeen hoop 
gooit en hoopt dat de bugs er zo uit vallen. 

> Als deze getest is en goed bevonden 
> wordt ie door gesynced naar de produktie servers.
simpel. als het klaar is doet je systeem een dansje, stuurt wat vrolijke 
mailtjes en kopieert wat code. Niet al te moeilijk (behalve het dansje).

> Daarnaast is er een language subsystem voor het aanpassen en vertalen.
> De meeste vertalers zijn geen developers en mogen dus ook geen toegang
> hebben tot die mogelijkheden. 
de taal is wel onderdeel van je software, het hoort namelijk bij je interface. 
voor regressie testen is het misschien wat moeilijk, maar een wijziging in 
een taalfile is niet anders dan een wijziging in een sourcefile.

> De taal files moeten ook gesynced worden 
> met staging. Daarna moeten SOMMIGE language sets naar bepaalde
> produktie servers, omdat niet alle produktie servers dezelfde talen
> aanbieden.
hmm het word een dansje met een leuke choreografie. Misschien dat je Hans van 
Maanen een opdracht kan geven? (MAW: weinig problemen hier.

Wat ik zo zie zou je eens goed naar aegis moetn kijken, en dan even de 
implementatie die je nu al had bedacht niet te veel je oordeeel laten 
beinvloeden.

In het kort kent Aegis 4 stadia van development, waarin een wijziging zich kan 
bevinden: development, testing, integratie, en baseline. aegis kent meerdere 
rollen voor gebruikers: developers, tester, integrator en admin. Die kunnen 
per project bepaalde handelingen (beginnen aan een change, de change klaar 
verklaren en doorschuiven naar testen etc...)

Aegis regelt al deze status overgangen, controleerd of aan de voorwaarden 
voldaan is en voert ze eventueel uit. Natuurlijk kun je op bijna elke 
overgang je eigen scripts er in hangen die wat huishoudelijk werk kunnen doen 
of bijvoorbeeld de server weer dat dansje laten doen.

En natuurlijk werkt aegis met aparte werkdirectories, zodat je nooit last hebt 
van andere developers die je files overschrijven etc.  (maar dat heb je met 
cvs ook al, en met php met je dan wel wat path magie doen zodat het de juiste 
code ziet)  

> Ter referentie, het gaat om:
> www.barafranca.com (alle talen)
> www.barafranca.nl  (alleen Nederlands)
ksnap er niet veel van, maar heb maar 2 seconden gekeken. text based, heb ik 
daar een 28" plasma monitor voor? 

-- 
met vriendelijke groeten,
Jelle Boomstra

http://linux-studie.nl