van maken, testen tot live

[Verwijderd]

Hallo allemaal,

Ik ben gevraagd om voor een sportvereniging de website aan te passen. De huidige is zwaar verouderd vandaar dat ze een nieuwe willen hebben.

Thuis ben ik aan het experimenteren met Joomla. Het werkt nog niet helemaal zoals het hoort, maar dat zal wel aan mij liggen.
Wanneeer het toch allemaal is gelukt met mijn "de nieuwe" website, deze draait nu op een virtual machine, wil ik dit allemaal uploaden naar de desbetreffende hostingpartner en voila iedereen kan het bewonderen.

Klinkt natuurlijk allemaal makkelijker dan het is.

Weet iemand hoe ik dit het beste kan aanpakken? Dus thuis alles maken, testen, testen bij de hosting provider en uiteindelijk live.

Alvast bedankt

[MueR]

Klinkt goed.

[NMe]

Ik zou niet weten wat je aan dat proces zou kunnen veranderen tenzij je (bijvoorbeeld) de hele testfase eruit zou willen slopen. Waarom denk je dat het proces dat je verzonnen hebt niet goed zou zijn?

[- J.W. -]

Ik heb er niet echt ervaring mee , maar wat ik zou doen is de oude website kopieren naar bijv. www.website.nl/old/, /old testen, dan www.website.nl/ laten redirecten naar www.website.nl/old/ (zonder /old te laten zien natuurlijk), dan nieuwe site op www.website.nl, lekker uitproberen en als alles als een zonnetje werkt de redirect weghalen.

't Voordeel is dat de site geen seconde down gaat door de migratie.

[ Voor 31% gewijzigd door - J.W. - op 21-04-2009 15:13 ]

[Verwijderd]

Alvast bedankt voor de reacties!

Waar ik me juist zorgen over maak is de database. Waar moet ik allemaal opletten. Hoe moet ik mijn virtual machine configureren, zodat ik dadelijk probleemloos live kan gaan.

[NMe]

Ehm...hetzelfde als je live server misschien?

[soulrider]

- J.W. - schreef op dinsdag 21 april 2009 @ 15:03:
Ik heb er niet echt ervaring mee , maar wat ik zou doen is de oude website kopieren naar bijv. www.website.nl/old/, /old testen, dan www.website.nl/ laten redirecten naar www.website.nl/old/ (zonder /old te laten zien natuurlijk), dan nieuwe site op www.website.nl, lekker uitproberen en als alles als een zonnetje werkt de redirect weghalen.

't Voordeel is dat de site geen seconde down gaat door de migratie.

dan moet je wel even die redirect weghalen, anders lukt dat niet natuurlijk.
(en dan heb je direct alle bezoekers op je nieuwe nog te testen site)

