Hoe ontwikkelen met grote database

[Avalaxy]

Stel dat je in productie een database hebt staan (SQL Server) van 100+ GB. Hoe ga je daarmee om in je ontwikkelproces? Normaal gesproken heb ik een setup waar ik een lokale SQL Server Express draai met een kopie van de database, maar dan gaat het om databases met enkele duizenden records. Tegen zo'n database kun je lekker experimenteren en klooien, en als het dan fout gaat knikker je de hele zooi weg en zet je een nieuwe kopie neer (wat dan een kloon is van je productiedatabase).

In het geval van een 100GB+ database is zo'n setup echter niet handig, vanwege diskruimte, beperkingen van SQL Server Express, overdrachtsnelheid van het netwerk, etc.

Eén manier om dat aan te pakken is door een kopie van de productiedatabase neer te zetten op een testserver, waar elke developer verbinding mee maakt. In die setup heeft de ontwikkelaar dus geen lokale database, en is hij afhankelijk van wat anderen met de centrale database doen.

De andere optie die ik kan bedenken is een subset van de productiedatabase op de lokale PC te zetten, maar de grote vraag is dan hoe je (zonder al teveel tijd te spenderen) makkelijk een subset van je hele database kunt pakken, te zorgen dat de referentiële integriteit nog in orde is en je applicatie niet stuk gaat omdat er belangrijke dingen missen.

Zitten hier ervaringsdeskundigen die een professionele oplossing hiervoor weten?

[frickY]

Meestal wil je je live data niet op je ontwikkelomgeving hebben. Zeker niet als dat persoonsgegevens zijn, maar bovenal heb je toch niet alles nodig. Het is niet dat je elke productvariatie gaat bekijken; je gebruikt meestal 1 test-set en als je klaar bent enkele willekeurige andere variaties.

Een goede set aan mock data is voldoende om tegen te ontwikkelen, en die kun je gewoon (random) genereren. Stress- en performancetests doe je met een grotere set die real-life benaderd, of liever nog een veelvoud is daarvan.

[Hydra]

Beiden. Je hebt normaliter in grote projecten een OTAP straat. Ontwikkel, Test, Acceptatie, Productie. Verschillende omgevingen die steeds meer productie-like worden.

[Avalaxy]

frickY schreef op donderdag 15 mei 2014 @ 00:05:
Een goede set aan mock data is voldoende om tegen te ontwikkelen, en die kun je gewoon (random) genereren.

Is alleen niet handig als je datamodel ook meeverandert. Tenzij je tools hebt die random data genereren, maar random gegenereerde data gaat in een hoop gevallen niet werken.

Hydra schreef op donderdag 15 mei 2014 @ 00:14:
Beiden. Je hebt normaliter in grote projecten een OTAP straat. Ontwikkel, Test, Acceptatie, Productie. Verschillende omgevingen die steeds meer productie-like worden.

OTAP is er, maar het is me niet duidelijk hoe jij de flow van het ontwikkel-gedeelte voor je ziet. In mijn optiek is de O de lokale machine van de developer, met een lokale database.

[NMe]

Avalaxy schreef op donderdag 15 mei 2014 @ 00:44:
[...]

Is alleen niet handig als je datamodel ook meeverandert. Tenzij je tools hebt die random data genereren, maar random gegenereerde data gaat in een hoop gevallen niet werken.

Hoe is dat precies anders wanneer je met de livedatabase werkt? Als je daarvoor je model aanpast moet je ook je data aanpassen, op dezelfde momenten waarop je dat met nepdata moet doen.

OTAP is er, maar het is me niet duidelijk hoe jij de flow van het ontwikkel-gedeelte voor je ziet. In mijn optiek is de O de lokale machine van de developer, met een lokale database.

Tijdens het ontwikkelen hoef je niet direct met een volledig opgeschaalde database aan de slag. Eerst kijken of het op kleine schaal werkt, daarna opschalen (met testdata) om te kijken of grote datasets ook geen probleem zijn. Direct tegen (een kopie van) een productiedatabase aan lullen tijdens het ontwikkelen is lang niet altijd even handig.

[Camulos]

Avalaxy schreef op donderdag 15 mei 2014 @ 00:44:
In mijn optiek is de O de lokale machine van de developer, met een lokale database.

Als het kan, dan prima.. maar vaak in omgevingen met grotere datasets is het normaal dat er een aparte OTAP-DB-Server. Dat betekend dat je met je lokale applicatie (O) een connectie maakt met de ontwikkel SQL-server (die vaak een subset van de ACP/PRD heeft).

In je eerste zin illustreer je het zelf best fraai:
.. (SQL Server) van 100+ GB. ... Normaal gesproken heb ik een setup waar ik een lokale SQL Server Express draai met een kopie van de database..

Met zulke datasets lijkt me het juist verstanding om een aparte SQL-server voor de verschillende OTAP-stadia te hebben... daarnaast heeft SQL Server Express een limiet van 10GB per database (naast andere limitaties)

[Zoijar]

Gewoon een mirror draaien ergens op een andere machine voor development. Wat is nou 100GB? Twee bluray films... Als we het nou over bv een PB hebben, dan moet je gaan denken hoe dat op te lossen. Dan zou ik een subset mirroren.

[P_Tingen]

Hoewel 100GB niet helemaal niks is, is het denk ik wel het gemakkelijkste. Hier hebben we wel een kopie van de productiedatabase staan als ontwikkeldatabase. Dat heeft als voordeel dat je gelijk op de performance moet letten van je programmatuur. Je moet dan wel een een server hebben inderdaad want dit soort spul wil je niet lokaal hebben staan. En werkt bovendien niet met een express versie. Je kunt op een of andere manier proberen een subset van data er uit te trekken maar dat kost je altijd meer tijd dan je van te voren denkt ivm integriteit van data. Schijfruimte is goedkoop dus ik zou opteren voor het kopieren van productie en het starten van een ontwikkel-database-server.

[Webgnome]

