Ontwikkelomgeving

[reshi]

Mensen,

Na nogal wat zoeken op (vooral) Google,hier op het forum, op het Joomla forum zelf, tek-tips forum, webmasterworld forum en wat dingen gelezen te hebben over software ontwikkeling op Wikipedia heb ik toch nog iets meer hulp nodig en ik hoop dat jullie me hiermee kunnen helpen.

Ik werk momenteel aan een site of 30. Het merendeel van deze sites is gemaakt mbv Joomla. "Binnenkort" zal een tweede persoon ook aan de sites gaan werken en daarom ben ik op zoek naar een versie beheer tool en een ontwikkelomgeving.

Ik had het volgende al gevonden voor mijn versie beheer:
http://subversion.apache.org/ gehost bij http://unfuddle.com/, maar ik vroeg me af of er nog meer van dit soort tools zijn? Uiteraard geeft Google veel resultaten, maar gezien mijn beperkte kennis hierover zou ik graag de ervaringen van andere hierover horen.

Voor de ontwikkelomgeving heb ik minder succes gehad. Mensen gebruiken hier vooral een locale Apache installatie voor of een tool zoals xampp. Dit is voor mij niet echt een optie, 30 verschillende sites op 30 verschillende hosts met 30 verschillende instellingen... Ik heb niet de tijd of de kennis om al deze hosts lokaal te "klonen". Of is hier een "simpele" oplossing voor?

Het handigste leek mij, om te testen op de server waarop ook de live site draait. Echter zit ik dan met het probleem dat ik werk op dev.mijndomein.com inplaats van www.mijndomein.com. En omdat ik altijd werk met absolute WWW url's is het onhandig om elke keer de juiste aanpassingen door te voeren tussen dev en live omgeving.

Daarnaast maken de Joomla sites gebruik van een database. Terwijl ik bezig ben met de site in de ontwikkelomgeving wordt er door andere content toegevoegd/aangepast op de live site. Is er een manier om de live site automatisch te syncen met de test site maar niet visa versa? Ik moet dan zelf kunnen aangeven welke tabellen wel of niet gesynced moeten worden.

En hoe werkt dit alles samen met bijvoorbeeld subversion?

Dit is mijn eerste stap in deze richting en elke hint/tip of opmerking is dan ook van harte welkom!

[Verwijderd]

Waarom zet je zelf niet een development server op (met je eigen subversion server). Je kun hierop dan rustig alles testen en dan maakt het ook niet uit als het even down is. Je zou met een subversion hook script alle commits op trunk automatisch door kunnen laten voeren naar je webroot voor testing doeleinden. Verder zou je een nfs share open kunnen zetten voor development.

[Boss]

Zolang je met absolute URLs blijft werken lijkt het mij praktisch onmogelijk om goed te kunnen debuggen. Is daar een reden voor?

[NMe]

Boss schreef op maandag 19 juli 2010 @ 10:40:
Zolang je met absolute URLs blijft werken lijkt het mij praktisch onmogelijk om goed te kunnen debuggen. Is daar een reden voor?

Dat wil ik ook graag weten. Als je zelf al tegen de beperkingen aanloopt begrijp ik niet dat je hieraan vasthoudt. Overigens zou je dan op een lokale testserver natuurlijk hetzelfde probleem hebben.

[YopY]

reshi schreef op maandag 19 juli 2010 @ 10:09:
Ik had het volgende al gevonden voor mijn versie beheer:
http://subversion.apache.org/ gehost bij http://unfuddle.com/, maar ik vroeg me af of er nog meer van dit soort tools zijn? Uiteraard geeft Google veel resultaten, maar gezien mijn beperkte kennis hierover zou ik graag de ervaringen van andere hierover horen.

Tegenwoordig worden Mercurial en GIT als betere alternatieven gezien - als je version control systemen toch moet leren kun je misschien beter naar deze twee kijken.

