[Git] Basis als master en branch voor projecten op basis?

[TheNephilim]

Misschien bekend bij enkele mensen hier, maar ik maak in het dagelijkse leven Wordpress thema's voor klanten. Geheel op maat, maar wel volgens een 'standaard' thema. Dus we hebben enkele functies en wat basis spullen die als 'base' dienen voor het nieuw te maken project. Nu heb ik een repo op Bitbucket en vroeg me af hoe ik dat het beste kan doen.

Als ik een nieuw project start, is het dan handig dat ik de master pull en dan push naar een nieuwe branch?

Of moet ik voor elk project een nieuwe repo maken? Lijkt me niet heel handig gezien ze nog steeds allemaal op basis van die ene 'master' gemaakt zijn.

[kwaakvaak_v2]

Persoonlijk zou ik er voor kiezen om voor elk theme een apparte repo te hebben, als je nooit functies van theme a -> b wil mergen/cherrypicken.

Verwacht dat wel te doen, dan alles in 1 repo en branchen..

Je kunt altijd een fork maken als in de praktijk blijkt dat het optie 1 of 2 niet handig lijkt te werken.. Branch en Fork zijn 'goedkope' handelingen binnen git.

[Sebazzz]

kwaakvaak_v2 schreef op dinsdag 07 januari 2014 @ 12:18:
Persoonlijk zou ik er voor kiezen om voor elk theme een apparte repo te hebben, als je nooit functies van theme a -> b wil mergen/cherrypicken.

Zelfs al wil je dat wel dan kan je dat doen door de source repo als remote toe te voegen.

Ik zou voor forken kiezen, ook omdat je je volledige history behoudt.

[Barryvdh]

Ik doe meestal een git clone, verwijder de git history en push hem dan naar een nieuw repo. Git geschiedenis van het startproject hoef ik niet voor dat nieuwe project te bewaren (gewoon een commit met 'initial import' oid).
Mergen doe ik ook niet, vooral omdat ik dan waarschijnlijk veel conflicts krijg en dat waarschijnlijk toch niet goed gaan, maar dat kan ook aan mij liggen

Het lijkt mij een beetje onoverzichtelijk worden als je dalijk tig branches hebt in 1 repo, en dan ook nog wat feature/patch branches gaat gebruiken..

[Rafe]

Overzichtelijkheid houden is een kwestie van goede naamgeving, maar dit is niet altijd even eenvoudig

Ik zou denk ik zelf voor branches gaan. Lijkt me dat je met enige regelmaat klantthema's wil updaten met changes uit master, bijvoorbeeld om compatible te blijven met nieuwere versies van Wordpress.

[TheNephilim]

Haha, ik zie het al Er zijn verschillende manieren waarop ik dit kan doen dus

[Barryvdh]

Ik ken Wordpress verder niet zo goed hoor, maar daar heb je toch ook parent themes en child themes? In je parent theme stop je dan de meeste code en in je child theme doe je de site-specifieke wijzigingen? Als het goed is hoef je dan je child theme niet vaak upstream up te daten toch?

Maar het hangt er dan inderdaad vanaf hoeveel wijzigingen het zijn steeds en hoe makkelijk het is om die terug te mergen.

[TheNephilim]

Dat klopt, een parent theme zou als basis kunnen dienen en je child theme bevat dan alleen de style. Dus kleurtjes en font en verder niet. Echter zijn de websites die we maken zo verschillend, dat op die manier werken niet mogelijk is. Dat kan alleen als je een hele strikte standaard structuur van je website hebt.

Overigens gebruiken we wel een parent theme. Hierin zitten alle standaard functies voor het bijv. een lightbox en bepaalde JS bestanden voor oude IE versies.

Het child theme is niet meer dan een skelet en moet ook de standaard less files en dergelijke bevatten waarvan ik een custom stylesheet compile.

--- Edit ---

Heb maar gewoon gebranched. Lijkt me de beste oplossing, voorlopig in ieder geval. Zo is voor mij ook duidelijk welk thema met welke basis gemaakt is. Heel af en toe maken we namelijk een compleet nieuwe basis, met de wensen en eisen die dan van toepassing zijn. Idealiter zou je natuurlijk de bestaande basis steeds updaten/upgraden/etc., maar dat is niet handig in de vele bestaande websites die gebruik maken van die basis. Updaten kun je toch niet, het is maar een skelet.

Updates kunnen we wel uitrollen voor het parent theme, maar dat zien we dan wel weer.

Als laatste rest nog een deploy strategie, maar dat is voorlopig nog even niet aan de orde. Nu al netjes het eerste (nieuwe) project voor 2014 in Git, dus ik ben al heel blij Wel even wennen, af en toe commiten en dergelijke, maar goed.

[ Voor 39% gewijzigd door TheNephilim op 07-01-2014 16:03 ]

[Nedra]

Heb je dit gezien: https://marketpress.com/2...-with-git-and-capistrano/
http://theme.fm/2011/08/t...ess-with-capistrano-2082/

Zou wel eens een hele relaxte manier kunnen zijn om je projecten te deployen

[TheNephilim]

Zou ik continue aan één project werken, dan lijkt het helemaal een goede oplossing. Echter is dat niet het geval en gaan bepaalde vereisten/aannames niet op.

Maar, ik ga wel eens kijken wat hier nog uit te halen valt. Er is vast wat mee te doen!

---

Overigens is dat test/dev/prod omgevingsgebeuren nogal onhandig. Ik ontwikkel op een server, waarop de klant(en) ook kunnen kijken en als het klaar is kunnen vullen en dergelijke. Nu kan ik niet zoveel met git en weet ik wat op die server, dus steeds handmatig uploaden na wijzigingen. Eerder werkte ik vanaf de server, dus hoefde ik dat niet handmatig te doen.

Maar goed, dat zou betekenen dat ik eerst lokaal moet ontwikkelen en dan overzetten naar de staging (oid.) server. Schiet niet echt op, gezien de x-daagse projecten hier soms Er zijn overigens wel Wordpress tools waarmee je kunt deployen en dergelijke, dus ook nieuwe installaties neerzetten enzo, maarja... nóg meer tools