P_Tingen schreef op donderdag 15 mei 2014 @ 09:47:
Hoewel 100GB niet helemaal niks is, is het denk ik wel het gemakkelijkste. Hier hebben we wel een kopie van de productiedatabase staan als ontwikkeldatabase. Dat heeft als voordeel dat je gelijk op de performance moet letten van je programmatuur. Je moet dan wel een een server hebben inderdaad want dit soort spul wil je niet lokaal hebben staan. En werkt bovendien niet met een express versie. Je kunt op een of andere manier proberen een subset van data er uit te trekken maar dat kost je altijd meer tijd dan je van te voren denkt ivm integriteit van data. Schijfruimte is goedkoop dus ik zou opteren voor het kopieren van productie en het starten van een ontwikkel-database-server.

hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Lijkt mij allerminst een handige / verantwoorde keuze. Bij het ontwikkelen van een product maak je als eerste een data set die is zoals het zou moeten zijn en in verloop van tijd ga je dan die data set verijken met de mogelijke onvoorziene situaties die er zijn.

maar dat is mijn bescheiden mening.

[InZane]

Webgnome schreef op donderdag 15 mei 2014 @ 10:24:
[...]


hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Lijkt mij allerminst een handige / verantwoorde keuze. Bij het ontwikkelen van een product maak je als eerste een data set die is zoals het zou moeten zijn en in verloop van tijd ga je dan die data set verijken met de mogelijke onvoorziene situaties die er zijn.

maar dat is mijn bescheiden mening.

Ligt er natuurlijk wel aan over wat voor data je dan praat.

Ik maak vaak genoeg mee dat er gewoon een subset van productie wordt gepakt. Als er geen hele gevoelige data in zit hoeft dat imho geen probleem te zijn.

[NMe]

Webgnome schreef op donderdag 15 mei 2014 @ 10:24:
[...]

hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Dat is niet eens je grootste zorg. Wat nou als je applicatie bijvoorbeeld kan mailen naar mensen en je zit als ontwikkelaar te testen om er vervolgens achter te komen dat je de klanten van je klant hebt gespamd?

Het hangt natuurlijk van je werk af maar ikzelf heb sowieso toegang tot alle productieservers waar we mee werken omdat ik dat gewoon nodig heb om mijn werk te doen. Ik kan dus sowieso in die database en áls ik ooit ontslagen word is dat dus sowieso een risico waar mijn baas rekening mee moet houden. Ik zou natuurlijk nooit zoiets doen, maar domweg niet met live-data werken op de ontwikkelomgeving kwijt mijn baas nog niet meteen van zijn verantwoordelijkheid om te voorkomen dat ik met de data van klanten aan de haal kan gaan als hij me ooit zou willen ontslaan.

[elhopo]

In basis heb je alleen een kopie van produktie nodig als je een issue van productie moet reproduceren. Dan nog kan je (meestal) volstaan met het ophalen van een paar records. Afhankelijk van waar je werkt kan je de subset zelf ophalen of op laten halen. Bij het op laten halen kan de data bijvoorbeeld meteen anoniem worden gemaakt. Vaak is het ook zo dat de ontwikkelaar geen rechten heeft op een productie database.

Daar waar je gewoon aan nieuwe functionaliteit aan het werken bent is een kopie van productie niet nodig, en vaak niet eens wenselijk. Het is onhandig om even een scriptje te testen wat wat records in de database bij elkaar zoekt, waar je vervolgens een uur op moet wachten omdat er 10.000.000 records worden doorlopen.

Wat voor mij het beste werkt is een database op een lokale server of een database instantie per ontwikkelaar waar deze naar hartenlust in kan queryen. Als er wat stuk gaat is de database zo weggegooid of teruggezet. In een testomgeving wordt dan verder gekeken of alles klopt (daar staat een vaste set testdata waar al dan niet automatisch mee wordt getest). Persoonlijk zie ik geen toegevoegde waarde van een kopie productie per ontwikkelaar.

Als bedrijf moet je het denk ik ook niet willen. Zoveel data is geld waard, en je wilt niet dat het zo door je bedrijf slingert.

[BCC]

Met ^^ Als je lokaal om de een of andere reden wel veel of data nodig hebt, dan schrijf je een populate script die je database volgooit met nep data, die wel logisch gestructureerd is.

Daarnaast is het volgens de richtlijnen van het CPB vaak ook niet eens toegestaan om productie data op je laptop te hebben.

Maar ik vind het best wel eng hoeveel ontwikkelaar "gewoon" een kopie van productie op hun laptop hebben staan (die vaak dan ook niet eens ge-encrypt is). Als ontwikkelaars het al niet belangrijk vinden, waarom kijken we dan nog op van al die datalekken die steeds in het nieuws komen? ?

En als jij als ontwikkelaar wel te vertrouwen bent met die data, doe dan voor de grap op het volgende congres dat je bezoekt eens een port scan naar alle machine met database servers met een standaard wachtwoord

[ Voor 54% gewijzigd door BCC op 15-05-2014 11:28 ]

[Acid_Burn]

Wij werken hier wel met productiedata van de klant voor een groot pakket van ons. Simpelweg omdat die omgeving ultra configurabel is. De datastructuur is heel dynamisch. Daar populatiescripts voor schrijven is schier onmogelijk.

Die data staat alleen bij ons op het netwerk. Eigen laptops aansluiten (of zelfs meebrengen) is niet toegestaan.

[Gomez12]

elhopo schreef op donderdag 15 mei 2014 @ 11:11:
In basis heb je alleen een kopie van produktie nodig als je een issue van productie moet reproduceren. Dan nog kan je (meestal) volstaan met het ophalen van een paar records. Afhankelijk van waar je werkt kan je de subset zelf ophalen of op laten halen. Bij het op laten halen kan de data bijvoorbeeld meteen anoniem worden gemaakt. Vaak is het ook zo dat de ontwikkelaar geen rechten heeft op een productie database.

Het nadeel van subsets vind ik altijd dat het al heel erg snel heel erg complex wordt wat er exact in die subset moet komen.

Standaard werken wij met productie data die automatisch gesynced wordt en dan in de sync zitten er wat obfuscation scripts zodat bijv alle emailadressen gaan van *@* naar *test@test*.test.
En de naw tabellen die gaan simpelweg door een randomgenerator net zoals dat alle user-pw's gereset worden.