Voor de ontwikkelomgeving heb ik minder succes gehad. Mensen gebruiken hier vooral een locale Apache installatie voor of een tool zoals xampp. Dit is voor mij niet echt een optie, 30 verschillende sites op 30 verschillende hosts met 30 verschillende instellingen... Ik heb niet de tijd of de kennis om al deze hosts lokaal te "klonen". Of is hier een "simpele" oplossing voor?

Je zou misschien de host kunnen vragen om een kopie van de configuraties en sites. Hoe dan ook, ik zou er wel voor kiezen om een goeie lokale ontwikkel en testomgeving te bouwen (het liefst apart - voor elke ontwikkelaar een aparte ontwikkelomgeving)

Het handigste leek mij, om te testen op de server waarop ook de live site draait. Echter zit ik dan met het probleem dat ik werk op dev.mijndomein.com inplaats van www.mijndomein.com. En omdat ik altijd werk met absolute WWW url's is het onhandig om elke keer de juiste aanpassingen door te voeren tussen dev en live omgeving.

Ik zou er toch voor kiezen om relatieve URLs te gaan gebruiken, of om de absolute URLs te laten genereren afhankelijk van de omgeving. Zo maakt het niet uit of je op localhost, dev.mijndomein.com of www.mijndomein.com zit. Live gebruiken voor ontwikkeling zou ik afraden, aangezien je, als je een fout maakt, je sites onderuit kunt halen of makkelijker per ongeluk live code overschrijft.

Daarnaast maken de Joomla sites gebruik van een database. Terwijl ik bezig ben met de site in de ontwikkelomgeving wordt er door andere content toegevoegd/aangepast op de live site. Is er een manier om de live site automatisch te syncen met de test site maar niet visa versa? Ik moet dan zelf kunnen aangeven welke tabellen wel of niet gesynced moeten worden.

Ja, dat moet gewoon kunnen. Replication kan met alle databasesystemen als het goed is, ook éénwegs. Ik zou op vaste tijden een kopie van je database maken, die je makkelijk in kunt stellen op je dev / testomgeving als je de database daarop stuk maakt. Zorg ervoor dat het opzetten van je test / devomgeving met een paar klikken voor elkaar is, zodat je niet geneigd bent om het maar op live te doen.

En hoe werkt dit alles samen met bijvoorbeeld subversion?

Nu ja, je hebt een centrale SVN repository waar jij en je toekomstige collega op werken. Zodra je aanpassingen klaar zijn en je het getest hebt en er groen licht voor gegeven wordt, kun je je sites de nieuwe code van de SVN af laten halen - als dat tenminste kan bij je host. Anders moet je handmatig de nieuwe code uit de SVN halen en uploaden, wat overigens ook niet zoveel werk is.

Stop de code, configuratie, database schema's (en evt. testdata) en documentatie in je SVN. Als je gebruik maakt van één stuk code voor al je websites doe je dat in één map, met site-specifieke informatie in andere mappen. Als elke site zijn eigen code hebt maak je voor elke site een map.

En lees natuurlijk het SVN boek, gratis te downloaden (ben te lui om de link voor je op te zoeken).

[reshi]

Bedankt voor de reacties zover!

Verwijderd schreef op maandag 19 juli 2010 @ 10:20:
Waarom zet je zelf niet een development server op (met je eigen subversion server)...

Omdat we met 30 verschillende hosts werken en dus 30 verschillende omgevingen hebben. Dan zou ik al deze omgevingen moeten nabootsen op die ontwikkel server.

Verwijderd schreef op maandag 19 juli 2010 @ 10:20:
Verder zou je een nfs share open kunnen zetten voor development.

Zou je hier meer informatie over kunnen geven?

NMe schreef op maandag 19 juli 2010 @ 11:19:
[...]

Dat wil ik ook graag weten. Als je zelf al tegen de beperkingen aanloopt begrijp ik niet dat je hieraan vasthoudt. Overigens zou je dan op een lokale testserver natuurlijk hetzelfde probleem hebben.

Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

[Kettrick]

reshi schreef op maandag 19 juli 2010 @ 12:05:
Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

