Ontwikkelomgeving: Juiste denkwijzen?

[bindsa]

Binnenkort ga ik mijn complete ontwikkelomgeving (voor PHP + MySQL/MongoDb applicaties) omgooien. Nu wil ik alles in een keer goed regelen.
Ik had het volgende in gedachten:

- Een NAS o.i.d. met een SVN Server en iets als XAMPP (Voor de MySQL server en de Apache server)
- Die NAS dient dan als Dev omgeving
- Mijn IDE wou ik zou instellen dat ik on-save sync met de dev webserver en MySQL server en met een simpele shortcut commit naar de SVN server
- Vanuit de SVN server wou ik dan, als ik dat wil, checkouts doen naar de live web server + MySQL server

Schematisch ziet dit er dan als volgt uit:



Waar ik nog een beetje over aan het nadenken ben:

- Hoe kan ik de databases nou makkelijk downloaden/uploaden naar dev/live omgeving?
Nu doe ik het altijd gewoon met PHPMyAdmin, export, dan weer import etc.
Zijn er ook mogelijkheden om vanuit PHPStorm (mijn toekomstige IDE) met een druk op de knop bijv. alléén de structuur van de database van de dev omgeving naar de live omgeving over te hevelen?
En om bijvoorbeeld de data + structuur van de database uit de live omgeving te downloaden en te importen naar de dev-omgeving?
Of zijn hier andere manier voor?

Hebben jullie verder hierop nog feedback en/of opmerkingen?

[ Voor 4% gewijzigd door bindsa op 29-07-2011 10:44 ]

[NMe]

Een save zou nooit automatisch mogen committen. Je hoort een commit bewust te doen zodat je zeker weet dat je de build niet breekt.