[Bigs]

Als de klantwijzigingen niet te groot zijn zou het werken met branches handig kunnen zijn omdat je dan je klantspecifieke branches kunt rebasen op master (dat voert de wijzigingen uit de branch commits opnieuw uit op de nieuwe master). Als de wijzigingen erg groot zijn zou ik gewoon met meerdere repo's werken en een 'master' repository waaruit je wijzigingen pullt. Git branches zijn in principe niet bedoeld om meerdere projecten in 1 repository te huizen (zoals bij SVN wel gebruikelijk is) dus ik zou ze daar ook niet voor gebruiken.

[TheNephilim]

Nog even gekeken, maar veel deployment oplossingen (ook speciaal voor Wordpress) vereisen SSH toegang. Dat gaat op onze eigen server wel lukken, maar niet bij de klant. Dat is 9 van de 10 keer gewone consumenten hosting voor enkele tientjes per jaar. Daarnaast is het opzetten van zo'n systeem niet de moeite per project.

Kortom; Ik moet iets simpelers hebben. Lokaal/Dev -> Staging -> Productie moet eigenlijk Staging/Dev -> Productie worden.

Bigs schreef op woensdag 08 januari 2014 @ 10:36:
Als de klantwijzigingen niet te groot zijn zou het werken met branches handig kunnen zijn omdat je dan je klantspecifieke branches kunt rebasen op master (dat voert de wijzigingen uit de branch commits opnieuw uit op de nieuwe master). Als de wijzigingen erg groot zijn zou ik gewoon met meerdere repo's werken en een 'master' repository waaruit je wijzigingen pullt. Git branches zijn in principe niet bedoeld om meerdere projecten in 1 repository te huizen (zoals bij SVN wel gebruikelijk is) dus ik zou ze daar ook niet voor gebruiken.

[Woy]

Het is sowieso niet verstandig om je Staging/Test gelijk te hebben met Dev. Ik zou niet willen dat als ik aan het werken bent je klant daar hinder bij ondervind tijdens het testen. Natuurlijk kun je wel een hele korte Dev -> Staging/Test cyclus houden, waardoor de klant wel erg up to date is. Juist automatische deployment kan daar dus extra bij ondersteunen.

Voor de deployment naar productie kan je dan nog een handmatige stap invoegen, maar die zal ook minder vaak uitgevoerd hoeven te worden.

[kwaakvaak_v2]

ik zou daar van maken

Dev -> Staging/Productie

Je wil niet testen op de dev omgeving, maar op de productie omgeving ivm. mogelijke subtiele verschillen en wat Woy hierboven zegt

[TheNephilim]

Shortly; gewoon lokaal gaan ontwikkelen en (automatisch) deployen naar staging. Dan na goedkeuring en vullen klant, gewoon handmatig deployen naar productie?

Dat moet misschien wel lukken. Al heb ik geen idee hoe ik alleen (!) het thema kan deployen, maar dat ga ik dan eens uitzoeken. Sowieso moet ik dat nog uitzoeken, deployen Staging server is gewoon Interworx. Nu is het gewoon nieuwe hostaccount toevoegen, profiel 'preview' en aan de slag.

[Barryvdh]

Zoals ik trouwens al zei, ik heb weinig verstand van Wordpress, maar kwam toevallig deze link tegen in de trending repo's van Github:
https://github.com/roots/bedrock

Dependency management with Composer
Automated deployments with Capistrano
Better folder structure
Easy WordPress configuration with environment specific files
Environment variables with Dotenv

Weet niet of je het al kent, maar misschien handig ter inspiratie.

[ Voor 8% gewijzigd door Barryvdh op 08-01-2014 13:29 ]

[Bigs]

Grappig, dat bedrock lijkt qua toolchain, configuratie en folderindeling wel heel erg op Ruby on Rails. Goeie zaak, ik werk al jaren met Capistrano en sinds kort ook met Vagrant. Ideaal Als dat ook met Wordpress mogelijk is, is dat zeker het overwegen waard.

[ Voor 16% gewijzigd door Bigs op 08-01-2014 13:50 ]

[Nedra]

TheNephilim schreef op woensdag 08 januari 2014 @ 10:44:
Nog even gekeken, maar veel deployment oplossingen (ook speciaal voor Wordpress) vereisen SSH toegang. Dat gaat op onze eigen server wel lukken, maar niet bij de klant. Dat is 9 van de 10 keer gewone consumenten hosting voor enkele tientjes per jaar. Daarnaast is het opzetten van zo'n systeem niet de moeite per project.

Kortom; Ik moet iets simpelers hebben. Lokaal/Dev -> Staging -> Productie moet eigenlijk Staging/Dev -> Productie worden.


[...]

Je bent niet de enige die daar tegen aan loopt. Maar: Als je ipv Capistrano, Dandelion - https://github.com/scttnlsn/dandelion - gebruikt kan je via ftp/sftp je veranderingen deployen op basis v git. Ik ben hier zelf nu net mee aan het prutsen en het lijkt mij een hele nette oplossing voor hosting zonder ssh toegang. Nadeel is wel dat je ook de WP files in je repo moet hebben.

@barryvdh: Thanks, ziet er uit alsof het waard is eens te bekijken.

Overigens een klein beetje gerelateerd; er is altijd nog het issue van media-files en databases gesynced houden. Of eigenlijk, niet meer: https://deliciousbrains.com/wp-migrate-db-pro/

[Barryvdh]

Of gewoon de hosting overnemen van de klant. Vroeger gebruikten wij ook nog wel eens de bestaande hosting, maar tegenwoordig nemen we het gewoon over en brengen we het onder in een eigen server. Stuk makkelijker met SSH, tools installeren, accounts/db beheren, domeinnamen wijzigen en compatibiliteit (oude php versie, missende modules etc)

[Nedra]

