Development structuur

[Verwijderd]

Ik zit momenteel te blokken op een probleem en kom er niet helemaal uit.
Op mijn werk willen we een volgende development-structuur aan gaan nemen.

De local-pc is de pc van de ontwikkelaar zelf (waarschijnlijk wel een soort gedeelde map maar individueel qua ontwikkelaar). Hiervandaan wordt er na het afmaken van een feature gepusht naar de development server, waar de items geverified worden en er na het afmaken van een sprint de totale dev-omgeving gesynct wordt met de staging omgeving. In deze staging werkt de klant ook, en zodra gesynct wordt zal de live database worden gedropt en komt er de staging versie eroverheen. (niet helemaal duidelijk vanuit het plaatje maar de bedoeling is dat er qua live/staging database beleid nooit een probleem is, live wordt er nooit iets aangepast, alleen vanuit staging komt er een wijziging door, vandaar de 2 databases in plaats van 3.

Het probleem hiervan is echter de database. Vanaf staging naar live is er nooit een probleem. Vanaf DB-dev naar DB-final kunnen er echter wel problemen voorkomen. Vaak niet, maar als we bijvoorbeeld een field-type veranderen kunnen we het niet doen met een sync vanaf DB-final naar DB-dev en na wijzigingen weer terug. En dan heb ik het nog niet eens over wijzigingen die de klant tussendoor toevoegt.

DB-techniek die gebruikt wordt is MySQL en ik heb nog geen definitief fijne sync-tool tussen beide systemen gevonden. Zijn er mensen die dit probleem ook hebben (kan me niet voorstellen van niet) en hoe is dit opgelost?
Wijzelf komen er niet uit en hebben vooral problemen met de field-types en dergelijke zodat bepaalde content niet meer compatible is. Vaak is dit dan wel omzetbaar maar is dat te automatiseren? Uiteindelijk wil je natuurlijk een strak gestroomlijnd proces vanaf local-pc naar live.

Ideetjes zijn erg welkom!

[Janoz]

De meest prettige manier waar ik tot nu toe mee gewerkt heb (in een omgeving waarin dit niet automatisch kon) is het meeleveren van een update script van de ene versie naar een andere versie en af en toe ook een heel create script voor de database. Onderdeel van de test is dan ook om niet alleen de functionaliteit te testen, maar ook de installatie. Het is in dat geval dan wel handig om toch echt een aparte staging DB te gebruiken. Als onderdeel van de test kun je dan (een deel van) de live DB terugkopieren naar de staging DB en vervolgens testen of het update script juist werkt.

[Verwijderd]

Dat is uiteraard het flexibelst, plus je hebt altijd duidelijk wat er in welke revisie is veranderd (als je die update scripts gewoon mee versioned).
Is er echter zover jij weet niet een soort automatizerings manier hiervoor? Het lijkt me nogal vervelend dat als je een beetje strak ontwikkelt en je wilt per twee weken een release uitbrengen je elke twee weken per project 1 maal moet controleren hoe het qua types etc zit om geen content te verliezen.

[pderaaij]

Verwijderd schreef op dinsdag 11 oktober 2011 @ 11:00:
Dat is uiteraard het flexibelst, plus je hebt altijd duidelijk wat er in welke revisie is veranderd (als je die update scripts gewoon mee versioned).
Is er echter zover jij weet niet een soort automatizerings manier hiervoor? Het lijkt me nogal vervelend dat als je een beetje strak ontwikkelt en je wilt per twee weken een release uitbrengen je elke twee weken per project 1 maal moet controleren hoe het qua types etc zit om geen content te verliezen.

Het lijkt me dat het wijzigen van een veld type een bewuste keus en dat je dit niet onder water wilt laten gebeuren. Door de wijzing in een handmatig script uit te voeren heb je er controle op en kun je adequater op problemen reageren.

Zelf werk ik regelmatig in zend Framework en maak dan gebruik van Akrabat DB Schema Manager -> http://akrabat.com/zend-f...work-database-migrations/

Er zijn nog veel andere tools die je op dezelfde manier ondersteunen met het beheren van je DB schema...

[djluc]

Het houdt in dat een developer nooit een database wijziging mag doen maar alleen een script mag maken wat de database aanpast. Dat lost je probleem op en je kan het controleren door de scripts te draaien over een kopie de live database. Het resultaat moet dan werken.

[Verwijderd]

In principe zou dat laatste zeker werken, maar je hebt vaak systemen draaien die intern de database wijzigen, pak een aantal stevige cms pakketten die een zeer ingewikkelde database structuur hebben waarbij je niet even handmatig de database kan nog wil wijzigen.

[Janoz]

Eigenlijk ken ik maar heel weinig applicaties die intern de database wijzigen, anders dan tijdens een installatie of upgrade. Ik snap dan ook niet precies wat je probleem is en wat dat met je eigen development te maken heeft.

[Verwijderd]

Tijdens installatie is er geen enkel probleem, het gaat vooral om updates.
Ik maak het wekelijks mee dat er ergens iets wijzigt in de database, gaat dan vooral om websites en online zakelijke applicaties die gewoon net qua type ergens wijzigen.
Het probleem is dat je het niet met 1 druk op de knop kan doen zodra je de database af laat hangen van een systeem van anderen wat ook tussendoor nog updates krijgt waardoor er wel eens types kunnen wijzigen (wat dan ook weer netjes via dev->staging->live gaat.
Momenteel wordt het opgelost door ervoor te zorgen dat klanten niets op staging kunnen uitvoeren tijdens het opnieuw ontwikkelen, duurt dit bijvoorbeeld langer dan een week dan is het uiteraard niet helemaal prettig. Wij backuppen dan de staging omgeving naar dev, werken eraan en pushen het er hard overheen.

[Wolfboy]

Bij ons doen we dergelijke database migraties altijd met South, maar dat gaat er wel vanuit dat je het Django framework gebruikt.

Een generieke optie hiervoor is Flyway

[djluc]

Heb toevallig net weer een project wat begon als een grappig testscript in een Git omgeving gezet met automatisch deployment middels: Git push production. Dat commando maakt nu automatisch een dump van de database, verzend via ssh de files en deployed deze vervolgens op de productieserver.

Eventueel in de toekomst nog automatische tests e.d. toevoegen en dan is het een strakke oplossing. Zometeen maar wat andere developers toegang gaan verlenen en dan kunnen we weer verder.

Documentatie is nog wel een crime, ben weer eens met Doxygen aan de slag gegaan maar echt lekker werkt het toch niet.

edit: Hooks zijn trouwens echt de key als je serieus met GIT aan de slag wilt gaan. Middels hooks is het super eenvoudig zaken te automatiseren waardoor je zeker wat dat ze met elke commit of push ook daadwerkelijk gebeuren.

[ Voor 15% gewijzigd door djluc op 25-10-2011 16:40 ]

[Verwijderd]

djluc

Momenteel werk ik inderdaad al met de hooks van GIT, werkt erg handig en we hebben eigenlijk alles vloeiend lopen qua structuur behalve de databases. Een dump maken, verzenden en weer deployen doen we nu niet, kan ik wel bouwen, maar ik ben nog niet uit de consistentie van de data, wat daar een juiste manier voor is. Zit momenteel te zoeken naar duidelijke cross-platform database migration, waar flyway dus een mogelijkheid van is!

[djluc]

Heb nu sowieso deze pre-commit hook staan:

code:

#!/bin/sh
/Applications/MAMP/Library/bin/mysqldump -u username -ppassword datebasename --no-data=true> SQLVersionControl/vc.sql
git add SQLVersionControl/vc.sql
exit 0

Deze maakt standaard een dump van de database, heb deze ergens op een blog gevonden. Zo heb ik in ieders geval de juiste dump altijd in het repository zitten.

[Verwijderd]

Er zijn verscheidene database version management tools maar wij prefereren om iedere update als een losse sql file op te slaan binnen een repository en er wordt bijgehouden welke versie van het databasemodel hoort bij welke revisie van de applicatie en worden de database wijzigingen doorgevoerd.

Database wijzigingen op productie wordt echt veel, het gaat meer om toevoegingen eigenlijk.

Voor eigen systemen heeft iedere module een migrate en install 'hook' die aangeroepen wordt om nieuwe tables aan te maken aan de hand van de oude versie tov de nieuwe versie, dit werkt eigenlijk best goed.