en waarom zou je die oude site naar /old gaan verhuizen en testen (en dus mogelijk breken) - en nog gebruiken eenmaal verhuist - als jij de code/design niet zelf geschreven hebt - dat is vragen voor problemen - bij statische html met enkele relatieve links kan je zo van map verhuizen, maar bij al de rest ben je toch net wat langer bezig - maar ondertussen is er geen enkele site bruikbaar.
(of je doet het iets veiliger: copy, test, redirect, delete)
zolang die oude nog werkt: afblijven en de nieuwe waar je alles van weet in een folder plaatsen en dan kan je achteraf oud en nieuw verwisselen of een redirect maken van root naar folder van nieuwe versie.
(ik ken verschillende site's waar er op de achtergrond telkens een /vx.y-folder wordt toegepast zodra er meer wordt aangepast dan een design template)

[- J.W. -]

soulrider schreef op dinsdag 21 april 2009 @ 15:30:
[...]

dan moet je wel even die redirect weghalen, anders lukt dat niet natuurlijk.
(en dan heb je direct alle bezoekers op je nieuwe nog te testen site)

Ik begrijp je even niet...

Misschien heb ik het wat wazig opgeschreven ook , poging 2:

stages:
1. oude site
2. oude site, kopie oude site maken [bezoekers naar oude site]
3. kopie oude site testen [bezoekers naar oude site]
4. redirect naar kopie maken [-> bezoekers naar kopie]
5. oude site weg [bezoekers naar kopie]
6. nieuwe site er op [bezoekers naar kopie]
7. nieuwe site testen [bezoekers naar kopie]
8. redirect weghalen [bezoekers naar nieuwe site]

en waarom zou je die oude site naar /old gaan verhuizen en testen (en dus mogelijk breken) - en nog gebruiken eenmaal verhuist - als jij de code/design niet zelf geschreven hebt - dat is vragen voor problemen - bij statische html met enkele relatieve links kan je zo van map verhuizen, maar bij al de rest ben je toch net wat langer bezig - maar ondertussen is er geen enkele site bruikbaar.

Ik ga er idd vanuit dat er netjes met relatieve links gewerkt wordt... , anders is het een slecht idee.

zolang die oude nog werkt: afblijven en de nieuwe waar je alles van weet in een folder plaatsen en dan kan je achteraf oud en nieuw verwisselen of een redirect maken van root naar folder van nieuwe versie.

Daar is ook wat voor te zeggen..

[Cartman!]

Gewoon de nieuwe zetten op domein.nl/staging/ bijvoorbeeld en daar alles controleren. Als blijkt dat alles werkt backup je even de oude site (die daarna dus niet meer hoeft te werken imo, je hebt immers een nieuwe). Dan plaats je een kopie van staging op je liveurl (domein.n) en zet je daarin error_reporting uit en pas je evt. nog settings aan zodat ie werkt. Als je in de toekomst nog wijzigingen doet voer je dit eerst uit op de staging om te checken of alles blijft werken. Zoja, dan push je de wijziging door naar live.

[Mad Marty]

- J.W. - schreef op dinsdag 21 april 2009 @ 15:44:
[...]

Ik begrijp je even niet...

Misschien heb ik het wat wazig opgeschreven ook , poging 2:

stages:
1. oude site
2. oude site, kopie oude site maken [bezoekers naar oude site]
3. kopie oude site testen [bezoekers naar oude site]
4. redirect naar kopie maken [-> bezoekers naar kopie]
5. oude site weg [bezoekers naar kopie]
6. nieuwe site er op [bezoekers naar kopie]
7. nieuwe site testen [bezoekers naar kopie]
8. redirect weghalen [bezoekers naar nieuwe site]


[...]

Als je nu je nieuwe site wil testen op www.site.nl wordt je natuurlijk geredirect naar de oude site

Waarom zou je inderdaad je oude site helemaal moeilijk in een subdir zetten, met de kans dat iets niet helemaal lekker werkt (en je dat eerst weer moet gaan verhelpen) als je ook gewoon je nieuwe in een subdir kan zetten en dan zelf naar www.site.nl/subdir surfen? (zoals Cartman zegt dus)

[Svennetjee]

Ikzelf maak gewoon altijd een subdomein in de trant van dev.[webadres].nl, of new.[webadres].nl.. Kun je gewoon in testen en met bijv. .htaccess scherm je de boel af voor iedereen behalve de ontwikkelaars..

[- J.W. -]

Mad Marty schreef op dinsdag 21 april 2009 @ 16:19:
[...]


Als je nu je nieuwe site wil testen op www.site.nl wordt je natuurlijk geredirect naar de oude site

niet als je hem bij het bestand aanspreekt natuurlijk... bijv. www.site.nl/main.php oid.

Waarom zou je inderdaad je oude site helemaal moeilijk in een subdir zetten, met de kans dat iets niet helemaal lekker werkt (en je dat eerst weer moet gaan verhelpen) als je ook gewoon je nieuwe in een subdir kan zetten en dan zelf naar www.site.nl/subdir surfen? (zoals Cartman zegt dus)

ja idd.. betere optie misschien. Nadeeltje is dat je de nieuwe site niet kan testen op www.site.nl, maar alleen op de subdir.

[Verwijderd]

Iedereen heeft het nu over een soort sub-domein. Nu ben ik bezig met hetgeen te maken op een virtualmachine. Is dat slim of zonde van het werk?

En hoe kan ik de database kopieren van de virtualmachine kopieeren naar de liveomgeving?

[DJF5]

Wat ik altijd doe is de oude site laten zoals deze is en een nieuwe beginnen op mijn virtuele machine. De database kloon ik of ik schrijf hem opnieuw. Uiteinderlijk die database er dus naast (nieuwe db naam) live zetten.

Voor ontwikkelen verwijs ik in mijn hosts file de domeinnaam niet naar de live server maar naar mijn virtuele bak. Daardoor lijkt het alsof je het gewoon live aan het maken bent. Daarna overkopieren, klaar!

* mits je natuurlijk dezelfde specs hebt op je virtuele als je live bak (denk aan php extensies, database versies, sql schema's, enzo )

[soulrider]

- J.W. - schreef op dinsdag 21 april 2009 @ 15:44:
[...]

Ik begrijp je even niet...

Misschien heb ik het wat wazig opgeschreven ook , poging 2:

stages:
1. oude site
2. oude site, kopie oude site maken [bezoekers naar oude site]
3. kopie oude site testen [bezoekers naar oude site]
4. redirect naar kopie maken [-> bezoekers naar kopie]
5. oude site weg [bezoekers naar kopie]
6. nieuwe site er op [bezoekers naar kopie]
7. nieuwe site testen [bezoekers naar kopie]
8. redirect weghalen [bezoekers naar nieuwe site]

[...]

ik had hem juist begrepen maar jouw fout zit in stap 4 tem 7:
zolang je een redirect hebt alle verkeer van / naar bv /old (wat jij doet in stap 4)
dan geraak je toch niet aan de nieuwe site in de root-folder / ? (want je redirect alles naar /old ...)
dus als je dan wilt gaan testen moet je de redirect weghalen voordat je ook maar een de nieuwe site in de root-folder geraakt. en dan is de site onmiddellijk live want ook de bezoekers komen er op terecht.
daar zit - volgens mij - de denk fout in je 'move oude site naar /old, redirect verkeer naar /old, zwier nieuwe site in rootfolder, test, en verwijder de redirect'.

maw: zie cartman and mad marty hun reactie's en aanvulling/voorstellen

en als je je redirect correct uitvoert (met een .htaccess rewrite zodat een tussentijdse bezoeker er niets van merkt) dan zijn ook de bestanden niet rechtstreeks aanspreekbaar hoor.
(of ga je een een '30x tijdelijk verhuisd' doen voor de oude site - maar dan moet je dat ook voor elke bestand doen, want zodra je op folder niveau werkt zit je weer met hetzelfde probleem als met de rewrite)

en je kan met een virtuele server/usb-server werken voor ontwikkeling, en zodra die 'uit alfa' is verhuis je naar de live server, laat je testen door x-tal personen van de vereniging en dan ga je pas oud met nieuw wisselen mbv backup, delete, copy actie's.
de data van elke database is exporteerbaar en terug importeerbaar. eventueel moet je eventueel converteren als je met verschillende servers werkt.
wederom: zie bovenbuur

[Verwijderd]

aha het balletje begint langzaam te vallen. Eerlijk gezegd heb ik er nog net op gezocht, maar kun je een export maken van alle joomla instellingen die ik heb gemaakt? En deze uiteraard ook weer importeren in de live omgeving?

[- J.W. -]

soulrider schreef op dinsdag 21 april 2009 @ 20:00:
[...]

ik had hem juist begrepen maar jouw fout zit in stap 4 tem 7:
zolang je een redirect hebt alle verkeer van / naar bv /old (wat jij doet in stap 4)
dan geraak je toch niet aan de nieuwe site in de root-folder / ? (want je redirect alles naar /old ...)

Ah, ik begrijp waar de vewarring is ontstaan

We hadden een ander soort redirect in gedachten:
Ik dacht aan het volgende:
Als je een adres intikt wordt altijd een bepaald bestand aangeroepen en gedraaid, vaak index.php oid. Ik wilde die index.php vervangen door een scriptje die de gebruiker doorstuurt naar /old
Als je dan van de nieuwe site index2.php oid als start-up neemt, kun je die direct aanroepen om de nieuwe site te testen (i.e. www.website.nl/index2.php in de browser stoppen).
[ik dacht dat dat een 'standaard' redirect was ]

[ Voor 3% gewijzigd door - J.W. - op 21-04-2009 22:40 ]

[soulrider]

Verwijderd schreef op dinsdag 21 april 2009 @ 20:46:
aha het balletje begint langzaam te vallen. Eerlijk gezegd heb ik er nog net op gezocht, maar kun je een export maken van alle joomla instellingen die ik heb gemaakt? En deze uiteraard ook weer importeren in de live omgeving?

ik ken joomla niet uit praktijk ervaring, maar meeste cms'en slaan hun basis-instellingen (database gegevens en admin login enzo) op in een config.php bestand en de rest (gebruikers, posts, wel of niet geactiveerde extra's,...) in de database - en die draait dan vaak op mysql ofzo.
de config.php/settings.php kan je copieren naar of aanpassen naar de echte server en die sql-data kan je gewoon exporteren - kolommen en data - via mysqladmin/admin-front op je test/ontwikkel server, en nadien importeren op je live server. export database/table(s)/... als .sql/.txt en op live server: import ....

@J.M: als je via een index.php werkt die alles tevoorschijn tovert uit (een) data/template/...-map(-pen) dan kan je inderdaad met wat aanpassingen in die index.php de data uit een andere map laten halen, maar dan werk je wellicht al met een htaccess-rewrite die alles via die index.php stuurt of al met eem cms
en wederom: dan moet je (volgens mij in het geval van de TS) in de code van de oude site duiken en werken aan code die je niet (volledig) kent. waardoor dan mogelijk enkele onderdelen niet direct zonder problemen direct gaan werken. (bv het automatisch ergens invoegen van een stylesheet/javascript/foto die uit de verkeerde folder wordt opgehaald)
maar je zou dan inderdaad via een index2.php of new.php kunnen werken voor de nieuwe versie.
(maar een aparte map die je dan afschermd met een gebruikersnaam en wachtwoord - .htaccess en .htusers - gedurende het testen en aanpassen op de live server lijkt me iets meer voor de hand liggend.)

Keuze blijft natuurlijk aan TS hoe die het gaat doen zodra ie de ontwikkelde nieuwe site naar de server gaat verhuizen. enig onderzoek hoe de oude site nu draait is misschien wel aan te raden om zo te weten wat de meest aan te raden oplossing is om de nieuwe site ook op die server/hosting te krijgen - (tijdelijk) draaiend naast de oude site zonder dat die in elkaars weg zitten. (subdomein, andere folder, ...)