[Bitrepository-devel] Integrationsmiljø

Kim Teglgaard Christensen ktc at statsbiblioteket.dk
Wed Jan 18 09:02:05 CET 2012


Jeg ved ikke hvor heldigt det vil være at anvende version numre i
forbindelse med destinations. Jo det vil helt klart gøre at cross talk
mellem forskellige version ikke burde kunne ske, men er det reelt et
problem? Jeg håber da at vi laver et system hvor komponenterne i
forvejen er imune over for det. Enten ved at hvis de modtager en gammel
version af en besked rent faktisk kan forstå den (beskeden er ikke
blevet ændret over versionerne), eller også kan den slet ikke forstås og
vil blive afvist ved validerings trinnet?
Desuden vil et cross talk eksempel, muligvis også udløse nogle alarmer,
hvilket vil give os lejlighed til at få lidt data der også. 
Yderligere, er vi sikre på at vi ved hver release af vores system vil
have en opdateret udgave af message-xml, og kender collectionsettings
til hvilken udgave af message-xml vi anvender?

Jeg helder stadig til at vi har nogle 'annonyme' navne der ikke har
holdning til hvad vi pt peger på. 
Ideen med at have tre lyder dog rigtig godt, en 'old-stable', en
'next-stable' og en 'rollout' som så kan rotere. 

Mvh Kim


On Tue, 2012-01-17 at 15:05 +0000, Michael Rasmussen wrote:
> Idéen er god, så man (forhåbentlig) undgår at forstyrre et ellers virkende miljø, men kunne det samme ikke opnås ved at navngive de ting, der skal navngives (alarm/collection-destination måske lidt andet?), som f.eks. integration-${message.xml.verson} i stedet? Så undgås krydssnak mellem forskellige udgaver også og udrulning burde kunne foregå i trin, frem for at kræve at alle kommer up-to-date mere eller mindre samtidig.
> 
> Proceduren ville så være (fra f.eks. stable=A unstable=B ny=C):
> 
> CollectionSettings til miljø C klargøres og komponenter sættes op der. Stable CollectionSettings peges på B (cp unstable/*.xml stable/), Unstable på C. Miljø A kan så lukkes eller udfases som nødvendigt.
> 
> ~ Michael
> 
> -----Original Message-----
> From: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] On Behalf Of Kim Teglgaard Christensen
> Sent: Tuesday, January 17, 2012 3:26 PM
> To: bitrepository-devel at ml.sbforge.org
> Subject: [Bitrepository-devel] Integrationsmiljø
> 
> Hej Folkens
> 
> Vi har jo (eller dvs, skal have) to integrations miljøer. Det stabile
> miljø og det som vi tester nye udgaver i. Når en ny udgave går hen og
> bliver stabil skal den gamle stable erstattes med den nye udgave og et
> nyt test miljø op. 
> 
> For at ikke at skulle rode for meget rundt i det miljø som skal blive
> det nye stable kunne det være en fordel at dets collection settings ikke
> ændres. Jeg vil derfor forslå at vi har to collection settings som har
> nogle neutrale navne, og blot ændre opfattelsen af hvad vi betragter som
> "stable" og "unstable" - lidt ala front/backbuffer i en driver. Hvad der
> er "stable" og "unstable" kunne passende styres af wikien hvor vi
> aligevel har et overblik over hvad der er i hvilken collections. 
> 
> De to miljøer kunne måske hede:
> integ1 (-> stable) 
> integ2 (-> unstable)
> 
> og når der så skal laves en rotation:
> integ2 (-> stable)
> integ1 (-> unstable)
> 
> Lyder det helt hen i hampen?
> 
> 
> Mvh Kim
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel
> 
> _______________________________________________
> Bitrepository-devel mailing list
> Bitrepository-devel at ml.sbforge.org
> http://ml.sbforge.org/mailman/listinfo/bitrepository-devel




More information about the Bitrepository-devel mailing list