Daar valt zeker wat voor te zeggen; maar nemen jullie dan ook bijv. de e-mail hosting voor jullie rekening? Klinkt misschien niet heel service gericht maar als de klant zegt "m'n e-mail doet het niet" is dat nou niet bepaald iets waar ik me graag mee bezig houd.

[Barryvdh]

Nedra schreef op woensdag 08 januari 2014 @ 15:06:
Daar valt zeker wat voor te zeggen; maar nemen jullie dan ook bijv. de e-mail hosting voor jullie rekening? Klinkt misschien niet heel service gericht maar als de klant zegt "m'n e-mail doet het niet" is dat nou niet bepaald iets waar ik me graag mee bezig houd.

Meestal bieden we of 1 account/forward aan (maar liever niet) maar raden we Google Apps aan, zodat we er zelf ook geen last van hebben. Of evt. houden ze de oude account voor de email. (Of een VPS waarmee ze wel veel email via de server kunnen doen).

[TheNephilim]

Barryvdh schreef op woensdag 08 januari 2014 @ 13:28:
Zoals ik trouwens al zei, ik heb weinig verstand van Wordpress, maar kwam toevallig deze link tegen in de trending repo's van Github:
https://github.com/roots/bedrock

[...]

Weet niet of je het al kent, maar misschien handig ter inspiratie.

Dat is een mooi systeem, maar wederom voor mijn situatie to much. Ook hier weer SSH etc., daar kan ik niet zoveel mee.

Nedra schreef op woensdag 08 januari 2014 @ 14:57:
[...]

Je bent niet de enige die daar tegen aan loopt. Maar: Als je ipv Capistrano, Dandelion - https://github.com/scttnlsn/dandelion - gebruikt kan je via ftp/sftp je veranderingen deployen op basis v git. Ik ben hier zelf nu net mee aan het prutsen en het lijkt mij een hele nette oplossing voor hosting zonder ssh toegang. Nadeel is wel dat je ook de WP files in je repo moet hebben.

@barryvdh: Thanks, ziet er uit alsof het waard is eens te bekijken.

Overigens een klein beetje gerelateerd; er is altijd nog het issue van media-files en databases gesynced houden. Of eigenlijk, niet meer: https://deliciousbrains.com/wp-migrate-db-pro/

Ah, Dandelion, dat ziet er werkbaar uit! Gewoon YAML files voor de FTP configuratie, dat zou moeten lukken. Volgens mij kan ik die zo naar /wp-content/themes/themename wijzen, zonder dat ik heel Wordpress ook erin zou moeten hebben.

Barryvdh schreef op woensdag 08 januari 2014 @ 15:02:
Of gewoon de hosting overnemen van de klant. Vroeger gebruikten wij ook nog wel eens de bestaande hosting, maar tegenwoordig nemen we het gewoon over en brengen we het onder in een eigen server. Stuk makkelijker met SSH, tools installeren, accounts/db beheren, domeinnamen wijzigen en compatibiliteit (oude php versie, missende modules etc)

Dat doen we tegenwoordig wel, maar op reseller basis en bij gewone consumenten hosting. We hebben wel zelf met hosting gewerkt en dergelijke, maar het is te bewerkelijk en niet mijn ding. Liever specialiseer ik me in ontwikkeling van websites, dan in webhosting. Daarnaast moet je bij storing altijd zelf aan de slag en heb je (naar mate je meer klanten krijgt) steeds meer verantwoordelijkheid.

Klanten (in ons geval) gaan toch niet betalen voor dure hosting. Dus liever houden we het lekker simpel!

Nedra schreef op woensdag 08 januari 2014 @ 15:06:
Daar valt zeker wat voor te zeggen; maar nemen jullie dan ook bijv. de e-mail hosting voor jullie rekening? Klinkt misschien niet heel service gericht maar als de klant zegt "m'n e-mail doet het niet" is dat nou niet bepaald iets waar ik me graag mee bezig houd.

Eensch, dat zou voor ons betekenen dat we bij klanten thuis e-mail in moeten gaan stellen. Dat is nu soms al het geval, maar dan ben je helemaal aan de beurt. Toen Google Apps nog gratis was, kon je het daar relatief simpel regelen, maar dat is nu geen optie meer. Die paar euro per (!) account is gewoon teveel voor de bedrijven waar wij voor werken.

[Barryvdh]

Maar de klanten die voor 2 euro per maand een website hosten, krijgen daar toch ook geen email support voor? Gewoon de instellingen voor Outlook/iPhone ed lijkt me voldoende. Wij hebben gewoon support op onze hosting, dus het enige verschil is dat ze ipv 5 euro per maand aan de hoster betalen, nu 5 aan jou betalen. Jij huurt een managed vps/dedicated iets dergelijks waarmee je de kosten kan delen en dus weer winst maakt. De klant boeit het niet en jij hebt nog steeds hetzelfde DirectAdmin systeempje, contactpersoon als je site offline is en je laat hen gewoon de updates etc doorvoeren. Maar dat is een beetje offtopic..

Ik ben iig blij dat wij gewoon met Git kunnen deployen en ik geen gezeik heb met andere servers. Als er klanten persé hun eigen hosting willen gebruiken is het bijna altijd gezeur omdat er net dat ene kleine dingetje anders is.

[Woy]

TheNephilim schreef op woensdag 08 januari 2014 @ 15:17:
[...]
...
Toen Google Apps nog gratis was, kon je het daar relatief simpel regelen, maar dat is nu geen optie meer.
...

Beetje offtopic maar kijk eens naar outlook.com

[TheNephilim]

Barryvdh schreef op woensdag 08 januari 2014 @ 15:35:
Maar de klanten die voor 2 euro per maand een website hosten, krijgen daar toch ook geen email support voor? Gewoon de instellingen voor Outlook/iPhone ed lijkt me voldoende. Wij hebben gewoon support op onze hosting, dus het enige verschil is dat ze ipv 5 euro per maand aan de hoster betalen, nu 5 aan jou betalen. Jij huurt een managed vps/dedicated iets dergelijks waarmee je de kosten kan delen en dus weer winst maakt. De klant boeit het niet en jij hebt nog steeds hetzelfde DirectAdmin systeempje, contactpersoon als je site offline is en je laat hen gewoon de updates etc doorvoeren. Maar dat is een beetje offtopic..