Ik ben geen SEO expert, maar het of een linkje relatief of absoluut is is toch gewoon template werk . Je kan prima absolute paden in je HTML krijgen zonder dat ze ook maar ergens in je code staan. Op je testomgeving krijg je dan gewoon absolute links naar de testomgeving

mbt tot versiebeheer zou ik eerder voor Git/Mq gaan dan voor SVN. Het heen en weer slepen van changes tussen verschillende omgevingen gaat wat makkelijker. De IDE integratie van svn is op dit moment nog wel wat beter, als je dat echt belangrijk vindt is svn misschien een betere keuze.

[ Voor 20% gewijzigd door Kettrick op 19-07-2010 12:13 ]

[djc]

reshi schreef op maandag 19 juli 2010 @ 12:05:
Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

Dan ben ik heel benieuwd waar jullie je SEO-advies halen.

[djluc]

YopY schreef op maandag 19 juli 2010 @ 12:00:
[...]
[...]
Tegenwoordig worden Mercurial en GIT als betere alternatieven gezien - als je version control systemen toch moet leren kun je misschien beter naar deze twee kijken.

[...]

Unfuddle is een grote GIT hoster.

[NMe]

reshi schreef op maandag 19 juli 2010 @ 12:05:
Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

Sorry, maar welke zoekmachine ken jij die een relatieve url niet begrijpt en hetzelfde interpreteert als een absolute url binnen hetzelfde domein? "SEO" is hier geen argument, want absolute of relatieve urls hebben alleen effect op SEO als ze juist niet binnen hetzelfde domein vallen, en daar zijn relatieve urls dus sowieso niet mogelijk.

[fleppuhstein]

reshi schreef op maandag 19 juli 2010 @ 12:05:
Omdat we met 30 verschillende hosts werken en dus 30 verschillende omgevingen hebben. Dan zou ik al deze omgevingen moeten nabootsen op die ontwikkel server.
[...]

Is het niet juist de intensie van correcte ontwikkeling, dat je applicatie/site draait, onafhankelijk van de host ? Omgevings variabele kun je natuurlijk configureerbaar maken.

Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

Al of niet of je volledige urls nodig hebt voor SEO, kan een url toch opgebouwd worden met behulp van omgevings variabele, zodat je alsnog een volledige url kunt opbouwen onafhankelijk van tld, en subdomain.

[Verwijderd]

reshi schreef op maandag 19 juli 2010 @ 12:05:
Bedankt voor de reacties zover!
[...]
Omdat we met 30 verschillende hosts werken en dus 30 verschillende omgevingen hebben. Dan zou ik al deze omgevingen moeten nabootsen op die ontwikkel server.

Wat voor exotische configuratie hebben jullie dat je dat niet kunt afvangen in een paar vhosts?

Zou je hier meer informatie over kunnen geven?

https://encrypted.google.com/search?q=how+to+setup+a+nfs+server&ie=utf-8&oe=utf-8

Voor zoekmachineoptimalisatie gebruiken wij volledige(absolute) URL's. Hier vanaf stappen is dan ook geen oplossing. Ik ben toch vast ook niet de eerste die hier tegenaan loopt?

Welke zoekmachine optimaliseer je dan voor? Eentje uit het jaar krijtje? Welke zoekmachine prefereert er een slecht design?

Verder zijn GIT of Mecurial ook zeker een goede keuze

[reshi]

Bedankt voor je reactie

Had http://git-scm.com/ idd zelf ook gevonden ondertussen en zal kijken naar Mecurial.

We optimaliseren voornamelijk voor Google. Omdat het niet 100% zeker is of het uitmaakt of je gebruikt maakt van absolute url's of relative url's en om het zekere voor het onzekere te nemen kiezen we voor volledige URL's (slecht design?). En inderdaad 99,99% van de tijd maakt het niet zo heel veel uit of je op een subdomein zit. Het URL zal automatisch aangemaakt worden. Ik vroeg me ook alleen af of hoe hier een "simpele" oplossing voor was mbt een ontwikkelomgeving.

