Database van testomgeving naar live-omgeving overzetten

[Verwijderd]

Ik vroeg mij af wat in CMS-pakketten als Drupal en Wordpress de beste methode is om een database van een testomgeving over te zetten naar een live-omgeving.

Stel, je hebt een website draaien in één van deze systemen en deze moet uitgebreid worden met extra functionaliteiten. Je maakt een kopie van de website naar een testomgeving om daar alles te bouwen en zodra dit klaar is wil je dit natuurlijk integreren in de live-omgeving.

Tijdens de ontwikkelperiode kan alleen in de live-omgeving ook het een en ander veranderd zijn, zoals nieuw of aangepaste pagina's, verwijzingen naar foto's en dergelijke.

Hoe kun je dan het beste de database met nieuwe functionaliteiten overzetten naar de live-omgeving? Je kunt niet de hele database zomaar overzetten, want dan ben je alles wat in de tussentijd is veranderd kwijt. Je kunt volgens mij ook niet alleen de nieuwe records overzetten, want het lijkt me dat je dan conflicten in IDs kunt krijgen in de database.

Wat is in zo'n geval de beste methode?

[Standeman]

Zorgen dat je tijdens de ontwikkeling alle wijzigingen (data & structuur) bijhoudt in een SQL file en deze draaien op de productieserver. ID's laat je natuurlijk gewoon genereren.

[Room42]

Standeman schreef op maandag 27 augustus 2018 @ 12:44:
[...] ID's laat je natuurlijk gewoon genereren.

Hoe pak je dan eventuele referenties naar die ID's aan?

[Avalaxy]

Room42 schreef op maandag 27 augustus 2018 @ 12:47:
[...]

Hoe pak je dan eventuele referenties naar die ID's aan?

GUIDs gebruiken als PK

[MAX3400]

Ik snap het issue niet geheel; een ontwikkelomgeving is toch bedoeld om wijziginge op produktie voor te bereiden? Niet per definitie om de wijzigingen te "kopieren"?

Als ik in O een aantal scripts wijzig en daardoor wijzig ik bepaalde key indices, dat kan je toch niet naar P kopieren? Op P kondig je maintenance af, voert dezelfde scripts uit en daarna heb je P gelijk gemaakt aan O?

[Standeman]

Room42 schreef op maandag 27 augustus 2018 @ 12:47:
[...]

Hoe pak je dan eventuele referenties naar die ID's aan?

Niet. Data wordt (voornamelijk) gegenereerd door gebruikers in de productieomgeving en niet in de testomgeving. Qua data zou er helemaal geen relatie moeten zijn tussen test en productie.

(En mocht het onverhoopt niet anders kunnen, schrijf ik meestal een tooltje die de database vult zodat ik gebruik kan maken van alle domein logica en business rules)

[ Voor 3% gewijzigd door Standeman op 27-08-2018 12:58 ]

[Verwijderd]

MAX3400 schreef op maandag 27 augustus 2018 @ 12:50:
Ik snap het issue niet geheel; een ontwikkelomgeving is toch bedoeld om wijziginge op produktie voor te bereiden? Niet per definitie om de wijzigingen te "kopieren"?

Als ik in O een aantal scripts wijzig en daardoor wijzig ik bepaalde key indices, dat kan je toch niet naar P kopieren? Op P kondig je maintenance af, voert dezelfde scripts uit en daarna heb je P gelijk gemaakt aan O?

Stel nou dat je een heel uitgebreid formulier wilt toevoegen met verschillende bedankpagina's afhankelijk van keuzes die in het formulier zijn gemaakt. Dit wil je dan toch eerst maken en testen in een testomgeving lijkt mij.

Maar zodra dat klaar staat lijkt het mij handig om dit in één over te zetten naar de productieomgeving. Of maak je daar alles dan weer opnieuw aan?

IDs lijken mij dan problemen op te leveren, omdat in Drupal bijvoorbeeld afbeeldingen in de database refereren naar een node ID. De nodeID kan in de testomgeving dan anders zijn dan in de productieomgeving en dan krijg je conflicten.

[Standeman]

Verwijderd schreef op maandag 27 augustus 2018 @ 13:12:
[...]

Stel nou dat je een heel uitgebreid formulier wilt toevoegen met verschillende bedankpagina's afhankelijk van keuzes die in het formulier zijn gemaakt. Dit wil je dan toch eerst maken en testen in een testomgeving lijkt mij.
...

Ik zou juist zoiets in productie doen en toegang beperken tot ingelogde gebruikers met een bepaalde (dev?) rol. Zodra je klaar bent maak je het pas publiek toegankelijk.

[disclaimer]
Ik heb bijzonder weinig verstand van CMS systemen
[/]

[DJMaze]

Verwijderd schreef op maandag 27 augustus 2018 @ 12:17:
Ik vroeg mij af wat in CMS-pakketten als Drupal en Wordpress de beste methode is om een database van een testomgeving over te zetten naar een live-omgeving.