Ik ben iig blij dat wij gewoon met Git kunnen deployen en ik geen gezeik heb met andere servers. Als er klanten persé hun eigen hosting willen gebruiken is het bijna altijd gezeur omdat er net dat ene kleine dingetje anders is.

Dat is waar, normaliter is dat voldoende. Echter is de e-mail toch weer een onderdeel waarop het mis kan gaan. Een website offline is al een probleem, maar mail is zeker niet handiger. E-mail en webhosting hebben we (zoals gezegd) wel gedaan en misschien is managed wel een idee hoor, maar het blijft extra werk. We richten ons op dit moment volledig op (Wordpress) webdevelopment en hebben daar nog genoeg te leren. Resellen zoals we nu doen, geeft ons de mogelijkheid om er een beetje op te verdienen, een beetje controle en nu hebben we een vertrouwde host. Waar alles werkt zoals het moet.

Overigens hebben we hier (in datacenter) nog een klein serverpark van 10-15 servers, met loadbalancers, fileservers, webservers, mysql servers en de hele mikmak. Daar draaien nog oude projecten op en enkele websites voor klanten. De ervaringen hiermee is dat het niet altijd even handig is en daarom beginnen we daar niet meer aan.

Snel deployen naar de klant is inderdaad wel handig, maar misschien kan zoiets met Dandelion. Over het algemeen is er weinig te doen in de database gezien het toch Wordpress is. Even content toevoegen voor nieuwe features moet je toch in de productie omgeving doen en dan neem je in ieder geval geen testspul mee.

Woy schreef op woensdag 08 januari 2014 @ 15:41:
[...]

Beetje offtopic maar kijk eens naar outlook.com

Ah die doen hetzelfde nu als Google voorheen begrijp ik. Dat kan nog wel eens handig zijn! Al blijf je het risico houden dat ook dat ooit betaald moet gaan worden. In ieder geval geen sluitende oplossing die ik overal wil gaan gebruiken. Wel handig voor de wat grotere klanten die opzoek zijn naar een dergelijke oplossing. Dank u!

--- Edit ---

Ik zie dat Dandelion alleen beschikbaar is voor OS X en Linux, niet handig voor mij als Windows gebruiker Maar goed, het feit dat zoiets als dit bestaat is al heel wat. Er zijn vast alternatieven voor Windows.

[ Voor 4% gewijzigd door TheNephilim op 08-01-2014 16:41 ]

[TheNephilim]

Hoe kan ik na een Clone verder in een nieuwe repo?

--- Edit ---

Ah, door de git url van de origin aan te passen .

[ Voor 40% gewijzigd door TheNephilim op 08-01-2014 17:28 ]

[TheNephilim]

Even een update, maar ook meteen een vraag! Inmiddels heb ik hier een tijdje de nieuwe projecten in Git en dat werkt prima. Ook een project in PhpStorm helpt al mee, maar er zijn nog wat dingen die ik graag zou verbeteren.

Naast Git (bij Bitbucket) en PhpStorm ben ik Vagrant gaan gebruiken, met name dan VagrantPress bleek erg handig te zijn. Deployment wil ik gaan doen via PhpStorm. We hebben namelijk alleen deployment via ftp nodig en naar preview en (eventueel) de productie server.

Structuur

/projectnaam/ (clone van mijn eigen versie van VagrantPress.)
-- wordpress/ (na vagrant up de dir waar Wordpress geïnstalleerd is.)
-- -- wp-content/
-- -- -- themes/
-- -- -- -- parenttheme/ (clone van onze parent theme.)
-- -- -- -- basetheme/ (clone van de basis, waarvan ik de origin wijzig naar nieuwe repo.)

In eerste instantie had ik al bedacht dat het handig is om niet alleen de dir basetheme/ toe te voegen als project in PhpStorm, maar gewoon Wordpress. Dan heb ik autocomplete en dergelijke, ook van Wordpress, heel handig natuurlijk!

Opzet bij nieuw project

1. Dir /projectnaam/ aanmaken.
2. Eigen kopie VagrantPress clonen in /projectnaam/.
3. vagrant up/
4. Dir parenttheme/ aanmaken in /projectnaam/wordpress/wp-content/themes/ en onze eigen parenttheme erin clonen.
5. Dir basetheme/ aanmaken in /projectnaam/wordpress/wp-content/themes/ en onze eigen basetheme erin clonen.
6. Nieuwe repo aanmaken voor basetheme en git remote origin wijzigen naar nieuwe repo.

Kortom...

Maar... PhpStorm heeft ook iets van Vagrant ingebouwd, dus zou ik eigenlijk /projectnaam/ helemaal in PhpStorm moeten zetten. Dat gaat vast allemaal goed, maar (nu de hamvraag) hoe doe ik dat met alle subdirs die ook allemaal uit Git komen? Daarnaast is eigenlijk een externe bron, die onafhankelijk te updaten moet zijn en dat geld ook voor (eventuele) plugins.

Misschien maak ik het ingewikkelder dan het is, maar wat mis ik hier? Hoe krijg ik dat netjes voor elkaar, zonder uren voorbereiding op een project te hebben.

[Nedra]