Het voordeel van deze aanpak vinden wij dat 99,99% van de test-data productie data is, dus alles wat de gebruiker kan tegenkomen kunnen wij naspelen zonder allerlei trucs uit te moeten halen zoals subsets over moeten halen.

Subsets vind ik altijd leuk bij iets wat 10 tabellen oid heeft, op het moment dat ik >200 tabellen met foreign keys etc heb dan wil ik echt geen subsets meer hanteren, dat systeem voor het aanmaken van de subsets gaat dan al extreem veel beheer vragen.

[BCC]

Met een subset wordt een subset van data bedoeld, niet van structuur. En dat het veel werk is om iets goed te doen is natuurlijk geen argument dan zou je nl ook niets aan security hoeven doen

[elhopo]

Gomez12 schreef op donderdag 15 mei 2014 @ 11:56:
[...]

Het nadeel van subsets vind ik altijd dat het al heel erg snel heel erg complex wordt wat er exact in die subset moet komen.

Standaard werken wij met productie data die automatisch gesynced wordt en dan in de sync zitten er wat obfuscation scripts zodat bijv alle emailadressen gaan van *@* naar *test@test*.test.
En de naw tabellen die gaan simpelweg door een randomgenerator net zoals dat alle user-pw's gereset worden.

Het voordeel van deze aanpak vinden wij dat 99,99% van de test-data productie data is, dus alles wat de gebruiker kan tegenkomen kunnen wij naspelen zonder allerlei trucs uit te moeten halen zoals subsets over moeten halen.

Subsets vind ik altijd leuk bij iets wat 10 tabellen oid heeft, op het moment dat ik >200 tabellen met foreign keys etc heb dan wil ik echt geen subsets meer hanteren, dat systeem voor het aanmaken van de subsets gaat dan al extreem veel beheer vragen.

Het is maar net wat je aan het ontwikkelen bent. Als ik nieuwe functionaliteit moet ontwikkelen dan wil ik specifiek dat scenario testen. Ik heb dan geen behoefte aan productiedata. Sterker nog, misschien zit me dat in de weg, en is een lege database handiger. Als je in de onderhoudteams zit (kan een aparte club zijn), dan wil je bugfixen en dan heb je soms productie data nodig. Je wil dan de situatie van dat moment hebben, want de fout is net opgetreden. Het is imo dan niet praktisch ter plekke een kopie van productie te maken, omdat dit teveel impact heeft op de systemen (vertraging etc). Het is dan dus sneller om alleen het specifieke geval eruit te halen en dat te testen. Impact van de kopie is lager, responstijd is sneller en de tijd om te fixen is dan dus ook korter. Ik zie een business case.

Wat BCC zegt: Omdat iets lastig is, is het nog niet een excuus om het niet te doen. Daarnaast heb je tegenwoordig tools zoals Apache Cayenne die een compleet model van je database uitspuugt, waarmee je dit relatief eenvoudig kan realiseren.

Het kan, ook in complexe systemen van vele tabellen. Het probleem is vaak wat dieper. Veel ontwikkelaars denken dat ze overal bij moeten kunnen en alles mogen aanpassen. Als je een tijdje in grote complexe omgevingen hebt gewerkt, zoals de bancaire sector ben je blij dat je dat niet kan en mag, het is vaak al lastig genoeg om je eigen zaken te regelen, laat de anderen maar het beheer doen.

[Munnikman]

Even een korte praktische suggestie waarbij ik voorbij ga aan de juridische punten (privacy / data veiligheid / etc) en de puristische discussie over het gebruik van een OTAP oplossing..... Gebruik SSIS om je datamodel over te zetten naar de door jou gewenste instance en gebruik een foreach container om van elke tabel 1000 records over te zetten. Volgens mij heb je dan voldoende data om te kunnen werken (aanname, ik ken jullie datamodel niet) en kan je beginnen met ontwikkelen.

Suc6!

[Zebby]

Als performance een issue is kun je misschien de statistics laden op een ontwikkelomgeving zodat je kan afleiden welk pad je queries zullen nemen.

[Dekaasboer]

Jup, je wil nooit een kopie van een productiedatabase op je laptop hebben staan. Stel je voor dat het ding gehackt of gejat word. Dan ben je mooi de sjaak.

Voor een bedrijf zal een ontwikkelserver niet zo'n probleem zijn. De mogelijkheden zijn legio aangezien het vaak allemaal niet zo redunant uitgevoerd hoeft te worden. Een simpele stand alone server, een kleine VM of zelfs een azure omgeving. Je kan de boel up to date houden met overzetten van backups.

Ik weet niet wat voor werkzaamheden er op gebeuren maar ik heb zelf nog nooit last gehad van andere ontwikkelaars. Als dat echt een probleem is kan je de database natuurlijk meerdere keren online brengen desnoods is seperate instances.

[Kwistnix]

Ik gebruik zelf als het even kan Liquibase voor database versioning. Echt ideaal. Afgezien van referentiegegevens gebruik ik dan een ander mechanisme om de database van vulling te voorzien, wanneer dat nodig is. Dat kan van alles zijn. Gewoon SQL scriptjes of geanonimiseerde dumps van de acceptatieomgeving (of prodcutie) etc.

Het liefst werk ik ook met hetzelfde RDBMS dat in productie draait, behalve voor unit testing dan pak ik meestal een in-memory oplossing als H2 of HSQLDB. Een productie-like RDBMS draai ik dan gevirtualiseerd. Op dit moment bijvoorbeeld Oracle in CentOS via VirtualBox.

[ Voor 29% gewijzigd door Kwistnix op 15-05-2014 14:51 ]

[SharpY]

Mijn inziens worden er te ingewikkelde opties voorgesteld hierboven. Wij werken met een db van +- 200gb productie, echter is de lokale ontwikkelomgeving van de ontwikkelaars alleen qua architectuur gelijk. De DB wordt via een template leeg ingeladen en data kan vanaf test worden gekopieerd . Testdata is afkomstig van productie waarover een "anonimiseringscript" is gedraaid. naam , adres, telefoonnummer email, etc.etc. is geanonimiseerd naar [Veldnaam] + [UserID] zodat het testen ook nog wat makkelijker wordt echter voor niet persoonsgebonden data wel realistische gegevens aanwezig zijn.

