[PHP - Laravel] Simpele deployment van een cms skeleton

[afraca]

Ik zie door de bomen het bos niet meer. Vergeef me mijn onwetendheid, ik ben primair een comp-sci student, en werk ernaast als php programmeur, dus ik ben nog niet helemaal op de hoogte van de beste oplossingen voor deployment van dingen. Als volgt:

Als je een Laravel site wilt bouwen gebruik je (mogelijk):

code:

composer create-project laravel/laravel {directory} 4.2 --prefer-dist

Een vrij eenvoudige manier om een skeleton binnen te krijgen. Op m'n werk hebben we nu een soort "enhanced" skeleton, waar we een aparte map hebben waar wat CMS controllers/models/spul in staat. In de composer.json van die skeleton zijn autoload instellingen aangepast, in de global.php van Laravel registreren we bijv. view namespaces enzo,. Dan hebben we dus een soort niet-composer-package maar wel CMS waarmee je aan de slag kan. Dit alles staat in een private Github repository.

Momenteel is het oude "CMS" een paar bestanden die via ftp naar een bepaalde server gekopieerd wordt, men voegt wat site-specifieke php bestanden toe, en editen doen we gewoon lekker op de live server. Versie-beheer is er nog niet, enz. Als er van het "cms" wat veranderd word, dan betekent dat handmatig kopiëren naar alles. Daarnaast zijn m'n collega's beperkt vaardig met de command line, veel gaat via DirectAdmin.

Nu willen we het anders doen. Het moet meer in lijn met betrouwbaardere gebruiken. Ik ken vaag wat buzzwords van de nieuwe manier van deployen. Continuous integration, Git Flow, deploy vanuit Bitbucket enzo. Maar dit staat dus best ver af van wat mijn collega's gewend zijn. En belangrijk is hier een middenweg in te zoeken. Belangrijke context: ons bedrijf pakt regelmatig bestaande projecten op shared hosting elders aan. Daarom is het lastig te voorspellen wat voorhanden is. 80% van ons werk draait op een VPS. Het is wel chill als het ook een beetje robuust is en werkt op shared hosting, tenzij het helemaal dichtgetimmerd is.

Door die "middenweg" is het zo met die "backend" folder in de skeleton zoals ik hierboven schreef. Dan hebben we 1 github repo (we gebruiken de GitHub for Mac client om grafisch te houden), hoeven m'n collega's bijna niet met Composer aan de slag bijvoorbeeld. In Laravel heb je dan nog workbenches voor dingen, maar ik heb nog niet helemaal duidelijk hoe ik dat dus simpel kan houden voor m'n collega's, en dus doen we daar momenteel niks mee (Met alle respect natuurlijk,zijn harde werkers).

Ik heb gekeken hoe ik met composer een "create-project" kan doen met een private Github repository (, dat lukt prima. Dus er is een manier om die skeleton via ssh op locatie te krijgen. Ik heb een beginnetje gemaakt aan een install script, maar zit nu dus te twijfelen of dat wel the "way to go" is voor ik verder ga!

Kortom, we hebben een "skeleton", die als basis moet dienen voor alle nieuwe sites die we zouden bouwen. M'n collega's moet ik niet teveel gaan belasten met Composer & Bower & Grunt & Git & Jenkins &zovoort, maar een beetje mag wel! Hoe kan ik dit het beste aanpakken?

(Net kwam nog in me op dat als we een vps hebben, dat we dat misschien handig kunnen combineren met iets FTPloy misschien dat ik ooit langs zag komen? Ik heb geen idee. )

[Cartman!]

Je kan Satis installeren, je skeleton in GIT zetten en dan een private package hebben zodat je met "composer create-project" direct je eigen skeleton kan installeren. In het verhaal over je collega's mis ik een beetje wat hun functies zijn, als dat ook developers zijn dan zou ik ze om hun oren slaan dat ze niet werken met dergelijke tools anno 2015 namelijk en het ze opleggen ipv. het van ze weg te houden. Met alle respect, het klinkt of ze in 1999 zijn blijven hangen...

[ Voor 7% gewijzigd door Cartman! op 19-04-2015 13:10 ]

[Donderpoes]

Je noemt al wat opties, ik zou ze uitproberen en kiezen welke jou het beste bevalt. Verder kan ik je hier niet echt mee verder helpen.

Wat ik je wel als tip wil meegeven. Vergeet je collega's. Ik heb het idee dat je collega's de vooruitgang tegenhouden. Ik heb in het verleden ook op die manier rekening gehouden met wat collega's die prima hun werk deden, maar op de manier hoe het heel wat jaren terug ging. Op een gegeven moment heb ik wat processen veranderd. Zodat deze weer wat meer met de huidige tijd meeliepen. De collega's vonden het maar niks. Maar ze moesten het wel oppakken (of wegwezen) en nu zijn ze prima aangepast.

[afraca]

Cartman! schreef op zondag 19 april 2015 @ 13:02:
Je kan Satis installeren, je skeleton in GIT zetten en dan een private package hebben zodat je met "composer create-project" direct je eigen skeleton kan installeren.

Daar had ik ook naar gekeken. Het blijkt dat je niet eens een Satis repo nodig hebt, je kunt rechtstreeks een package van een github repo installeren Maar ik heb nog totaal niet gekeken hoe je dan kunt locken op bepaalde versies/tags enzo.

In het verhaal over je collega's mis ik een beetje wat hun functies zijn, als dat ook developers zijn dan zou ik ze om hun oren slaan dat ze niet werken met dergelijke tools anno 2015 namelijk en het ze opleggen ipv. het van ze weg te houden. Met alle respect, het klinkt of ze in 1999 zijn blijven hangen...

Misschien kwam het onnodig denigrerend over. Het zijn topmensen en harde werkers. Voor context en verdere discussie misschien goed om (het enigszins vaag te houden maar) toch iets te zeggen: gaat om zelfgeschoolde ontwikkelaars, daarom niet heel high-end fancy gedoe, ze kijken wat werkt, en het is klein eigen opgezet bedrijf. Één 75/25 frontend/backend, tweede is 50/50, en derde is grafisch ontwerper die nu frontend beetje leert.

[Cartman!]

afraca schreef op zondag 19 april 2015 @ 22:36:
[...]
Daar had ik ook naar gekeken. Het blijkt dat je niet eens een Satis repo nodig hebt, je kunt rechtstreeks een package van een github repo installeren Maar ik heb nog totaal niet gekeken hoe je dan kunt locken op bepaalde versies/tags enzo.

Daar is Satis dus zo handig voor, die regelt dat voor je Kan t zonder? Jep, is t handiger met? Jep

Misschien kwam het onnodig denigrerend over. Het zijn topmensen en harde werkers. Voor context en verdere discussie misschien goed om (het enigszins vaag te houden maar) toch iets te zeggen: gaat om zelfgeschoolde ontwikkelaars, daarom niet heel high-end fancy gedoe, ze kijken wat werkt, en het is klein eigen opgezet bedrijf. Één 75/25 frontend/backend, tweede is 50/50, en derde is grafisch ontwerper die nu frontend beetje leert.

Als development hun dagelijkse werk is moet je t er gewoon instampen, simpel. En later zijn ze je dankbaar wat de meeste tools die je noemt besparen je zoveel tijd.