Als ik het goed begrijp is de basetheme het enige waar je een nieuwe git repo voor maakt? En deploy je dan ook op basis v de basetheme repo of deploy je vanuit de hele wordpress folder? (misschien begrijp ik 't niet helemaal goed, maar aangezien ik hier ook veel mee bezig ben, ben ik erg nieuwsgierig )

[TheNephilim]

Yup, de basetheme/ is namelijk waar het om draait. Wordpress kan de klant (evt.) zelf updaten als de website online staat en het is voor mij niet erg nuttig om de hele vagrant map in git te hebben. Het enige wat ik wil, is dat aanpassingen aan de standaard vagrant configuratie gewoon netjes in Git staan, zodat ik er altijd bij kan en wijzigingen terug te draaien zijn. Met de parentheme/ word eigenlijk niks gedaan. Die is nodig voor bepaalde basisfunctionaliteit, maar die gaan we niet updaten (als dat niet nodig is).

Alleen het basetheme/ depoyen denk ik ja, nog niet gedaan. Echter een keer de hele meuk naar preview omgeving, inclusief wordpress zelf. Maar dan moet ik ook rekening houden met de wp-config.php en dergelijke. Kost eigenlijk al teveel tijd voor de projecten hier. Dus even zien hoe we dat gaan doen.

Heb ondertussen al wat gevonden, maar dat helpt me niet. Zowel wordpress/, basetheme, en parenttheme, kunnen een submodule zijn. Echter moet ik dan de /projectnaam/ in Git knikkeren en dan komen we weer bij het probleem uit de eerste alinea.

Nogmaals, de hele mikmak in Git is niet handig, zeker niet met deployen. Dan moet ik voor alle gebruikte plugins (3-4) ook weer updates en dergelijke bijhouden. Ik wil gewoon (als de klant iets wil) snel een wijziging kunnen aanbrengen aan het thema van de klant. Dus lokaal aanpassen, dan (evt.) deploy naar preview en door naar live. Maar alleen het thema...

[Archiebald]

Is het niet handiger om per plugin ook en per klant (neem aan dat die maar 1 thema heeft) ook.

Dus als je een nieuwe klant hebt, maak je een nieuwe branch op basis van de master (parentthema). Dan merge je vervolgens alle plugin branches die die klant heeft erin.

Als je dan de plugins update in hun eigen branch, kun je die gewoon per klant weer in de klant branch te mergen (en dus bij de klant die plugin updaten). Moet je alleen niet een klant branch terug in een plugin branch mergen

Voor automatische deploy kun je misschien ook eens kijken naar een Jenkins CI.
Die gebruiken wij icm MSBuild om de configs automatisch aan te passen. Wellicht is er vast iets voor Wordpress/php wat hetzelfde doet, maar dat weet ik niet.

[Nedra]

En kan je niet gewoon de nieuwe repo (per klant, neem ik aan) van je basistheme in de gaten houden en deployen?

Overigens gebruik ik nu een variant van deze repo. Uit je vorige posts maak ik op dat je niet veel hebt aan Dandelion of Capistrano, maar misschien kan het alsnog handig zijn icm PHPStorm?

[TheNephilim]

Archiebald schreef op woensdag 22 januari 2014 @ 16:10:
Is het niet handiger om per plugin ook en per klant (neem aan dat die maar 1 thema heeft) ook.

Dus als je een nieuwe klant hebt, maak je een nieuwe branch op basis van de master (parentthema). Dan merge je vervolgens alle plugin branches die die klant heeft erin.

Als je dan de plugins update in hun eigen branch, kun je die gewoon per klant weer in de klant branch te mergen (en dus bij de klant die plugin updaten). Moet je alleen niet een klant branch terug in een plugin branch mergen

Voor automatische deploy kun je misschien ook eens kijken naar een Jenkins CI.
Die gebruiken wij icm MSBuild om de configs automatisch aan te passen. Wellicht is er vast iets voor Wordpress/php wat hetzelfde doet, maar dat weet ik niet.

Dat gecombineerde word me allemaal veel te ingewikkeld Het moet lean, mean en vooral niet teveel werk zijn. Een half uurtje setup is voor sommige projecten al veel te veel.

Nedra schreef op woensdag 22 januari 2014 @ 17:13:
En kan je niet gewoon de nieuwe repo (per klant, neem ik aan) van je basistheme in de gaten houden en deployen?

Overigens gebruik ik nu een variant van deze repo. Uit je vorige posts maak ik op dat je niet veel hebt aan Dandelion of Capistrano, maar misschien kan het alsnog handig zijn icm PHPStorm?

Ik ga het denk ik anders aanpakken, de parent theme gaat denk ik verdwijnen. Alle basisfunctionaliteit knikker ik in het basisthema. Het is te weinig om een parent theme te verantwoorden, in ieder geval op deze manier.

Aan Capistrano en consorten heb ik niks. Voor zover bij mij bekend hebben die allemaal SSH/Git nodig op de server en dat kan niet in de productie omgegeving. Super-Project ziet er wel grappig uit, daar ga ik eens verder naar kijken. Thanks! ^^

---

Ondertussen heb ik een preview omgeving opgezet door gewoon Wordpress Network te installeren. Dan hoef ik alleen nieuwe website toe te voegen (in Wordpress) en dan krijg je preview.<onsdomein.nl>/<klantdomeinnaam.nl>. Heel makkelijk voor de klant en wij hoeven niet steeds Wordpress up te loaden, plugins te installeren en weet ik wat. Daarvoor gebruik ik dan gewoon de deploy functie in PhpStorm. Het enige probleem is de database, je kunt die niet 1-op-1 overnemen van dev naar preview, maar vullen is ook lastig. Misschien dat een eenmalige import wel werkt, even kijken hoe dat gaat.

Nu nog de productie toevoegen aan deploy. Dan kan ik een aanpassing doen en die testen, laten zien op de klant in preview en deployen naar productie als alles goed is.

Her en der is er nog een boel winst te halen wat betreft tijd. Ik moet het 'proces' eerst nog in de vingers krijgen en dat kost gewoon tijd. Hopelijk komen er steeds wat handigheidjes naar boven borrelen, om het tot een mooi geheel te maken.

To do list!

• Parent theme & Base theme combineren tot één basis.
• Uitvogelen waarom nieuwe bestanden toevoegen een vagrant reload vereisen.
• Repo/branch gebeuren nog eens onder de loep nemen.

[Nedra]

WP Netwerk voor op de staging server, da's best handig! Ik zie dat WP Migrate DB Pro ook werkt voor Multisites (je zou haast denken dat ik voor ze werk, maar het is eerlijk waar één van de handigste plugins die ik ooit gekocht heb). Dat zou je weer wat tijd kunnen besparen met de Database!

Ik doe het op 't moment als volgt:

• Repository clonen (aangepast van dat 'super project') naar lokaal
• Een nieuw project repositiory maken waar ik dit project naar push
• Lokale, staging en productie server details invullen in de WP config en dandelion files
• Downloaden WP en plugins van de WordPress repo via Composer
• Normale WP installatie doorlopen
• Migrate DB Pro lokaal installeren
• Een standaard WP installatie maken op de staging server (via installatron of gewoon handmatig) en eventueel al op de productie server
• WP bestanden (plugins en thema) deployen naar staging/production via Dandelion
• Op de staging/production server nog even WP Migrate DB Pro activeren
• Lokale database naar staging/production deployen via WP Migrate DB Pro

Het lijkt heel wat werk, zo uitgetypt, maar in feite ben ik er binnen 15 minuten klaar mee.
Daarna kan ik al m'n aanpassingen binnen no-time naar de andere omgevingen deployen, inclusief database. Het enig jammere aan WP Migrate DB Pro is dat het geen CLI interface heeft, maar daar werken ze aan.

[TheNephilim]

WP Migrate DB Pro ziet er wel grappig uit, al is dan 550 dollar nog wel weer een heel bedrag. Misschien een goed idee als ik alles helemaal 100% op de rit heb, nu is het nog vooral veel zoeken naar goede oplossingen.

Grappig, zo de work-flow eens te zien! De eerste twee komen ook voor bij mij, echter daarna gaan we toch verschillende kanten op. Dandelion kan ik niet gebruiken, ik werk hier achter een Windows machine en niet op OS X/Linux.

---

Stapsgewijs mijn work-flow en opmerkingen daarbij.

1. Eigen versie van VagrantPress clonen.

2. Nieuwe repository maken voor basetheme en Git remote veranderen naar deze nieuwe repository.

3. vagrant up om de nieuwe Vagrant installatie te starten.
Deze installeert Wordpress volgens de vooraf opgegeven specificaties, maar altijd onder localhost:8080/ met dezelfde wachtwoorden en dergelijke. Dus geen handmatige installatie meer, ook geen subdirs of weet ik wat.

4. Clone basetheme repository in /wp-content/themes/ van de VagrantPress Wordpress installatie.

5. Project maken in PhpStorm en aan de slag!
Hier stel ik een LESS compiler in, voeg ik een deployment FTP adres toe. De standaard 'preview' shizzle staat er al in (dacht ik). Alleen nog een 'productie' toevoegen. Heb hier nog niet zoveel mee gedaan, slechts één keer gebruikt Anyway, allemaal nog een boel werk te doen om het een beetje meer een 'flow' te maken.

---

Nog steeds een probleem is het hele VagrantPress gebeuren en mappenstructuur die erbij hoort. Als ik iets met submodules wil doen, moet ik een aparte repository van VagrantPress maken per project, naast de bestaande repo van het project.

VagrantPress ¹
-- wordpress ²
-- -- wp-content
-- -- -- themes
-- -- -- -- theme ³

1. Mijn eigen versie van VagrantPress. Aangepaste database file bijvoorbeeld, ik heb de standaard posts en pagina's niet nodig. Ook wat opties heb ik aangepast zoals de time zone.
2. Dit moet eigenlijk als bron de officiële Wordpress Git repo zijn, als submodule.
3. De repository van het thema. Dit is eigenlijk waar het om gaat... de rest is 100% bijzaak als het eenmaal draait en niet van belang op productie en ook niet op staging.

---

Als laatste probleem, maar dat is wellicht wat offtopic; de structuur van mijn thema's bevalt me nog niet helemaal. Nu is er in de thema folder, een mapje 'resources' te vinden met daarin js/img/css/less/fonts mapjes. In (bijv.) js/ zit dan nog bootstrap/ met alle Bootstrap shizzle en dat geld ook voor less. Liever heb ik dat allemaal bij elkaar, een mapje /vendor/ bijvoorbeeld. Met daarin Bootstrap en alle andere spullen van 3e partijen. Echter zit er weer verschil in statische content (js/css) en php files van bepaalde benodigde libraries. Weet nog niet wat ik hiermee wil. Misschien is het opsplitsen per vendor in de js/css/etc. mappen niet zo'n slecht idee en moet ik dat maar zo laten.

Op weg naar professioneler ontwikkelen... Het lijkt allemaal steeds ingewikkelder te worden zo Git valt wel mee, al maak ik daar nog geen optimaal gebruik van. Meestal even een commit aan het einde van de dag, een commit per onderdeel is echt nog veel werk in verhouding met de aanpassing zelf. Deployen word al wat makkelijker al moet ik nog zien hoe PhpStorm met meerdere 'doelen' omgaat.

In Wordpress ontwikkeling zelf valt ook nog een boel winst te halen. Volgens mij moeten we meer gebruik maken van Widget area's en voorgedefineerde opties. Echter maken de meeste klanten er toch geen gebruik van, al zou het hergebruik makkelijker kunnen maken. Het probleem wat dan opduikt is dat de ontwerpen vaak sterk afwijken van elkaar en je dan weer moet gaan hacken in plugins, waardoor ik dingen toch weer per project zelf in elkaar zet.

[Archiebald]

Wat is de reden dat je kiest voor een nieuwe repository op basis van de oude repository?

[Bigs]

Het voordeel van meerdere kleine commits ipv een grote aan het eind van de dag is niet alleen dat je makkelijk wijzigingen kunt terugdraaien, maar ook dat je achteraf voor je klant een mooi logboek hebt van wat je hebt gedaan (handig als er vragen komen over je factuur). Later zul je ook merken dat het dingen als rebasen overzichtelijker maakt.

Zelfs als ik meerdere wijzigingen in 1 bult werk doe dan commit ik die toch in stukjes, puur voor het overzicht.

[ Voor 26% gewijzigd door Bigs op 06-02-2014 11:29 ]

[TheNephilim]

Archiebald schreef op donderdag 06 februari 2014 @ 10:54:
Wat is de reden dat je kiest voor een nieuwe repository op basis van de oude repository?

De nieuwe code is fundamenteel anders dan waar je mee begint. Ik kan daarnaast eigenlijk nooit wijzigingen, die ik doe in de thema's, gebruiken in het basis thema.

Jij bedoeld dat ik branches maak voor ieder custom thema, dat gebaseerd is op het standaard thema?

Bigs schreef op donderdag 06 februari 2014 @ 11:28:
Het voordeel van meerdere kleine commits ipv een grote aan het eind van de dag is niet alleen dat je makkelijk wijzigingen kunt terugdraaien, maar ook dat je achteraf voor je klant een mooi logboek hebt van wat je hebt gedaan (handig als er vragen komen over je factuur). Later zul je ook merken dat het dingen als rebasen overzichtelijker maakt.

Zelfs als ik meerdere wijzigingen in 1 bult werk doe dan commit ik die toch in stukjes, puur voor het overzicht.

Klopt, dat is ook waar ik naartoe moet. Zal er wel eens mee experimenteren als dat kan. Ik moet naast het maken van een nieuwe work-flow en dergelijke, nog wel verder met nieuwe en oude projecten.

Zit nog met een mappenstructuur probleem, zoals ik hierboven al eens genoemd heb, maar daarvoor kan ik misschien beter een ander topic maken. Vagrant is een prachtige oplossing, maar hoe andere mensen dat met Git doen, is me een raadsel.

[Nedra]

Thx voor je uitgebreide uitleg v jouw workflow, inderdaad interessant om te zien hoe anderen het doen. Ik zou het leuk vinden als de mensen met interesse hierin hun ervaringen eens in de zoveel tijd zouden delen in dit topic!

Ik heb zelf geen ervaring met vagrant, maar kan je daar ook een virtuele host in aanmaken? Nu gebruik ik virtualhostx om een domeinnaam naar een lokale map te wijzigen zodat ik de betreffende website oproep met local.klantnaam.com (bijv).

Ik zal anders binnenkort even kijken of ik je workflow kan nadoen, het kan geen kwaad om af en toe eens te kijken hoe het anders kan

[TheNephilim]

Voor mij is het vooral interessant hoe ik kan verbeteren. Er is erg weinig te vinden over ontwikkelen in Wordpress op een professionele manier. Je komt dan vaak weer tips tegen die meer met het ontwikkelen van de code te maken hebben. Verder dan 'zet een lokale omgeving op en deploy met deze tool' komen ze vaak niet. Goed, nu ben ik lastig door alleen via FTP te kunnen deployen en weet ik wat voor uitzondering, maar goed.

Vagrant is eigenlijk gewoon een wrapper om een virtuele machine heen. In PhpStorm open je een project en kies je 'vagrant up' (bij Tools). Dan start hij de virtuele machine voor dat project. Als je aan een ander project wil werken, zet je de actieve vagrant weer uit en start je de vagrant van je andere project.

Kortom; je hebt continue localhost in gebruik. In mijn geval is het localhost:8080 en daar staat dan de website die je 'opgestart' hebt. Erg handig!

Andere mogelijkheden zijn natuurlijk om Wordpress lokaal ook gewoon als Network te installeren. Dan is het ook een kwestie van nieuwe website aanmaken en klaar. Zelf twijfel ik nog of dat voor mij niet makkelijker is. WAMP heb ik hier al draaien, daar dan WP Network installeren en per project een nieuwe website in het Network. Scheelt ook het installeren van plugins, die kun je voor een heel Network activeren bijv.

[Archiebald]

TheNephilim schreef op donderdag 06 februari 2014 @ 12:04:
[...]


De nieuwe code is fundamenteel anders dan waar je mee begint. Ik kan daarnaast eigenlijk nooit wijzigingen, die ik doe in de thema's, gebruiken in het basis thema.

Jij bedoeld dat ik branches maak voor ieder custom thema, dat gebaseerd is op het standaard thema?

Nou, het is meer dat een nieuwe repo meer werk is dan een nieuwe branch maken. Het switchen tussen een branch is volgens mij simpeler dan het switchen van repo.

Ik kan het mis hebben, maar volgens mij is het zo dat als je een repo kopieert naar een nieuwe repo. Je aan het forken bent.
Als je een nieuwe branch maakt die afgeleid is van de master, dan ben je aan het branchen.

Voor de rest lijkt me (zoals jij Vagrant beschrijft) Vagrant prima voor dat doeleinde.

Wat misschien een intressante term is voor je om alles te automatiseren: O(ntwikkeling) T(est) A(cceptatie) P(roductie). In het engels is dat DTAP.

[Nedra]

TheNephilim schreef op donderdag 06 februari 2014 @ 13:43:
Voor mij is het vooral interessant hoe ik kan verbeteren. Er is erg weinig te vinden over ontwikkelen in Wordpress op een professionele manier. Je komt dan vaak weer tips tegen die meer met het ontwikkelen van de code te maken hebben. Verder dan 'zet een lokale omgeving op en deploy met deze tool' komen ze vaak niet. Goed, nu ben ik lastig door alleen via FTP te kunnen deployen en weet ik wat voor uitzondering, maar goed.

Vagrant is eigenlijk gewoon een wrapper om een virtuele machine heen. In PhpStorm open je een project en kies je 'vagrant up' (bij Tools). Dan start hij de virtuele machine voor dat project. Als je aan een ander project wil werken, zet je de actieve vagrant weer uit en start je de vagrant van je andere project.

Kortom; je hebt continue localhost in gebruik. In mijn geval is het localhost:8080 en daar staat dan de website die je 'opgestart' hebt. Erg handig!

Andere mogelijkheden zijn natuurlijk om Wordpress lokaal ook gewoon als Network te installeren. Dan is het ook een kwestie van nieuwe website aanmaken en klaar. Zelf twijfel ik nog of dat voor mij niet makkelijker is. WAMP heb ik hier al draaien, daar dan WP Network installeren en per project een nieuwe website in het Network. Scheelt ook het installeren van plugins, die kun je voor een heel Network activeren bijv.

Persoonlijk vind ik het fijn niets hoven te starten, zolang de locale server draait (xampp in mijn geval) zijn al m'n dev sites beschikbaar onder hun eigen domeinnamen, met loc. ervoor. Wel realiseer ik me dat het voor minder verrassingen zorgt als je met zoiets als Vagrant de productie server emuleert. Doe je dat dan ook specifiek?

Overigens zijn niet alle plugins volledig multisite compatible, dat zou af en toe nog wel eens vervelend kunnen zijn als je alles op basis v nieuwe multi-site installaties doet.

[TheNephilim]

Nedra schreef op donderdag 06 februari 2014 @ 14:27:
[...]


Persoonlijk vind ik het fijn niets hoven te starten, zolang de locale server draait (xampp in mijn geval) zijn al m'n dev sites beschikbaar onder hun eigen domeinnamen, met loc. ervoor. Wel realiseer ik me dat het voor minder verrassingen zorgt als je met zoiets als Vagrant de productie server emuleert. Doe je dat dan ook specifiek?

Nee dat is ook eigenlijk niet nodig. Wordpress is geen deftig pakket en draait eigenlijk op alle voorkomende hosting. Ideaal is natuurlijk de laatste stabiele PHP versie, maar dat kun je wat betreft hosting toch vergeten. Meestal is het nog 5.2.x, maar gelukkig zie ik ook al redelijk wat 5.3.x. Helaas ben ik 5.4 of 5.5 nog niet tegengekomen.

Overigens zijn niet alle plugins volledig multisite compatible, dat zou af en toe nog wel eens vervelend kunnen zijn als je alles op basis v nieuwe multi-site installaties doet.

Nog geen problemen mee gehad. Liever laat ik dergelijke plugins sowieso links liggen. Niet dat ik zelf nou zulke geweldige code schrijf, maar wel binnen de Wordpress grenzen. Plugins die gebruik maken van methodes buiten Wordpress (db aanpassen, etc.) die haal ik liever niet in huis.

---

Status update

Misschien herhaal ik wat van de vorige iteratie, maar toch wil ik de huidige stand van zaken nog even delen.

Lokaal ontwikkelen

Netjes in een Wordpress Network, dat scheelt al best veel werk. Het enige wat nog een beetje bewerkelijk is, is de content. Bij de eerste ontwikkelfases maakt dat niet zoveel uit, maar als de websites eenmaal op de preview server staat en de klant met aanpassingen komt, ben je constant je content 2x aan het toevoegen. Niet zozeer pagina's en dergelijke, maar bepaalde velden of toevoegingen.

https://deliciousbrains.com/wp-migrate-db-pro/ biedt daar een oplossing voor. Ik kan dan de content van preview naar lokaal trekken en zo heb je toch up-to-date content. Echter is het wéér een extra element in de toolset en die wil ik zo klein mogelijk houden. Over de toolset later meer trouwens. Daarnaast zijn we met twee mensen en aan 4 actieve projecten heb je net niet genoeg. Dus moet je naar de 200 dollar per jaar, per persoon, beetje prijzig!

Nog een probleem, als mijn collega een aanpassing wil doen aan een project waaraan ik normaal gesproken werk; moet hij de git repo pullen en een Wordpress website aanmaken. Niet echt heel handig... Dat is natuurlijk het nadeel van lokaal ontwikkelen, maar zoiets moet toch makkelijker kunnen?

Deployment

Tot zover gaat dat best wel goed, gewoon met de IDE deployen, geen gezeur. Toch is dat niet helemaal handig, zeker met meerdere mensen niet. Je moet namelijk vaker dan eens de ftp-gegevens invullen. Slechts één persoon kan deployen, of moet toch weer de ftp-gegevens opscharrelen. Niet erg handig!

Toen kwam ik http://beanstalkapp.com/ tegen. Daar kan ik twee dingen doen; m'n git repo's kwijt en deployment instellen via ftp. Helemaal wat ik nodig heb!

Ondertussen heb ik eens een gratis testaccount aangemaakt. Daar kan ik met één repo eens kijken of het werkt. Dat gaat allemaal makkelijk, echt heel makkelijk. Na het toevoegen van een repo en het pushen van de files, kun je één of meerdere servers toevoegen en daarnaartoe deployen. Gewoon met een klik op een knopje en zelfs vanuit een mobiele app.

Echter kost dat wel wat centjes. 15 dollar, voor 10 repo's met maximaal 5 gebruikers. Dat betekend dat ik per project 1 euro, per maand, spendeer puur voor development. Voor 50 dollar kan ik al 50 projecten kwijt, dus het word met meer wel goedkoper, maar toch.

Nu wil ik graag alle projecten in één workflow houden. Dat is wel zo makkelijk en zal ook tijd besparen uiteindelijk. Alleen is het wel een beetje raar om websites waarvoor we (eenmalig) 400 euro (!) vangen, in een dergelijke tool te hangen. Dat kan eigenlijk niet uit.

Daar moet dus eigenlijk nog wat tussen. Alleen de projecten met een bepaald project, of de afnemers van ons onderhoud-pakket erin zetten. Dat kan, maar het is dan wel jammer dat je voor bepaalde projecten toch nog ouderwets met ftp aan de slag moet en dergelijke.

Git

Beanstalk had wat handige, duidelijke en vooral simpele guides (http://guides.beanstalkapp.com/). Daarin werd gepraat over verschillende branches. Naast development/staging/production, ook over feature branches. Kortom; ik voeg functionaliteit toe aan een website en maak voor het ontwikkelen ervan, een aparte branch, die ik later merge met development als het in orde is. Toch?

Goed, tijd om daar eens in te duiken dan. Ook hier geld weer, dat het voor sommige projecten echt veel te veel werk is om allerlei branches op te zetten.

Hoe zit het met bovenstaande branches, in combinatie met versienummers? Of zijn dat tags?

Nog veel uit te zoeken dus