Wat betreft je databasevraag: volgens mij kan PhpStorm daar niets voor je betekenen. Wij hebben op kantoor in elke repository naast het mapje voor de webroot ook nog mapjes voor de databaselayout, de ontwerpen (PSD's) endocumentatie zodat die ook geversioneerd kunnen worden. Exporteren/importeren doe ik ook gewoon met de hand via PhpMyAdmin.

Ik zal deze vraag trouwens, zoals je zelf al voorstelde in een TR, verplaatsen naar SEA, daar past je vraag iets beter.

[Dragor]

NMe schreef op vrijdag 29 juli 2011 @ 10:07:
Een save zou nooit automatisch mogen committen. Je hoort een commit bewust te doen zodat je zeker weet dat je de build niet breekt.

Dat.

En ik kwam een paar dagen geleden erachter dat PHPMyAdmin (ik draai nu 3.3.7deb5) een Synchronize feature heeft om meerdere databases te synchen, zie http://www.phpmyadmin.net...onization_User_Manual.htm
Misschien dat dat je kan helpen.

[sub0kelvin]

Ik sluit me aan bij de rest wat betreft SVN. Je wilt eigenlijk alleen werkende code in SVN, zodat je er op kan vertrouwen (unit-tests vóór committen) dat als je later uitcheckt of als je later teruggaat naar een oudere versie, dat je dan kunt vertrouwen op hetgeen ingecheckt is. Natuurlijk check je wel eens nieuwe bugs in, maar dat is wat anders dan rauwe development-gerelateerde fouten inchecken. Daarnaast, ik weet niet hoe vaak jij savet, maar ik doe dat al gauw een paar keer per minuut.... dat betekent dat je door honderden commits moet scrollen als je even wilt teruggaan naar een oudere versie van een paar dagen terug, of als je de history van een bestand wil doornemen.

Om je database-schema up-to-date te houden is alleen de structuur natuurlijk niet voldoende. Bijvoorbeeld als je dingen hebt gerefactord en er ergens een kolom bij is gekomen die gevuld moet worden op basis van gegevens uit een andere kolom of tabel. Dat zie je niet terug in de structuur, dus je zult altijd zelf bewust de updates moeten schrijven voor je database. Ook omdat je het updateproces van een productie-database zelf in de hand wilt houden en niet wil vertrouwen op een ongecontroleerd automatisch proces.

Om databasewijzigingingsscripts gestructureerd bij te houden en uit te voeren kun je ook gebruik maken van Liquibase. De scripts die je daarvoor schrijft zijn versioneerbaar en kun je dus samen met je code inchecken en meenemen in je update-proces. Het fijne is dat Liquibase er voor zorgt dat je databaseschema zelf weet welke versie hij is, dus je kunt niet per ongeluk 2x dezelfde wijziging doorvoeren.

[bindsa]

Ah foutje van mij in de startpost, on save wil ik syncen met de dev server, bij CTRL+K wil ik committen... Excuus ga ik aan passen.

Dank voor de tip van Liquibase, ga ik naar kijken!

[Y0ur1]

Wat maakt het uit hoe je precies commit? Je wilt persé committen met een toetsencombinatie, het lijkt er op dat je SVN meer ziet als een bak waarin je al je code dumpt. Nu is dat wel zo in principe maar zoals eerder aangegeven is verschilt het fundamenteel met het saven van een file.

Tip: lees eens wat over release management.

Waar je verder naar zou kunnen kijken is Beanstalk, hiermee kun je eenvoudig code naar servers deployen.

Als je met meerdere mensen op die ontwikkelserver gaat werken raad ik je een NAS sterk af. Samba en SVN met meerdere mensen trekken eenvoudig NAS systemen niet, vooral als je daarbij ook nog PHP en MySQL gaat draaien. Als je alleen bent kun je ook een dev server in een virtual machine draaien als je een beetje geheugen hebt, scheelt een boel investering

[sub0kelvin]

T.H. Lassche schreef op vrijdag 29 juli 2011 @ 10:44:
Ah foutje van mij in de startpost, on save wil ik syncen met de dev server, bij CTRL+K wil ik committen... Excuus ga ik aan passen.

Dank voor de tip van Liquibase, ga ik naar kijken!

Ah ok, op die manier. Dat klinkt een stuk logischer

De developomentdatabase aanpassen doe ik altijd live met (in het geval van MySQL) met de mysql-workbench. Op basis van de wijzigingen aan de dev-database die zijn gedaan tussen commits maken we dan updatescripts. Deze worden dan uitgevoerd tijdens het uitrollen op testing, training en uiteindelijk productie.

[Boss]

Y0ur1 schreef op vrijdag 29 juli 2011 @ 10:58:
Als je met meerdere mensen op die ontwikkelserver gaat werken raad ik je een NAS sterk af. Samba en SVN met meerdere mensen trekken eenvoudig NAS systemen niet, vooral als je daarbij ook nog PHP en MySQL gaat draaien. Als je alleen bent kun je ook een dev server in een virtual machine draaien als je een beetje geheugen hebt, scheelt een boel investering

Onderschat de nieuwe NASsen niet. Bijvoorbeeld Synology maakt behoorlijk krachtige systemen.

[NMe]

Y0ur1 schreef op vrijdag 29 juli 2011 @ 10:58:
Als je met meerdere mensen op die ontwikkelserver gaat werken raad ik je een NAS sterk af. Samba en SVN met meerdere mensen trekken eenvoudig NAS systemen niet, vooral als je daarbij ook nog PHP en MySQL gaat draaien. Als je alleen bent kun je ook een dev server in een virtual machine draaien als je een beetje geheugen hebt, scheelt een boel investering

Mwah, een NAS is niet per definitie een bak harde schijven die met minimale hardware aan elkaar hangt. Afhankelijk van de hardware heb je inderdaad gelijk.

[Remus]

T.H. Lassche schreef op vrijdag 29 juli 2011 @ 09:51:
- Vanuit de SVN server wou ik dan, als ik dat wil, checkouts doen naar de live web server + MySQL server

Als je het al direct uit subversion wil trekken (wat mij niet een goed idee lijkt) voor je productieomgeving, gebruik dan export ipv checkout!

Ik zou echter aanraden om iets minder direct vanuit je repository naar productie te gaan. Creeër een release-tag in subversion en maak van daaruit een release package, gebruik de release package uit die tag om op je testomgeving te testen (niet alleen de software zelf, maar ook deployment stappen, database changes etc) en ga pas dan met die releasepackage en 'lessons learned' naar productie.

[bindsa]

Y0ur1 schreef op vrijdag 29 juli 2011 @ 10:58:
Wat maakt het uit hoe je precies commit? Je wilt persé committen met een toetsencombinatie, het lijkt er op dat je SVN meer ziet als een bak waarin je al je code dumpt. Nu is dat wel zo in principe maar zoals eerder aangegeven is verschilt het fundamenteel met het saven van een file.

Ik heb niet gezecht hoevaak ik die toetsencombi gebruik Typisch alleen na een devsessie (aan het eind dus) namelijk.

Waar je verder naar zou kunnen kijken is Beanstalk, hiermee kun je eenvoudig code naar servers deployen.

Dank

Als je met meerdere mensen op die ontwikkelserver gaat werken raad ik je een NAS sterk af. Samba en SVN met meerdere mensen trekken eenvoudig NAS systemen niet, vooral als je daarbij ook nog PHP en MySQL gaat draaien. Als je alleen bent kun je ook een dev server in een virtual machine draaien als je een beetje geheugen hebt, scheelt een boel investering

Ben in m'n eentje. En ik wil de boel ergens centraal opslaan. Vandaar die NAS

[ Voor 3% gewijzigd door bindsa op 29-07-2011 13:39 ]

[NMe]

T.H. Lassche schreef op vrijdag 29 juli 2011 @ 13:38:
[...]

Ik heb niet gezecht hoevaak ik die toetsencombi gebruik Typisch alleen na een devsessie (aan het eind dus) namelijk.

Het is gebruikelijk een commit te doen na elke "mijlpaal". Feature af? Commit. Bug gefixt? Commit.

[Y0ur1]

@TS:
Ik zie dat je een eenmanszaak hebt, ik zou zeggen: begin simpel. Je kunt je tijd veel beter steken in opdrachten dan het opzetten van een heel serverpark Maak slim gebruik van oplossingen die er al zijn en hou het simpel:
- bijvoorbeeld Beanstalk voor SVN / GIT hosting en deployment
- hosted mail
- maak een virtual machine aan die gelijk is aan de live server (kwa config) op je workstation, zo heb je helemaal geen aparte server nodig
- database server hoeft geen fysieke aparte server te zijn
- maak een samba share aan naar je dev server (virtual machine), dus meteen naar je www root
- dingen synchroniseren en uitgebreide deployment strategieën kosten altijd tijd en voegen complexiteit toe die je misschien niet eens nodig hebt
- gebruik online off site backup
- kijk ook eens naar MySQL workbench, is een stuk beter dan phpmyadmin
- het up-to-date houden van je database schema is een apart topic waard, misschien wel een boek. Maar wederom: hou het simpel als het geen mega grote kritische projecten zijn. Meestal volstaat het bijhouden van je wijzigingen in losse update files ook. Die kun je dan uitvoeren bij het live zetten van je nieuwe code.
- release management is mooi, tags, branches etc, maar kijk goed of het loont.

Mijns inziens heb je niet veel meer nodig als ZZP'er voor kleine tot middelgrote projecten.

[bindsa]

Y0ur1 schreef op vrijdag 29 juli 2011 @ 14:59:
@TS:
Ik zie dat je een eenmanszaak hebt, ik zou zeggen: begin simpel. Je kunt je tijd veel beter steken in opdrachten dan het opzetten van een heel serverpark Maak slim gebruik van oplossingen die er al zijn en hou het simpel:
- bijvoorbeeld Beanstalk voor SVN / GIT hosting en deployment
- hosted mail
- maak een virtual machine aan die gelijk is aan de live server (kwa config) op je workstation, zo heb je helemaal geen aparte server nodig
- database server hoeft geen fysieke aparte server te zijn
- maak een samba share aan naar je dev server (virtual machine), dus meteen naar je www root
- dingen synchroniseren en uitgebreide deployment strategieën kosten altijd tijd en voegen complexiteit toe die je misschien niet eens nodig hebt
- gebruik online off site backup
- kijk ook eens naar MySQL workbench, is een stuk beter dan phpmyadmin
- het up-to-date houden van je database schema is een apart topic waard, misschien wel een boek. Maar wederom: hou het simpel als het geen mega grote kritische projecten zijn. Meestal volstaat het bijhouden van je wijzigingen in losse update files ook. Die kun je dan uitvoeren bij het live zetten van je nieuwe code.
- release management is mooi, tags, branches etc, maar kijk goed of het loont.

Mijns inziens heb je niet veel meer nodig als ZZP'er voor kleine tot middelgrote projecten.

Bedankt voor je tips Het worden ook geen allemaal fysiek aparte servers, e.e.a. wordt sowieso wel virtueel geregeld. Database schema moet in mijn geval wel goed voor elkaar zijn, ik werk vaak aan CRM's van +200 tabellen. SVN is ook hard nodig, het zou niet de eerste keer zijn dat de klant zegt: 'Die ene tekst/image die 2 maanden terug nog op de site stond kan je die even terugzetten, etc', je kent het wel

[Verwijderd]

T.H. Lassche schreef op vrijdag 29 juli 2011 @ 17:41:
[...]

het zou niet de eerste keer zijn dat de klant zegt: 'Die ene tekst/image die 2 maanden terug nog op de site stond kan je die even terugzetten, etc', je kent het wel

Dit zou ik eerder met normale back-ups regelen. svn is niet bedoelt als backup-service. Als je mieters veel plaatjes in je repo gaat zetten wordt het ook een stuk trager

[chime]

Op het schema mis ik nog een acceptatieomgeving.
Iets waarop je de release/gebruikers even op kunt laten testen zonder je live-omgeving te besmetten.

Acceptatie zou qua omgeving ook zo gelijk mogenlijk moeten zijn aan productie (versie OS, ... )

[-DarkShadow-]

T.H. Lassche schreef op vrijdag 29 juli 2011 @ 17:41:
[...]
Database schema moet in mijn geval wel goed voor elkaar zijn, ik werk vaak aan CRM's van +200 tabellen.

Ik ken geen generieke naam voor dit systeem, maar in een framework dat ik wel eens gebruik zit dit:
http://www.yiiframework.c...1.1/en/database.migration

Zo kun je gemakkelijk vanuit dev veranderingen doorvoeren in het db schema in productie. Rollback is ook geen probleem en je db blijft compatible met je software.

[bindsa]

-DarkShadow- schreef op maandag 01 augustus 2011 @ 21:26:
[...]

Ik ken geen generieke naam voor dit systeem, maar in een framework dat ik wel eens gebruik zit dit:
http://www.yiiframework.c...1.1/en/database.migration

Zo kun je gemakkelijk vanuit dev veranderingen doorvoeren in het db schema in productie. Rollback is ook geen probleem en je db blijft compatible met je software.

Dank voor de tip!

[johnydoe]

Dat systeem heeft ook gewoon Database Migrations, zoals yii het ook noemt.
Doormiddel van Phing en DBDeploy kun je al aardig ver komen als je geen framework gebruikt wat dit ondersteund, zie linkje.

Ik heb in een snelle google actie ook een tooltje gevonden wat dit voor je kan doen.

In ieder geval komt het er op neer dat je voor iedere migratie een script maakt wat die migratie voor je kan doen (tables aanmaken, wijzigen of droppen, maar ook de data migreren). Het liefst maak je ook nog een rollback bestand, waarmee de migratie weer hersteld kan worden, maar als ZZP'er is dat misschien nu wat teveel van het goede meteen.

Succes

[alt-92]

Alhoewel, ook als ZZP'er heb je enorm voordeel aan een goeie Rollback optie.
Het voorkomt dat je uren voor eigen rekening zit te werken als je toch terug moet draaien, of nog erger.