Repository indeling icm DeployHQ

[robg1984]

Wij hebben een CMS met de volgende indeling:

code:

clients/
   klant1/
   klant2/
   klant3/
cms/
   application/
   resources/
.htaccess
index.php

Nu is het zo dat alles in 1 repository (Gitlab) zit.
Met DeployHQ zetten we alles in 1 keer naar een testserver en vervolgens per klant (in apart project binnen DeployHQ) naar de ftp-server van de klant.

Dit werkt allemaal prima.
Probleem 1: Het nadeel is echter dat alle klantmappen ook gedeployed worden naar de ftp-server van elke klant.
Probleem 2: We willen een andere programmeur aan het werk zetten voor slechts 1 klant, die moet dus niet alle klanten kunnen pullen uit de repository.

Nu zou je zeggen, dan maak je toch per klant een aparte repository en 1 voor de core (cms/) maar is dit de handigste manier?
In dit geval zou je namelijk ook per klant 2 projecten binnen DeployHQ moeten hebben, 1 voor de klantmap en 1 voor de core, dan ben je dus elke keer 2 keer aan het committen,pushen,deployen als je diverse wijzigingen hebt gedaan.

[naam]

Wat wij hier als structuur gebruiken is per klant/project een repository. Dan de gemeenschappelijke delen laden met bijvoorbeeld Composer. Hierdoor krijg je dus een apart Project met daarin de 'Core' van je applicatie, en klantspecifieke dingen alleen in de repository van die klant/project.

[Bloemkoolsaus]

naam schreef op maandag 24 oktober 2016 @ 12:58:
Wat wij hier als structuur gebruiken is per klant/project een repository. Dan de gemeenschappelijke delen laden met bijvoorbeeld Composer.

Zo is het bij ons ook geregeld.

Toen we nog svn gebruikten, deden we het met externals (submodules in git). Maar met composer werkt veel prettiger.

[DJMaze]

In mijn CMS prop ik de core in /usr/local/lib/php/NAAM_CORE/ en deel dat met alle projecten.
Vervolgens per project een Mercurial repo met alleen de public data.
Bij core updates krijgen alle projecten dan ook automatisch een vlekkeloze DB migratie en blijft de rest "as is".
En als het project later niet op één van mijn servers komt te staan upload ik de 'core' gewoon naar de website root (bijvoorbeeld: /public_html/../NAAM_CORE/)
Scheelt een hoop werk!

Daarnaast kan ik een deel van de core als php extensie library (.so) inladen (of HHVM) op de server voor een hogere snelheid.

[ Voor 10% gewijzigd door DJMaze op 24-10-2016 17:51 ]

[robg1984]

Wij hadden eerder ook 1 instantie van de core voor alle klanten maar als we die gingen updaten kwam het te vaak voor dat er bij 1 klant fouten optraden. Wij gebruiken ons CMS niet als 1 systeen die overal hetzelfde is maar 1 core met (veel) uitbreidingen per klant. Ik wil de core dus niet in 1 keer voor iedereen updaten. Hoe doen jullie het trouwens met de database als hier een kolom bij komt? Hoe gaan jullie hiermee om met het updaten van de databases van klanten?

[Barryvdh]

robg1984 schreef op dinsdag 25 oktober 2016 @ 09:15:
Wij hadden eerder ook 1 instantie van de core voor alle klanten maar als we die gingen updaten kwam het te vaak voor dat er bij 1 klant fouten optraden. Wij gebruiken ons CMS niet als 1 systeen die overal hetzelfde is maar 1 core met (veel) uitbreidingen per klant. Ik wil de core dus niet in 1 keer voor iedereen updaten. Hoe doen jullie het trouwens met de database als hier een kolom bij komt? Hoe gaan jullie hiermee om met het updaten van de databases van klanten?

Dat is dus makkelijker met Composer. Van je CMS een (private) package maken, dat requiren (bijv v1.2.x) en per klant dus uitbreiden (in het repo van de klant). Bij update van het CMS haal je gewoon nieuwe update binnen, bijv kleine bugfixes in 1.2.1/1.2.3 etc, of nieuwe features in 1.3.0. Incompatible versies als 2.0, 3.0 (SemVer dus), dan kan je zelf bepalen welke klant welke update krijgt door gewoon composer update te draaien.

Voor database changes gebruik ik migrations (in Laravel, maar zijn ook losse libraries voor), die beschrijven elke update. Dus na installeren van nieuwe versie, draai je (automatisch) de migraties die nog open staan en je database wordt bijgewerkt.