Zolang iets een migratie api/tool heeft kan het meestal wel. Anders niet.

[MAX3400]

@Verwijderd je geeft het zelf al aan met je voorbeeld; in O maak je formulieren en verwijzingen en plaatjes etc. Allerlei ID's veranderen, hetzij afzonderlijk, nieuw, naar elkaar, etc. Dan kan je toch niet, plat gezegd, copy/paste doen van de spullen die je hebt aangepast incl de database, "file content", etc...

[Croga]

Verwijderd schreef op maandag 27 augustus 2018 @ 13:12:
Stel nou dat je een heel uitgebreid formulier wilt toevoegen met verschillende bedankpagina's afhankelijk van keuzes die in het formulier zijn gemaakt. Dit wil je dan toch eerst maken en testen in een testomgeving lijkt mij.

Maar zodra dat klaar staat lijkt het mij handig om dit in één over te zetten naar de productieomgeving. Of maak je daar alles dan weer opnieuw aan?

IDs lijken mij dan problemen op te leveren, omdat in Drupal bijvoorbeeld afbeeldingen in de database refereren naar een node ID. De nodeID kan in de testomgeving dan anders zijn dan in de productieomgeving en dan krijg je conflicten.

Je bent nu niet meer aan het ontwikkelen maar ook aan het vullen....

O is de Ontwikkel omgeving die bedoelt is om te ontwikkelen. Inhoud overzetten van O naar P is niet de bedoeling.
P is de Productie omgeving, daar zit de productie data in.

Dus als je praat over het aanmaken van een formulier dan is dat ontwikkeling. Het vullen van een bedank pagina is inhoud. Die hoort niet op O thuis.
Wat je zou kunnen doen is de bedank pagina voor een deel coderen maar de inhoud wijzigbaar maken zodat Marketing daar de juiste bedankjes neer kan zetten..... Zo weet je zeker dat je formulier juist blijft werken, ook al staat er niet de juiste inhoud in de bedank paginas.

Bekijk het zo:
Stel dat je dat formulier maakt met links naar pages. De content eigenaar verwijdert vervolgens de pages en komt bij jou klagen dat het formulier niet meer werkt...... Dat moet je niet willen.

[Verwijderd]

MAX3400 schreef op maandag 27 augustus 2018 @ 13:31:
@Verwijderd je geeft het zelf al aan met je voorbeeld; in O maak je formulieren en verwijzingen en plaatjes etc. Allerlei ID's veranderen, hetzij afzonderlijk, nieuw, naar elkaar, etc. Dan kan je toch niet, plat gezegd, copy/paste doen van de spullen die je hebt aangepast incl de database, "file content", etc...

Vandaar ook mijn vraag wat de beste methode is

In het geval van mijn voorbeeld zou een testomgeving dus eigenlijk een overkill zijn en levert teveel dubbel werk op?

[MAX3400]

Verwijderd schreef op maandag 27 augustus 2018 @ 13:36:
[...]

Vandaar ook mijn vraag wat de beste methode is

In het geval van mijn voorbeeld zou een testomgeving dus eigenlijk een overkill zijn en levert teveel dubbel werk op?

Lastig om in te schatten hoe jij/jullie werken maar voorbeeldje: in O wil je een nieuw stuk PHP van 300 regels. En in die code verwijs/query je 6x de database. Sowieso 300 regels code is al "tijd" en dan kom je er ook nog achter dat elke query 16 seconden duurt want non-indexed. Je creert 3 nieuwe indices en een grotere execution buffer. En na 10 uur werk is alles af.

Dan naar P: code is plat copy/paste dus 5 seconden. Indices en buffer zijn SQL-statements dus 1 minuut? Dan een node ID opvoeren naar de nieuwe PHP kost je 1 minuut?

Heb je dus in O 10 uur besteed om alles af te dekken, programmeren, testen en optimaliseren; en in P misschien 5 minuten en zelfs zonder mogelijke downtime (alleen kleine load op de DB bij je nieuwe statements opvoeren).

Maar, misschien dat ik te simpel denk? Heb je dan een voorbeeld waar je nu tegenaan loopt? Of hoe je iets doet? Zeker voor dit soort CMS-oplossingen maak je (bijna) nooit hardcoded zaken maar (bijna) altijd soft-coded zaken waardoor porteren naar devolgende omgeving makkelijker gaat?

[AW_Bos]

Voor mijn CMS die ik nu aan het updaten ben, heb ik een sql-file gemaakt met alle queries die ik in de ontwikkelomgeving heb toegevoegd.

Nu is het even hopen of alles netjes in dat migratie bestand staat. Maar dat wordt snel duidelijk als ik die naar de testomgeving uit ga voeren.

Uiteraard heb ik ook een tooltje gemaakt om twee databases te kunnen vergelijken met elkaar. De ontwikkeldatabase en de database van de testomgeving die ik ga upgraden. Dus de verschillen kan ik toch al vrij makkelijk zien.