Sowieso is de lokale ontwikkelomgeving absoluut geen vergelijkbare omgeving om 100gb aan data in de database in te hebben staan,omdat de hele omgeving niet eens een beetje lijkt op wat er normaal op een productie of acceptatie omgeving draait.

[sig69]

Wij draaien hier ook gewoon kopien van productie databases op de development server. Niet helemaal netjes, maar voor nu de makkelijkste oplossing. En als je tegen de limieten van Sql Express aanloopt: daar is Sql Server Developer Edition voor, kost 60 dollar ofzo

[SharpY]

sig69 schreef op donderdag 15 mei 2014 @ 20:50:
Wij draaien hier ook gewoon kopien van productie databases op de development server. Niet helemaal netjes, maar voor nu de makkelijkste oplossing. En als je tegen de limieten van Sql Express aanloopt: daar is Sql Server Developer Edition voor, kost 60 dollar ofzo

Zonder persoonlijke gegevens of gewoon 1:1?

[sig69]

Gewoon 1:1, vandaar " Niet helemaal netjes, maar voor nu de makkelijkste oplossing".

[SharpY]

Ah, ik zou toch even die 10 minuten spenderen om een simpel scripje te maken, je weet het maar nooit

[sig69]

Ach er staat niet echt gevoelige data in. En daarnaast, elke developer is ook "support medewerker" en kan ook op productie inloggen dus als je echt kwaad wil kan dat toch wel.

[Kevinp]

Webgnome schreef op donderdag 15 mei 2014 @ 10:24:
[...]


hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Lijkt mij allerminst een handige / verantwoorde keuze. Bij het ontwikkelen van een product maak je als eerste een data set die is zoals het zou moeten zijn en in verloop van tijd ga je dan die data set verijken met de mogelijke onvoorziene situaties die er zijn.

maar dat is mijn bescheiden mening.

Want die ontwikkelaar heeft geen toegang tot de productie omgeving?

Vele van die methode zijn goed bedoeld, maar uiteindelijk leveren ze schijnveiligheid

Als de data extern wordt weg gezet heb je een punt, maar anders zie ik het probleem niet zo.

[markvt]

Misschien is dit wat: met red-gate "sql data generator" om test data aan te maken?

http://www.red-gate.com/p...pment/sql-data-generator/

Hoef je alleen een model te laden in je database en er data in te mikken.

Met SQL Compare kan je je model synchen tussen databases.

[The Eagle]

Ik werk dagelijks met ERP in enterprise omgevingen, en 100GB is redelijk normaal te noemen.
Ben beheerder, consultant en ook devver als het moet dus kan me van beide kanten inleven. Compliancy is meestal leading in welke opties er zijn.
Wat ik zelf veel zie is dat in DEV productiedata niet toegestaan wordt. Echter op T en A is het niet abnormaal om met productiedata te mogen werken.
Alternatief is vaak het scramblen van data, oftewel het door elkaar gooien van data (bijv stamgegevens van vendors) danwel depersonificatie van personeelsdata.
Qua kosten maakt het iig weinig uit of je nou een 20GB DB op Dev of test hebt staan, of 100GB.

Overigens kan ik voor sommige systemen ook alleen de applicatielogica overzetten vanuit productie. Dan hoef je niet eens aan je normale data te komen
Having said that: bij Oracle kun je online een DB dupliceren naar een andere DB. Kost initieel wat tijd, maar daarna veel minder omdat alleen de verschillen maar nodig zijn. Heb erop ze zaak eentje van 175GB draaien waarvan de refresh in een klein uurtje klaar is. En das een simpele dual Xeon uit 2010 met 24GB ram waar het zaakje op draait

Verder zie ik vaak versioning tools gebruiken, die ook automatisch kunnen migreren, objecten kunnen locken en backups kunnen maken van de targetomgeving voor iets overgezet wordt. Kijk maar eens naar Quest STAT of naar CAPI. Leuk spul.

@TS: wees jezelf er van bewust dat 100GB+ DB's veel voorkomen in grote omgevingen. Daar is geld voor opslagcapaciteit veel minder een issue. Als het moet (bijv door compliancy) dan is het gewoon nodig en dan komt het er.

[Boogie]

100GB is niet groot, maar inderdaad te groot voor SQL express.
ik beheer 10+ databases van ~1.2TB voor ontwikkelen, testen, opleiden, accepteren en allerhande projecten.
Wel een script om een omgeving/testset te verkleinen; per omgeving is een verversingsfrequentie waarbij gewoon de backup gerestored wordt; dat duurt 1,5 uur of zo en gebeurt 's nachts. Maar omdat een database file shrinken extreem intensief is en heel lang duurt doen we dat niet; de file weer vergroten bij de voglende restore kost ook heel veel tijd en de ruimtewinst is beperkt.

Je zou ook kunnen denken aan snapshots op een storage omgeving; die kan je eenvoudig veversen en nemen alleen de 'delta' aan ruimte in.

Bij het ontwikkelen moet je gewoon voorzichtig zijn en tabellen die je gaat 'verneuken' even kopieren zodat je die eenvoudig terug kan zetten zonder dat je heel de database hoeft te verversen.

[ Voor 12% gewijzigd door Boogie op 15-05-2014 22:22 ]

[Gomez12]

The Eagle schreef op donderdag 15 mei 2014 @ 21:27:
Wat ik zelf veel zie is dat in DEV productiedata niet toegestaan wordt. Echter op T en A is het niet abnormaal om met productiedata te mogen werken.

T maar zeker A lijkt me eigenlijk bijna onmogelijk om zonder productiedata goed te krijgen. Of je moet echt dedicated testers / accepters hebben die daar echt doorheen kunnen kijken. Maar mijn ervaring qua A is dat dat (over het algemeen) gewoon een paar key-users zijn die vertrouwd zijn met hun data en extreem slecht kunnen testen / accepten zonder dat ze hun data zien, die willen gewoon zien dat wat er in productie gebeurt ook in T/A niet stuk gaat.

