GIT branch deployen naar Apache server

[Storm90]

Ik ben opzoek naar een goede oplossing om mijn master branch op GIT te deployen naar de server, waar de uiteindelijke website op draait. Ik heb al een aantal oplossingen gevonden op internet:

- git-ftp: https://github.com/git-ftp/git-ftp
- deployhq: https://www.deployhq.com/
- ftploy: https://ftploy.com/

Gezien deze oplossingen me vrij nieuw lijken, vraag ik me toch af wat men deed vóór deze oplossingen waren "uitgevonden". GIT op de server installeren waar de website op draait en pullen?

Een oplossing als git-ftp lijkt me absoluut niet verkeerd, maar als er een (oudere) betere oplossing te vinden is, zou ik hier graag van op de hoogte zijn

Dus iemand die hier GIT gebruikt voor het versiebeheer van zijn/haar website en een Apache server waar de website op draait? Zo ja, wat voor oplossing gebruiken jullie hiervoor?

[azerty]

Ik ben hier toevallig vorige week mee bezig geweest voor mijn hobbyprojecten, en ik heb dit gebruikt:

http://jonathannicol.com/...ployments-from-bitbucket/

Je kunt op bitbucket (ik weet niet waar jij je code naartoe versluist, maar in elk geval GitHub heeft gelijkaardige features) een deploy hook toevoegen, die dan een script aanroept dat op je server een branch binnenhaalt en je site bijwerkt. Werkt vrij goed bij mij

[Soultaker]

Inderdaad Git op de server zetten, en post-receive hook configureren die een checkout doet naar de gewenste directory, en dan gewoon pushen naar de server om te deployen.

[Storm90]

Bedankt voor jullie reactie! Ik zal meteen even naar je link kijken, @wsitedesign ;)!!
Het nadeel van deployhq en ftploy is dat ze al gauw geld vragen om vaker te deployen. Dan lijkt me zo'n script nog niet zo'n slecht idee!

[Nvidiot]

Ik ben zelf veel meer voorstander van het bouwen van een nette package en die dan deployen in plaats van direct met git naar de server te pushen.

[Storm90]

Nvidiot schreef op donderdag 16 april 2015 @ 21:54:
Ik ben zelf veel meer voorstander van het bouwen van een nette package en die dan deployen in plaats van direct met git naar de server te pushen.

Maar wat versta jij dan onder "het bouwen van een nette package"? We willen de gebruikers zo min mogelijk belasten en dus willen we kleine wijzigingen zo snel mogelijk online zetten op het moment dat er weinig/geen gebruikers op de website zijn. Alle bestanden opnieuw uploaden duurt te lang en is vrij overbodig als nog geen 1% van alle bestanden is gewijzigd, dan upload je toch liever slechts de aangepaste bestanden. Maar handmatig is weer te foutgevoelig... Dus ik zoek juist een automatisch systeem die slechts de aangepaste bestanden upload.

[Nvidiot]

Het gaat mij om het voorkomen van dit probleem:
Vrijdagmiddag commit: "Partial rewrite of website, page XYZ still broken"

Maandag: "Ah ja, ik zou de website nog updaten" -> git push. Ai. Toen was de site stuk.

Bij het bouwen van een package (kan zo simpel zijn als het doen van een 'git archive') forceert het mij om weer even na te denken "ok, een release. Even opletten, was master in een deploybare staat?".

[azerty]

Nvidiot schreef op donderdag 16 april 2015 @ 22:01:
Het gaat mij om het voorkomen van dit probleem:
Vrijdagmiddag commit: "Partial rewrite of website, page XYZ still broken"

Maandag: "Ah ja, ik zou de website nog updaten" -> git push. Ai. Toen was de site stuk.

Bij het bouwen van een package (kan zo simpel zijn als het doen van een 'git archive') forceert het mij om weer even na te denken "ok, een release. Even opletten, was master in een deploybare staat?".

Dat is perfect op te lossen door een "production" branch te gebruiken waar je enkel naar pusht als je klaar bent met je wijzigingen en je getest hebt... Ik heb er zo zelfs onmiddelijk nog een QA branch bijgemaakt, die live op een subdomein draait, zo kan ik mijn code na het ontwikkelen eerst nog eens "live" testen voor ik het in productie gooi