[Kettrick]

reshi schreef op maandag 19 juli 2010 @ 13:20:
Bedankt voor je reactie

Had http://git-scm.com/ idd zelf ook gevonden ondertussen en zal kijken naar Mecurial.

We optimaliseren voornamelijk voor Google. Omdat het niet 100% zeker is of het uitmaakt of je gebruikt maakt van absolute url's of relative url's en om het zekere voor het onzekere te nemen kiezen we voor volledige URL's (slecht design?).

Of de keuze goed of slecht is weet niemand, zolang je resultaten goed zijn zou ik er vooral niet aankomen .

En inderdaad 99,99% van de tijd maakt het niet zo heel veel uit of je op een subdomein zit. Het URL zal automatisch aangemaakt worden. Ik vroeg me ook alleen af of hoe hier een "simpele" oplossing voor was mbt een ontwikkelomgeving.

Als je url's meteen goed verwijzen naar de testomgeving is er uberhaubt geen probleem of slecht design, en hoef je helemaal geen oplossing te zoeken

Als je 30 sites bij een hoster hebt staan moet het niet al te ingewikkeld zijn om lokaal een soortgelijke omgeving op te tuigen, 30 vhosts is geen rocketscience

[MueR]

Ik zou beginnen met het laten vallen van de absolute URLs. Die voegen helemaal niets toe, behalve kopzorgen bij een release. Zodra je dat hebt gedaan kan je met wildcard vhosts prima een ontwikkelomgeving maken. Zo hebben wij hier op kantoor een wildcard match op *.dev, wat blind rewrite naar /var/webroot/development/*.

[NMe]

reshi schreef op maandag 19 juli 2010 @ 13:20:
We optimaliseren voornamelijk voor Google. Omdat het niet 100% zeker is of het uitmaakt of je gebruikt maakt van absolute url's of relative url's en om het zekere voor het onzekere te nemen kiezen we voor volledige URL's (slecht design?). En inderdaad 99,99% van de tijd maakt het niet zo heel veel uit of je op een subdomein zit. Het URL zal automatisch aangemaakt worden. Ik vroeg me ook alleen af of hoe hier een "simpele" oplossing voor was mbt een ontwikkelomgeving.

Het spijt me, maar ik heb hier een gigantisch klok-klepel-gevoel bij. Nogmaals, het gebruik van absolute or relatieve urls binnen hetzelfde domein heeft geen enkel effect op Google. En wanneer je buiten je domein zit te morren, dan heb je het probleem dat je hierboven omschreef niet, of desnoods maak je een setting in je config waar je de subdomeinen opslaat zodat je urls in je code zelf nog altijd "relatief" zijn, met een prefix uit je config.

Urls die binnen hetzelfde domein vallen moet je lekker relatief doen.

[reshi]

MueR en NMe bedankt voor jullie reactie. Het wel of niet werken met absolute URL's is jammer genoeg niet aan mij. Laten we die discussie dan ook even achterwegen laten en terug gaan naar de versie beheer en ontwikkelomgevingen.

Subversion en GIT voor het versie beheer (beide bij unfuddle)
en voor de ontwikkelomgeving wordt er veel een vhost voorgesteld.
Moet je hiervoor niet "veel" (l)unix kennis hebben? Zo nee, is het relatief makkelijk om al mijn verschillende configuraties bij mijn verschillende hosts na te bootsen? Dit lijkt me niet echt praktisch, onder andere, omdat als mijn host iets update ik ook weer moet gaan updaten?
Daarom leek mij testen op een test server praktischer. En in beide gevallen zou de database op de ontwikkelomgeving nog voor een gedeelte gesync moeten worden met de database van de live site. Hier heb ik nog geen oplossing voor kunnen vinden.

[Kalentum]

reshi schreef op maandag 19 juli 2010 @ 14:22:
Daarom leek mij testen op een test server praktischer. En in beide gevallen zou de database op de ontwikkelomgeving nog voor een gedeelte gesync moeten worden met de database van de live site. Hier heb ik nog geen oplossing voor kunnen vinden.

Ik zet af en toe een backup van de live database over naar development. Het is toch niet heel erg dat die wat achterloopt qua inhoud? Alleen als de structuur van de database verandert moet je dat natuurlijk wel overnemen.

[NMe]

Jullie keuze voor deze setup maakt het vinden van een geschikte ontwikkelomgeving die je dit werk uit handen neemt onmogelijk. In plaats van de discussie hier van de hand te wijzen zou ik hem als ik jou was juist even aanslingeren bij de persoon die wél die invloed kan uitoefenen. Nogmaals: op deze manier maak je het je onnodig moeilijk, ook in de keuze voor een ontwikkelingsomgeving waarin je snel te werk kan gaan.

[zwippie]

Je kunt ook op je eigen computer virtual machines aanmaken zodat je alle hosting situaties makkelijk kunt nabootsen. Kost je ongeveer 2 tot 4 GB per VM, afhankelijk van de distro en de hoeveelheid extra software.

[MueR]

Tja, als jij een onderdeel van je probleem niet bespreekbaar wil maken dan weet ik niet of we je kunnen helpen. Je gaat altijd met het probleem zitten dat je voor elke release alle absolute urls vanuit je testomgeving moet omzetten naar je live urls. Je bent het jezelf nu ontzettend moeilijk aan het maken.

Je hoeft je configuratie bij de live site toch helemaal niet na te bootsen? Het is Joomla, meer standaard vijfhonderd in een dozijn bestaat haast niet. Een simpele LAMP setup is genoeg om Joomla te draaien, dus dan kan een centrale dev/testserver prima voldoen icm de eerder genoemde wildcard vhost.

Database syncen kan je doen via het alom gerenommeerde phpMyAdmin. Om dat live te syncen is onzinnig en potentieel destructief, dat moet je dus pas doen op het moment dat je aan werkzaamheden gaat beginnen (kopie live > dev) en bij release (dev > live).

offtopic:
Ik zie trouwens ook echt niet in hoe de beslissing om geen absolute URLs te gebruiken niet terug te draaien is, tenzij diegene die de sales doet allerlei verhaaltjes heeft opgehangen die niet kloppen, wat jammer genoeg veel te veel voorkomt.

[reshi]

Kettrick, het zijn 30 verschillende hosts, niet 30 sites bij één host. Hiervoor vhosts maken zou een oplossing kunnen zijn, maar zoals gezegd dit lijkt me erg veel tijd te kosten om deze allemaal bij te houden. Er komen ook steeds meer sites op nieuwe hosts bij. Ja Joomla is generiek 13 in een dozijn. Alles lokaal testen op een machine met één setup lijkt me iets te kort door te bocht? Het lijkt me dat er genoeg fout kan gaan door verschillende php en mysql versies, apache modules die wel of niet aan staan en andere server instellingen als ik de site uiteindelijk van mijn lokale systeem naar de live site kopieer.

NMe: "In plaats van de discussie hier van de hand te wijzen zou ik hem als ik jou was juist even aanslingeren bij de persoon die wél die invloed kan uitoefenen."
Uiteraard wordt dit met de juiste personenen besproken. De absolute URL's kunnen relatief gemaakt worden. Alles kan. Ik ben nu alleen nog op zoek naar een oplossing waarbij dit niet hoeft. Als jullie aangegeven dat het dan onmogelijk wordt om met deze setup een dev omgeving te vinden, dan ga ik daarvan uit en neem ik dat mee in mij zoektocht.

Momenteel test ik een gedeelte (nieuwe sites) op de live server door mijn host betand aan te passen, voordat de site "live" gaat voor de rest van de wereld. Dit werkt netjes voor het www domein. Natuurlijk kan dit niet meer als de site live staat en moet je dus werken met een sub domein. Is hier niet een "trucje" voor om toch je sub domein als een www domein is je browser te kunnen benaderen? We werken vooral op shared hosting accounts met een dedicated IP.

Voor het syncen van de database:
MueR: "(kopie live > dev) en bij release (dev > live)"

Dat is hoe we het nu ook doen( mbv SQLyog), mits er tijdens de dagen dat er gewerkt is op de dev, updates zijn uitgevoerd aan de live site. Dan kan je de dev niet meer kopiëren naar de live site en moet je alle handelingen met de hand gaan overnemen. Daarnaast zal je bij elke aanpassing eerst de database moeten kopiëren (kopie live > dev). Dit is uiteraard een kleine moeite, maar dit zal je dan ook bij kleine aanpassingen die te maken hebben met de database en php bestanden moeten doen om niet alleen de database maar ook de bestanden het zelfde te houden. Dan lijkt het me dat dit onnodig extra veel werk met zich mee brengt? Of zijn dit handelingen die gewoon moeten gebeuren wil je werken met een ontwikkelomgeving?

Ik val misschien over dingen die voor jullie heel logisch zijn/normaal zijn in dit soort situaties. Ik heb er echter geen ervaring mee.

[ Voor 10% gewijzigd door reshi op 20-07-2010 10:34 ]

[Kettrick]

reshi schreef op dinsdag 20 juli 2010 @ 10:27:
Kettrick, het zijn 30 verschillende hosts, niet 30 sites bij één host. Hiervoor vhosts maken zou een oplossing kunnen zijn, maar zoals gezegd dit lijkt me erg veel tijd te kosten om deze allemaal bij te houden. Er komen ook steeds meer sites op nieuwe hosts bij. Ja Joomla is generiek 13 in een dozijn. Alles lokaal testen op een machine met één setup lijkt me iets te kort door te bocht? Het lijkt me dat er genoeg fout kan gaan door verschillende php en mysql versies, apache modules die wel of niet aan staan en andere server instellingen als ik de site uiteindelijk van mijn lokale systeem naar de live site kopieer.

Zie hier de reden om je klanten zo veel mogelijk bij één partij ( of nog liever, bij jezelf ) te hosten. Als je inderdaad met 30 verschillende configuraties te maken hebt wordt het allemaal wat ingewikkelder.

Je kan echter zonder problemen verschillende mysql versies installeren, en eventueel per vhost een eigen php.ini neerzetten welke overeenkomt met de specifieke host. Het is wat gekloot, maar dat is de prijs die je betaald voor niet verspreiden van je sites over 30 hosts

NMe: "In plaats van de discussie hier van de hand te wijzen zou ik hem als ik jou was juist even aanslingeren bij de persoon die wél die invloed kan uitoefenen."
Uiteraard wordt dit met heb besproken. De absolute URL's kunnen relatief gemaakt worden. Alles kan. Ik ben nu alleen nog op zoek naar een oplossing waarbij dit niet hoeft. Als jullie aangegeven dat het dan onmogelijk wordt om met deze setup een dev omgeving te vinden, dan ga ik daarvan uit en neem ik dat mee in mij zoektocht.

Als je zorgt dat je je absolute URL's in je templates opbouwt a.d.h.v. de hostname is er niets aan de hand, in je HTML staan gewoon absolute paden en op dev verwijzen ze gewoon naar dev, opgelost

Voor het syncen van de database:
MueR: "(kopie live > dev) en bij release (dev > live)"

Dat is hoe we het nu ook doen( mbv SQLyog), mits er tijdens de dagen dat er gewerkt is op de dev, updates zijn uitgevoerd aan de live site. Dan kan je de dev niet meer kopiëren naar de live site en moet je alle handelingen met de hand gaan overnemen. Daarnaast zal je bij elke aanpassing eerst de database moeten kopiëren (kopie live > dev). Dit is uiteraard een kleine moeite, maar dit zal je dan ook bij kleine aanpassingen die te maken hebben met de database en php bestanden moeten doen om niet alleen de database maar ook de bestanden het zelfde te houden. Dan lijkt het me dat dit onnodig extra veel werk met zich mee brengt? Of zijn dit handelingen die gewoon moeten gebeuren wil je werken met een ontwikkelomgeving?

Ik val misschien over dingen die voor jullie heel logisch zijn/normaal zijn in dit soort situaties. Ik heb er echter geen ervaring mee.

Je zou hier wat omheen kunnen scripten en hopen dat je versiebeheer de juiste changes voor je merged, maar die blijft altijd een lastig punt. Het liefst zie je helemaal geen changes op de live site tot je je release doet, maar dat is natuurlijk lang niet altijd mogelijk .

Het is iig. een probleem waar iedereen mee te maken heeft, je zal er dus goed over na moeten denken en een werkwijze moeten vinden die binnen jullie organisatie en team past

[Kalentum]

reshi schreef op dinsdag 20 juli 2010 @ 10:27:
Voor het syncen van de database:
MueR: "(kopie live > dev) en bij release (dev > live)"

Dat is hoe we het nu ook doen( mbv SQLyog), mits er tijdens de dagen dat er gewerkt is op de dev, updates zijn uitgevoerd aan de live site. Dan kan je de dev niet meer kopiëren naar de live site en moet je alle handelingen met de hand gaan overnemen. Daarnaast zal je bij elke aanpassing eerst de database moeten kopiëren (kopie live > dev). Dit is uiteraard een kleine moeite, maar dit zal je dan ook bij kleine aanpassingen die te maken hebben met de database en php bestanden moeten doen om niet alleen de database maar ook de bestanden het zelfde te houden. Dan lijkt het me dat dit onnodig extra veel werk met zich mee brengt? Of zijn dit handelingen die gewoon moeten gebeuren wil je werken met een ontwikkelomgeving?

Kopieren van live naar dev is nooit een probleem. Kopieren van dev naar live kan best gevaarlijk zijn. Er kan nog testdata aanwezig zijn, een tabelletje wat je achteraf niet nodig had. Ik zou dat niet doen.

Databasewijzingen horen ook in je versiebeheersysteem. Voor databasewijzigen gebruik ik een migration tooltje voor: http://code.google.com/p/mysql-php-migrations/. Hiermee kun je bij een release alle nodige databasewijzigingen op de live database uitvoeren.

je zou ook nog kunnen kijken naar een tool die de verschillen tussen twee databases voor je op een rijtje zet. BV Toad for Mysql kan je hierbij helpen (misschien SQL Yog ook?). Door te vergelijken tussen je live database en je development database zie je precies welke tabellen gewijzigd zijn en ook krijg je SQL code erbij om je live database gelijk te maken aan je dev database.

[djc]

reshi schreef op maandag 19 juli 2010 @ 14:22:
Subversion en GIT voor het versie beheer (beide bij unfuddle)

Ik zou eerder voor Mercurial + TortoiseHG gaan, is denk ik een stuk behapbaarder als je weinig ervaring hebt met version control.

[reshi]

Toad for Mysql klinkt als een oplossing en ervoor zorgen dat alle URL's "dynamisch absolute" zijn, omdat het anders redelijk onmogelijk wordt.

Ik vraag me toch af hoe de grotere website boeren dit doen? Die moeten toch ook tegen het probleem aanlopen waarbij de live site aangepast wordt terwijl er aan de dev site gesleuteld wordt?

[mulder]

Je live site (=instantie van je code) en je dev site (moeten kunnen) weten op welk domain ze draaien (configuratiebestand oid, dynamisch bepalen). Dan kun je, op het moment dat de pagina gegenereerd wordt, domain + url doen. In dat zelfde configuratiebestand staat welke database gebruikt moet worden. Bijvoorbeeld.

[MueR]

reshi schreef op woensdag 21 juli 2010 @ 16:08:
Ik vraag me toch af hoe de grotere website boeren dit doen? Die moeten toch ook tegen het probleem aanlopen waarbij de live site aangepast wordt terwijl er aan de dev site gesleuteld wordt?

Dat probleem heb je ja. Je kopieert daarom nooit klakkeloos de complete database. Nieuwe tabellen kan je wel in het geheel overzetten, bij wijzigingen in tabellen voer je de juiste alter queries uit, verder los je het op met een upgrade script. Zo enorm moeilijk is het niet.

[rewind.]

Misschien kun jeje hosts file misbruiken om te redirecten van www naar dev?

[reshi]

rewind. schreef op woensdag 21 juli 2010 @ 17:02:
Misschien kun jeje hosts file misbruiken om te redirecten van www naar dev?

Dat heb ik al geprobeerd uit te zoeken, maar daar kwam ik niet uit. Ook al hier en daar gevraagd, maar kreeg dan altijd het antwoord dat het Host betand daarvoor niet bedoeld is. Het kan alleen maar van IP naar domein en niets anders.

Misschien dat iemand anders op Tweakers hier een ander idee over heeft?

[Kalentum]

Die hostfile oplossing zou ik sowieso niet doen. Je moet er dan de hele tijd aan denken dat je die host-file weer moet omzetten als je wel een keer op de live versie van een site moet kijken. Dan rapporteert een klant een probleem en dan kan jij dat niet vinden omdat je host-file naar je developmentmachine verwijst.

Wat ik op dit moment doe is op basis van de http-host ($_SERVER['HTTP_HOST'] in PHP) detecteren in welke omgeving ik zit. Afhankelijk daarvan wordt dan een configuratie gekozen.

Een simpeler alternatief is door middel van een Environment variabele. In je Apache configuratie (bv .htaccess) zet je "SetEnv APPLICATION_ENV development". Deze waarde kun je dan in php uitlezen met getenv(). En op basis daarvan weet je applicatie welke configuratie geladen moet worden.

Wat je moet voorkomen is dat je bij een release van een nieuwe versie eerst nog allerlei configuratie handmatig moet wijzigen.

[reshi]

rutgerw schreef op donderdag 22 juli 2010 @ 09:23:
Die hostfile oplossing zou ik sowieso niet doen.

Heb jij een oplossing voor het geen wat ik zoek dan? Momenteel gebruik ik het alleen bij het maken van een nieuwe website voor een domein waar nog niks op staat. Hier heb ik dan ook geen dev omgeving voor, ik maar gewoon de website op de plek waar hij uiteindelijk moet komen, afgeschermd met een .htaccess file.

[Kalentum]

In dit topic staan toch al een aantal suggesties?

[roy-t]

Voor een SVN variant kan ik je visual svn aanraden (niets met MS te maken). Dat is gewoon 1,2,3, hoppa en je hebt een SVN repository draaiend op een server .

[reshi]

rutgerw schreef op maandag 26 juli 2010 @ 16:12:
In dit topic staan toch al een aantal suggesties?

Ik bedoelde een oplossing om mijn pc/browser te laten denken dat www.mijndomein.nl eigenlijk dev.mijndomein.nl is, zodat ik op deze manier mijn absolute URL "probleem" voor een gedeelte oplos.

[r0bert]

Webserver met network-shared userhome/www als userdirs. In je network-share fijn devven. Gitten mbv github.com of gitolite op server installeren (m.n. certificaten instellen), alleen wel de vraag is of je Joomla zelf dan als submodule kan instellen (zou wel erg handig zijn).

Op de webserver kun je dan naast de userdirs wat virtualhosts instellen per client en verschillende omgevingen daarbinnen (dev, acceptatie, live, ..).

[Rutix]

Wacht even hoor. Ik begrijp dat je aan 30 sites werkt en dat je een ontwikkelomgeving wilt zodat er nog iemand aan kan werken. Verder hoor ik dingen over 30 verschillende hosts enzo. Hoe doe je het nu dan? Je gaat me toch niet vertellen dat als je werkt aan een site dat je inlogt op die host? Zo niet dan is het toch geen probleem om een centrale webserver op te zetten.