Zo hebben wij laatst een stkje google-maps integratie gemaakt en dat kwam niet door de 1e acceptatie omdat de mensen zeiden : klant x zit niet in Alaska. Het randomizer script haalde gewoon random (maar wel kloppende) naw gegevens ergens vandaan en daar konden de Accepters dus niet doorheen kijken want die hadden zoiets van : klant x zit op locatie y dus locatie y moet getoond worden (en naw mutaties doet een andere afdeling dus normaliter hadden ze daar geen zicht op)

Toen mochten we dus ook even de naw-randomizer uit de synch halen want anders kwam er geen acceptatie.

[jip_86]

Acid_Burn schreef op donderdag 15 mei 2014 @ 11:32:
Wij werken hier wel met productiedata van de klant voor een groot pakket van ons. Simpelweg omdat die omgeving ultra configurabel is. De datastructuur is heel dynamisch. Daar populatiescripts voor schrijven is schier onmogelijk.

Die data staat alleen bij ons op het netwerk. Eigen laptops aansluiten (of zelfs meebrengen) is niet toegestaan.

Hier ook centrale databases met productiedata in het netwerk die gescrambled zijn. De sofware is namelijk nauwelijks iets waard zonder een realistische inrichting. Er zijn ernstig verminkte omgevingen die veel voor ontwikkelen gebruikt worden, maar ook die zo intact mogelijk gelaten worden om ook rechten van bepaalde rollen zoals de klant ook werkt goed mee te kunnen nemen bij een test.

[BikkelZ]

Zijn er geen paraplu's te bedenken waaronder je een realistische set aan data kunt hangen? Bijvoorbeeld de actieve klanten van de afgelopen maand? Of de drie grootste klanten? Met een systeem waarbij je makkelijk een extra klant of periode naar binnen kunt lepelen als er een specifiek probleem optreedt?

Vaak wordt maar 10% data in een database intens gebruikt en de rest is naslag.

[decipherer]

Ik vind het toch ongelooflijk om te zien hoe vaak er nog met productie data op een ontwikkel omgeving (of tst,acc) getest word. Daar valt bij ons dus echt _niet_ over te praten. De ontwikkel en dev omgevingen worden daar gevuld door testen van ontwikkelaars. Er is een interne test omgeving die voornamelijk gevuld wordt door testen van onze testers. Er zijn vervolgens test omgevingen die van buitenaf benaderbaar zijn en waar interne en externe gebruikers kunnen testen, het is hier niet toegestaan productie data te gebruiken.
Door de vele handmatige en geautomatiseerde testen hebben we op onze ota omgeving een redelijke vulling opgebouwd.

[ACM]

decipherer schreef op zaterdag 17 mei 2014 @ 07:35:
Ik vind het toch ongelooflijk om te zien hoe vaak er nog met productie data op een ontwikkel omgeving (of tst,acc) getest word.

En waarom vind je dat? Er worden hier ook argumenten aangehaald waarom het wel zinvol is.

De nadelen zijn volgens mij:
- Extra plek om (privacy)gevoelige gegevens te kunnen lekken.
- Grootte van database kan opzetten van ontwikkel- en testomgevingen lastiger maken en tests langer laten duren dan nodig.
- Bestaande data kan een wijziging 'in de weg' zitten.

De voordelen:
- Meest reeele representatie van de productiedata.
- Geen (ingewikkelde?) procedure nodig om een testomgeving met data te vullen, die zelf ook weer onderhoud nodig heeft.
- Minder risico dat bepaalde wijzigingen niet met 'perfecte' testdata mis gaan, maar uiteindelijk wel met productiedata.
- Minder kans dat je door de te kleine database een query opzet die met productiedata significant anders wordt uitgevoerd.

Mis ik er nog wat?

De zwaarte van het punt over de gevoeligheid van de data hangt natuurlijk volledig af van de data... In het geval van Tweakers is het overgrote deel van die data toch al in meer of mindere mate letterlijk publiek toegankelijk en is het aandeel persoonsgegevens zeer beperkt. Als je met bijvoorbeeld bancaire of medische gegevens werkt heb je natuurlijk met veel strengere veiligheidseisen te maken.

De grootte van de data blijft natuurlijk altijd een sta-in-de-weg (daar ging dit topic tenslotte over), maar ik vind dat bij ons zelf tegen de nadelen opwegen.

Bij ons zijn dezelfde mensen verantwoordelijk voor zowel het oplossen van bugs als het uitwerken van nieuwe functionaliteit. De nieuwe functionaliteit is in de praktijk bovendien meestal een evolutionaire vernieuwing van bestaande functionaliteit, waardoor ontwerpen e.a. meestal ook op basis van bestaande functionaliteit worden ontwikkeld.

In beide gevallen is het een stuk praktischer om dan ook daadwerkelijk met productiedata verder te kunnen bouwen. Maar wij zitten dan natuurlijk ook heel sterk in de 'de data is het product'-hoek, dat geldt natuurlijk niet voor iedereen
En bijkomende voordelen zijn dan nog dat je gelijk een goed beeld krijgt van wat je wijzigingen aan productiedata aan tijd kosten en of queries inderdaad nog gebruik maken van de juiste indices.

[Verwijderd]

Juist bij database ontwikkeling lijkt het me verstandig met een actuele productie-database te werken. Bijv. voor performance vraagstukken (wat ACM ook al aangeeft).

Ik werk zelf ook met redelijk grote databases (van ERP pakket). Bijna alle klanten hebben een machine met daarop de productie-omgeving, en een omgeving met de rest van de OTAP straat. Werkt prima. Als het moet hebben we in een half uur een verse kloon. Er zijn wel klanten die denken te kunnen besparen op hun OTAP straat. Maar ze zijn zich dan weer niet bewust van de risico's..

Wat betreft de gevoelige data; meestal teken je voor geheimhouding toch? Ik denk niet dat je het helemaal dicht kan timmeren. Anders is het altijd nog mogelijk om gegevens te 'verminken', bijvoorbeeld HR info. Emailadressen worden bij ons ook altijd standaard 'verminkt' om niet het risico te lopen klanten te mailen vanuit een niet productie-omgeving.

[Sircuri]