[ Voor 6% gewijzigd door azerty op 16-04-2015 22:27 ]

[Ramon]

Wat wij doen is een checkout in een directory met als naam de hash van de meest recente commit. We verwijzen dan met een symlink naar die hash. Als we een nieuwe versie live zetten maken we een nieuwe directory met de laatste hash (alles geautomatiseerd natuurlijk), zetten daar alle code in, doen nog wat huishoudelijk werk (eventuele migraties e.d.) en als dat klaar is veranderen we de symlink naar de nieuwe hash. Dit alles resulteert in nog geen seconde downtime terwijl er wel een compleet nieuwe en schone website staat (geen .pyc bestanden meer enzo). Plus, je kan makkelijk terug naar vorige versies, mocht dat nodig zijn.

[ Voor 6% gewijzigd door Ramon op 16-04-2015 22:08 ]

[Barryvdh]

Ik gebruik Rocketeer: https://github.com/rocketeers/rocketeer
CommandLine tool die grofweg hetzelfde doet als wat hierboven staat, maar dan automatisch.
dus git pull naar nieuwe release map, composer install en andere tasks uitvoeren, dan symlink naar nieuwste release verwijzen.

[Storm90]

wsitedesign schreef op donderdag 16 april 2015 @ 22:05:
[...]


Dat is perfect op te lossen door een "production" branch te gebruiken waar je enkel naar pusht als je klaar bent met je wijzigingen en je getest hebt... Ik heb er zo zelfs onmiddelijk nog een QA branch bijgemakt, die live op een subdomein draait

Exact, wij maken gebruik van de gitflow, dus slechts de nieuwe releases van development (welke zijn getest op de development omgeving) worden met de master gemerged. Dit geldt uiteraard niet voor hotfixes, deze worden direct met de master branch gemerged. Overigens ook pas nadat deze hotfix lokaal getest is.

[SlaadjeBla]

Nvidiot schreef op donderdag 16 april 2015 @ 22:01:
Even opletten, was master in een deploybare staat?".

Afhankelijk van wat jij met master bedoelt zou deze altijd in een opleverbare staat moeten zijn. Op ieder moment. Master = production.

[Storm90]

Ramon schreef op donderdag 16 april 2015 @ 22:07:
Wat wij doen is een checkout in een directory met als naam de hash van de meest recente commit. We verwijzen dan met een symlink naar die hash. Als we een nieuwe versie live zetten maken we een nieuwe directory met de laatste hash (alles geautomatiseerd natuurlijk), zetten daar alle code in, doen nog wat huishoudelijk werk (eventuele migraties e.d.) en als dat klaar is veranderen we de symlink naar de nieuwe hash. Dit alles resulteert in nog geen seconde downtime terwijl er wel een compleet nieuwe en schone website staat (geen .pyc bestanden meer enzo). Plus, je kan makkelijk terug naar vorige versies, mocht dat nodig zijn.

Nice, klinkt als een erg nette oplossing! En erg snel rollbacken indien nodig, eigenlijk precies wat ik zoek. Hebben jullie ook een dergelijke oplossing voor de database? Ik zou me kunnen voorstellen dat je met een nieuwe release een aanpassing doet in de database, welke ook gevolgen kan hebben op de werking van een vorige versie.

Ik gebruik Rocketeer: https://github.com/rocketeers/rocketeer
CommandLine tool die grofweg hetzelfde doet als wat hierboven staat, maar dan automatisch.
dus git pull naar nieuwe release map, composer install en andere tasks uitvoeren, dan symlink naar nieuwste release verwijzen.

En wat is je ervaring tot dusver? Goed? Want dan wil ik dit wel gaan overwegen, functies als zelf deployen via de command line (doen we bij een NodeJS project namelijk ook al), rollbacken, huidige versie tonen, testen runnen e.d. bevallen me wel

[Barryvdh]

Bevalt mij goed ja. Configuratie is eventjes zoeken in het begin maar verder top.
Is van origine wel beetje op Laravel georiënteerd, met composer, database migraties en standaard shared folders enzo, maar kan ook prima voor andere projecten.
inderdaad ook snel rollbacken enzo. Voor database wijzigingen gebruiken wij de standaard laravel migrations.

[Storm90]