Het grootste nadeel wat hier niet genoemd wordt is: Het ontwikkelen met een productiedatabase geeft naar mijn mening duidelijk aan dat er niet op een gestructureerde manier ontwikkeld en getest wordt. Als je een stuk moet ontwikkelen dan heb je enkel representatieve test data nodig van dat deel dat je aan het ontwikkelen bent. Heb je data uit andere modules nodig om je huidige stuk code te laten werken, zul je het moeten mocken/stubben.

Performance vraagstukken kun je aanpakken met random gegenereerde data. Waarom moet je productie data hebben? Je kan prima 1 record uit productie nemen bijvoorbeeld en deze 100.000x laten clonen in de database. Je zou ook gewoon zelf test data kunnen maken en die dupliceren in een database.

Ik heb hierboven dus nog geen argumenten gezien waarom dat persee een productie database van een klant moet zijn. Alles is te genereren met random data of goed uitgedachte test-data.

Mocht je uiteindelijk echt een productie probleem tegenkomen die niet op te lossen is d.m.v. standaard logging e.d., kan ik me indenken dat je uiteindelijk overweegt om een kopie te trekken van de klant. Mocht het zover komen is het tevens het juiste moment om te bekijken waar logging/audit/feedback beter moet om dit probleem niet nogmaals te hebben.

[jip_86]

Sircuri schreef op zaterdag 17 mei 2014 @ 11:44:
Het grootste nadeel wat hier niet genoemd wordt is: Het ontwikkelen met een productiedatabase geeft naar mijn mening duidelijk aan dat er niet op een gestructureerde manier ontwikkeld en getest wordt. Als je een stuk moet ontwikkelen dan heb je enkel representatieve test data nodig van dat deel dat je aan het ontwikkelen bent. Heb je data uit andere modules nodig om je huidige stuk code te laten werken, zul je het moeten mocken/stubben.

Performance vraagstukken kun je aanpakken met random gegenereerde data. Waarom moet je productie data hebben? Je kan prima 1 record uit productie nemen bijvoorbeeld en deze 100.000x laten clonen in de database. Je zou ook gewoon zelf test data kunnen maken en die dupliceren in een database.

Ik heb hierboven dus nog geen argumenten gezien waarom dat persee een productie database van een klant moet zijn. Alles is te genereren met random data of goed uitgedachte test-data.

Mocht je uiteindelijk echt een productie probleem tegenkomen die niet op te lossen is d.m.v. standaard logging e.d., kan ik me indenken dat je uiteindelijk overweegt om een kopie te trekken van de klant. Mocht het zover komen is het tevens het juiste moment om te bekijken waar logging/audit/feedback beter moet om dit probleem niet nogmaals te hebben.

Ik geloof nooit dat je voor een pakket met tientallen modules een realistische testset in elkaar kan zetten zonder dat je tegen fouten aan gaat lopen omdat je gewoonweg rommel de database hebt gecloned. Dan ben je eerst bezig met mocken vullen etc, en vervolgens nog debugtijd om achter te komen dat je zelf voor verkeerde vulling gekozen hebt.

Daarnaast met een ultra configurabele omgeving heb je gewoon bruikbare scenario's nodig zo als een klant ze ook gebruikt. Nog maar afgezien van de tijd die je kan besparen als je die kopie van de klant al hebt in je testomgeving.

[ACM]

Sircuri schreef op zaterdag 17 mei 2014 @ 11:44:
Het ontwikkelen met een productiedatabase geeft naar mijn mening duidelijk aan dat er niet op een gestructureerde manier ontwikkeld en getest wordt.

Of geïsoleerd ontwikkelen en testen onderdeel is van gestructureerd werken is weer een hele andere discussie Maar belangrijker is dat je dat niet 'even' verandert.

Als je een stuk moet ontwikkelen dan heb je enkel representatieve test data nodig van dat deel dat je aan het ontwikkelen bent. Heb je data uit andere modules nodig om je huidige stuk code te laten werken, zul je het moeten mocken/stubben.

Dan ga je ervanuit dat je taken of wijzigingen altijd maar zeer beperkte scope hebben, dat je het je kan veroorloven om altijd maar mocks/stubs te maken en dat je niet tijdens het ontwikkelen al een goede simulatie van de eindsituatie wilt bekijken.
Als je dat laatste pas kan nadat e.e.a. naar de test- of acceptatieomgeving is gepushed kost dat over het algemeen weer extra tijd.

Voorbeeldje uit mijn praktijk; optimaliseren van zoekresultaten op basis van de populairste zoekopdrachten. Dat is zodanig data-specfiek, dat je domweg je tijd zit te verspillen om uberhaupt randomized data te genereren. Sterker nog, ook werken met een deelverzameling van de normale corpus verandert al de resultaten.

Performance vraagstukken kun je aanpakken met random gegenereerde data. Waarom moet je productie data hebben? Je kan prima 1 record uit productie nemen bijvoorbeeld en deze 100.000x laten clonen in de database. Je zou ook gewoon zelf test data kunnen maken en die dupliceren in een database.

Nee dat kan je niet. Met random data en met een records dupliceren introduceer je wel veel records, maar niet met een voor jouw praktijk reeële verdeling. Juist de afwijkingen van de norm en clustering rond non-random datapunten leveren de meeste problemen op, niet de statistisch verantwoorde middengroep die je (met name) zou produceren met randomized data. En omdat je van te voren niet weet waar pijnpunten zitten (anders waren het geen pijnpunten meer), kan je ook niet met 'slim data genereren' de boel altijd goed reproduceerbaar maken.
Uiteraard is de kans dat je die pijnpunten daadwerkelijk tijdens het testen tegen komt ook al niet enorm groot, maar als je dan bij het oplossen van zo'n performanceissue ook nog eens wilt gaan proberen om de data zelf te reproduceren (tenzij dat natuurlijk nodig is om het probleem te achterhalen) zit je volgens mij het jezelf onnodig moeilijk te maken

Om maar wat performanceproblemen te noemen die we op Tweakers gezien hebben en waar random data waarschijnlijk geen vergelijkbare situatie voor had opgeleverd:
- Paginering van forumtopics met 50k-100k reacties (het gemiddelde is 13)
- Statistieken vertonen bij gebruikers met 50k-100k reacties

Ik heb hierboven dus nog geen argumenten gezien waarom dat persee een productie database van een klant moet zijn. Alles is te genereren met random data of goed uitgedachte test-data.

Op het moment dat het over productiedata van klanten gaat ben ik met je eens dat je moet proberen te vermijden dat je daarvan afhankelijk bent voor je ontwikkeling.
Maar als het om een eigen database gaat met eigen ontwikkelaars, kan je over het algemeen alweer een stuk beter veroorloven dat je altijd een kopie van de (belangrijkste) productiedata voorhanden hebt.

[Gamebuster]

Webgnome schreef op donderdag 15 mei 2014 @ 10:24:
[...]
hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Tot nu toe heb ik op mijn werk altijd gewerkt met kopieën van productie data. Nu werk ik met kleine sets aan testdata, maar ik ben wel benieuwd hoe ik het straks ga doen, wanneer ik wat "complexere" data wil.

Data genereren o.b.v. productie data, maar dan geanonimiseerd?

[pasz]

100GB is niet niks. Heb je er veel BLOBs inzitten ?

[P_Tingen]

Wij werken eigenlijk ook altijd met kopieen van productie. Als we zelf een database zouden moeten vullen met nepdata zijn we wel even bezig; ons pakket beslaat ruim 2500 tabellen, dat ga je niet eventjes vullen. We hebben een geautomatiseerde procedure die kwetsbare data uit productie, zoals netwerkpaden naar interfaces en dergelijke vervangt door de locatie van de test of ontwikkelinterface.

Als extra beveiling wordt bij automatisch verstuurde mail vanuit ontwikkel- en testomgeving onderaan de mail een signature ingevoegd die de oorsprong van de mail aangeeft. De programmatuur herkent zelf aan de naam van de geconnecte database in welke omgeving hij draait.

De data die wij hebben is van een productiebedrijf. Daar zit geen privacygevoelige informatie in. Wel info die mogelijk voor een concurrent belangrijk kan zijn, maar ontwikkelaars zijn handig genoeg om aan die informatie te komen als ze dat zouden willen, daar hebben ze de kopie van productie niet voor nodig. Bovendien hebben alle ontwikkelaars een geheimhoudingsverklaring getekend. Data doorspelen is gewoon strafbaar en wat ik bij ons zie is dat iets waar in ieder geval de ontwikkelaars bij ons helemaal niet mee bezig zijn.

Wat ik vooral handig vind is dat we juist de data uit productie hebben. Ons pakket is al oud en sommige data is crappy. Het is handig om dat direct bij het ontwikkelen al te zien. Bovendien draaien queries op een nagenoeg lege database ALTIJD snel. Door productiedata te gebruiken vallen verkeerde queries of indexen gelijk op.

[Sircuri]

ACM schreef op zaterdag 17 mei 2014 @ 12:43:
Of geïsoleerd ontwikkelen en testen onderdeel is van gestructureerd werken is weer een hele andere discussie Maar belangrijker is dat je dat niet 'even' verandert.

Klopt, dat ga je ook zeker niet even aanpassen. Mijn ervaring is dat dit al vanaf het begin van het project erin moeten zitten, tenzij je tijd over hebt om dit te veranderen.

Dan ga je ervanuit dat je taken of wijzigingen altijd maar zeer beperkte scope hebben, dat je het je kan veroorloven om altijd maar mocks/stubs te maken en dat je niet tijdens het ontwikkelen al een goede simulatie van de eindsituatie wilt bekijken.
Als je dat laatste pas kan nadat e.e.a. naar de test- of acceptatieomgeving is gepushed kost dat over het algemeen weer extra tijd.

Voorbeeldje uit mijn praktijk; optimaliseren van zoekresultaten op basis van de populairste zoekopdrachten. Dat is zodanig data-specfiek, dat je domweg je tijd zit te verspillen om uberhaupt randomized data te genereren. Sterker nog, ook werken met een deelverzameling van de normale corpus verandert al de resultaten.

Ik moet je absoluut gelijk geven dat er zeker situaties zijn waarin het genereren van test-data je meer tijd kost dan het oplevert.

Wat betreft de scope van de wijzigingen ben ik nog altijd van mening dat elke wijziging in de code is terug te brengen tot een enkel atomic change. En inderdaad zal het soms tijd kosten om een mock/stub data set te creëren waarmee je de betreffende change kan ontwikkelen/ testen. Via integratie tests zal de totale integratie getest worden tussen de verschillende modules. Dus ja, als er wijzigingen zijn over een brede scope, kun je het nog altijd via unit-tests testen en via een integratie test controleren of onderlinge modules nog steeds correct werken.
Ik moet hierbij wel aantekenen dat ik de luxe heb om deze tijd te gebruiken die nodig is voor het maken van test-data set / stubs. Daarnaast kan ik ook verantwoorden dat deze tijd nuttig is en geen weggegooid geld is. Het werk dat in mijn team opgeleverd wordt, duurt dan wel langer om te ontwikkelen, maar het aantal fouten in de code is drastisch veel lager dan wat ik in het verleden heb gezien bij vorige werkgevers en ook voordat we begonnen met deze methodiek.

Nee dat kan je niet. Met random data en met een records dupliceren introduceer je wel veel records, maar niet met een voor jouw praktijk reeële verdeling. Juist de afwijkingen van de norm en clustering rond non-random datapunten leveren de meeste problemen op, niet de statistisch verantwoorde middengroep die je (met name) zou produceren met randomized data. En omdat je van te voren niet weet waar pijnpunten zitten (anders waren het geen pijnpunten meer), kan je ook niet met 'slim data genereren' de boel altijd goed reproduceerbaar maken.
Uiteraard is de kans dat je die pijnpunten daadwerkelijk tijdens het testen tegen komt ook al niet enorm groot, maar als je dan bij het oplossen van zo'n performanceissue ook nog eens wilt gaan proberen om de data zelf te reproduceren (tenzij dat natuurlijk nodig is om het probleem te achterhalen) zit je volgens mij het jezelf onnodig moeilijk te maken