Barryvdh schreef op donderdag 16 april 2015 @ 22:59:
Bevalt mij goed ja. Configuratie is eventjes zoeken in het begin maar verder top.
Is van origine wel beetje op Laravel georiënteerd, met composer, database migraties en standaard shared folders enzo, maar kan ook prima voor andere projecten.
inderdaad ook snel rollbacken enzo. Voor database wijzigingen gebruiken wij de standaard laravel migrations.

Alright! Good to know. Het project waar ik het voor wil gebruiken is gebaseerd op Zend. Helaas hebben zij geen mogelijkheid tot migrations voor db wijzigingen, maar daar heb ik volgens mij al iets op gevonden: http://akrabat.com/akraba...work-database-migrations/

Ik ga dat Rocketeer eens proberen! Ben erg nieuwsgierig.

[Ramon]

Storm90 schreef op donderdag 16 april 2015 @ 22:45:
[...]


Nice, klinkt als een erg nette oplossing! En erg snel rollbacken indien nodig, eigenlijk precies wat ik zoek. Hebben jullie ook een dergelijke oplossing voor de database? Ik zou me kunnen voorstellen dat je met een nieuwe release een aanpassing doet in de database, welke ook gevolgen kan hebben op de werking van een vorige versie.


[...]

Er wordt (wederom automatisch) een backup gemaakt, en de migraties worden gedraaid. Als je een rollback doet dan wordt dus de gebackupte database teruggezet. Een rollback is dus bedoeld voor dat ene "oh shit nee toch niet goed" momentje na een deploy, en niet om een dag of wat later alsnog naar een vorige versie te gaan, want je weet niet wat de klant in de tussentijd heeft aangepast.

[ Voor 15% gewijzigd door Ramon op 16-04-2015 23:39 ]

[Vinnienerd]

Oplossing is om niet op vrijdag naar production the pushen.

[Storm90]

Er wordt (wederom automatisch) een backup gemaakt, en de migraties worden gedraaid. Als je een rollback doet dan wordt dus de gebackupte database teruggezet. Een rollback is dus bedoeld voor dat ene "oh shit nee toch niet goed" momentje na een deploy, en niet om een dag of wat later alsnog naar een vorige versie te gaan, want je weet niet wat de klant in de tussentijd heeft aangepast.

Ja duidelijk. Het is ook niet de bedoeling een rollback van de database uit te voeren op het moment dat het alweer nieuwe data bevat, nietwaar

Oplossing is om niet op vrijdag naar production the pushen.

Ach, als je het niet erg vindt om in het weekend te werken is dat geen probleem toch XD

[harrald]

Wij hebben een master branch waar alleen wijzigingen in worden gemerged die goed zijn bevonden voor productie. Vervolgens word er na de merge een versie nummer toegewezen (git tag).

Dan met ssh naar productie en na git fetch te hebben gedaan kan je gewoon de nieuwe versie uitchecken.

Al blijkt nou dat er om wat voor reden dan ook toch een foutje aanwezig was in deze nieuwe versie dan is het enkel het vorige versie nummer uitchecken en er is weer een werkende website alsof er nooit wat is gebeurd.

Dat gezegd hebbende klinkt de manier van Ramon wat robuuster. Soms heb je toch wat meer dingen te doen omdat je ook niet letterlijk alles in git wilt zetten. Of er moeten nog mappen schrijfbaar worden gemaakt of symlinks geplaats of whatever.

Welke manier je ook kiest. De mogelijkheid om vrijwel instant terug te keren naar een bewezen werkende situatie geeft zoveel rust.

[edit] oh en inderdaad nooit iets live zetten op een vrijdag

[ Voor 3% gewijzigd door harrald op 18-04-2015 18:08 ]

[_Erikje_]

Misschien is het verstandig om Jenkins of vergelijkbaar tussen je GiT commit en je deploy te stoppen.

Je commit en pusht naar je branch
Jenkins pikt de nieuwe revisie automatisch op
Jenkins bouwt alles en doet controles (jshint, csslint ...)
Jenkins deployed alleen als het aan je standaarden voldoet.

Hierdoor heb je grotere zekerheid dat hetgeen dat je naar productie pusht, goed functioneert. Ook is het op deze manier gemakkelijk om je testomgeving, klant acceptatie omgeving ook te beheren.