Om maar wat performanceproblemen te noemen die we op Tweakers gezien hebben en waar random data waarschijnlijk geen vergelijkbare situatie voor had opgeleverd:
- Paginering van forumtopics met 50k-100k reacties (het gemiddelde is 13)
- Statistieken vertonen bij gebruikers met 50k-100k reacties

Ik moet je denk ik wel gelijk geven in dit. Wat er echter blijft knagen is het feit dat je naar mijn idee nooit kan garanderen dat op basis van je tests, de juiste resultaten naar voren komen. Naar mijn idee kun je nooit iets goed testen als van te voren niet vast staat wat het test-resultaat gaat zijn. Het gewenste test resultaat kan toch alleen ontstaan als je ook weet wat je er in stop aan input? Daarom vind ik dit heel moeilijk te accepteren. Je hebt valide punten, maar het druist in tegen mijn gevoel van testbaarheid.

[ACM]

Sircuri schreef op zaterdag 17 mei 2014 @ 20:20:
Ik moet je denk ik wel gelijk geven in dit. Wat er echter blijft knagen is het feit dat je naar mijn idee nooit kan garanderen dat op basis van je tests, de juiste resultaten naar voren komen. Naar mijn idee kun je nooit iets goed testen als van te voren niet vast staat wat het test-resultaat gaat zijn. Het gewenste test resultaat kan toch alleen ontstaan als je ook weet wat je er in stop aan input? Daarom vind ik dit heel moeilijk te accepteren. Je hebt valide punten, maar het druist in tegen mijn gevoel van testbaarheid.

Het is zeker nodig om te weten wat er in gaat. Maar vergeet niet dat het overgrote deel van die testdata (iig mijn voorbeelden) niet veranderen van het ene op het andere moment. Het is daarmee niet zomaar geschikt voor unit-testing, maar wel voor al het handmatige testen dat daar 'boven' zit.

Je had er 'ooit' geen controle over, maar sinds het in een testomgeving is gezet, waar gebruikers de boel niet meer kunnen aanpassen, is het natuurlijk een stuk minder onzeker geworden
Sterker nog, je kan na een aantal wijzigingen dezelfde datadump van je productieomgeving opnieuw terugzetten mocht je daar behoefte aan hebben.

Afgezien daarvan blijft het allemaal situatieafhankelijk.

[BiBi]

Reden dat je vanuit de business niet wil dat er productiedata op je OT omgevingen komt is 'onzerkerheid'.

Niet iedereen is even goed te vertrouwen en leg het maar eens uit wanneer via de OT omgevingen kostbare gegevens op straat komen te liggen.

@TS: Waarom richt je niet een dataserver in je ontwikelomgeving in. Zo moeilijk kan het toch niet zijn om deze te vullen met testdata.

[Tarkin]

Wij hebben hiervoor scripts ontwikkeld. Zodat we enkele files per keer kunnen downloaden van een productieserver.

Ook hebben we iets wat proxycheck files heet. Dummy files die we lokaal zoveel kunnen opladen als we willen

[Guillome]

Webgnome schreef op donderdag 15 mei 2014 @ 10:24:
[...]


hoewel het het makkelijkste is om een kopie te maken van productie omgeving is dat natuurlijk nooit , never, nada een optie. Je gaat geen data uit productie overzetten naar ontwikkel omdat je dan een goede data set hebt. Wat als een medewerker met die data aan de haal gaat na ontslag omdat het in ontwikkel stond?

Lijkt mij allerminst een handige / verantwoorde keuze. Bij het ontwikkelen van een product maak je als eerste een data set die is zoals het zou moeten zijn en in verloop van tijd ga je dan die data set verijken met de mogelijke onvoorziene situaties die er zijn.

maar dat is mijn bescheiden mening.

Bij mijn vorige werk werden namen en andere persoonlijke gegevens veranderd bij het maken van een kopie naar de dev-omgeving. Is een goede optie.

Overigens zou je op de dev ook wel MS SQL manager nodig hebben. Daar kan je veel beter SQL in debuggen en optimaliseren

[P.O. Box]

P_Tingen schreef op zaterdag 17 mei 2014 @ 17:08:

Als extra beveiling wordt bij automatisch verstuurde mail vanuit ontwikkel- en testomgeving onderaan de mail een signature ingevoegd die de oorsprong van de mail aangeeft. De programmatuur herkent zelf aan de naam van de geconnecte database in welke omgeving hij draait.

vind dat niet echt een extra beveiliging.... wij hebben een laagje tussen onze applicatie en de e-mailfunctionaliteit gezet... dit laagje controleert in welke omgeving de code zich bevind... indien het een test of ontwikkelomgeving is zullen alleen mails aan een bepaalde subset van e-mailadressen worden doorgelaten (en die subset bevat eigenlijk alleen de mailadressen van de ontwikkelaars)...

[Gomez12]

P.O. Box schreef op maandag 26 mei 2014 @ 16:00:
[...]


vind dat niet echt een extra beveiliging.... wij hebben een laagje tussen onze applicatie en de e-mailfunctionaliteit gezet... dit laagje controleert in welke omgeving de code zich bevind... indien het een test of ontwikkelomgeving is zullen alleen mails aan een bepaalde subset van e-mailadressen worden doorgelaten (en die subset bevat eigenlijk alleen de mailadressen van de ontwikkelaars)...

Simpele vraag wellicht, maar waarom zou je uberhaupt tussen applicatie en email controleren in welke omgeving je zit?

Wij splitsen het over het algemeen (eigenlijk altijd) in 2 config files op (1 bevat instellingen die een klant moet kunnen wijzigen voor de applicatie en 1 bevat de instellingen voor de infrastructuur) en gooien er hardcoded defaults in die verwijzen naar interne test-services van ons.
Dus de email gaat gewoon naar een volwaardige email server die alles accepteert en overal webmail op heeft.

Het enige wat wij doen is in ons login-script het infrastructuur config bestandje op read-only zetten op elke dev-omgeving.

Al die extra controles etc zijn wmb allemaal extra complexiteit waar ik eerlijk gezegd het nut niet van inzie en wat alleen maar fouten kan bevatten, de emailserver etc moet toch configurabel zijn, dus waarom zou ik dan niet gewoon de email server aanpassen