Goede deployment strategie voor klein team (LAMP)

[Hmail]

Ik ben nu een tijdje aan het werk bij een klein softwarebedrijf met op dit moment 2 directe ontwikkelaars. Ik werk dus direct samen met 1 collega die redelijk thuis is in web-frontend ontwikkeling. Onze klanten zijn voornamelijk kleine bedrijven waar we websites voor ontwikkelen in eigen systemen (dus geen standaard frameworks, nagenoeg alles is zelfbouw).

De manier van deployment is al jaren hetzelfde geweest: Op 1 server staat een mapje met de mastercode, die wordt gecopy/paste naar een nieuwe map, daar worden klantspecifieke aanpassingen op gedaan (en e.v. bugs gefixed in de mastercode) en die wordt uiteindelijk via FTP online gezet. Er is dus 0 relatie tot andere systemen, als een bug op 1 plaats gefixed is moet dat op alle andere websites doorgevoerd worden. Het zal je niet verbazen dat functionaliteit dus nooit 1 op 1 over te zetten is. Verder worden bugfixes altijd via FTP gedaan, rechtstreeks op de productieomgeving.

Ik kom nu dus als ontwikkelaar op dit bedrijf kijken en heb voor een aantal websites waar regelmatig ontwikkelwerk in zit alvast een versiebeheer geïmplementeerd. Om e.e.a eenvoudig grafisch inzichtelijk te maken voor mijn collega's heb ik daarbij Stash geïnstalleerd. Van een paar projecten heb ik nu dus historie, de mogelijkheid te switchen tussen branches, etc, alle voordelen die git met zich meebrengt.

Voor het deployment loop ik echter nog tegen wat issues aan. Voor de meeste bedrijven zal testwerk een groot onderdeel uitmaken van hun deployment strategy, bij ons is het slechts een kwestie van compiles? ship it!. Ik ben nu dus op zoek naar een methode die vergelijkbaar werkt als via FTP (de editor biedt de mogelijkheid om commit+push te down) en dat deze wijziging automatisch uitgerold wordt op een testserver. Aan het eind kan een set wijzigingen dan handmatig online gezet worden op de productieserver. Ik kan hier niet echt goede ideëen voor vinden en kom eigenlijk alleen systemen tegen als Buildmaster en Bamboo. Dat lijkt me voor nu wat overkill, uiteindelijk zou ik wel graag bij zo'n systeem uit komen, maar ik zou het nu graag in stapjes doen, eerst een testserver, unit tests in de code, de concrete voordelen van een goede strategie duidelijk maken voor ons bedrijf, en dan een voorstel doen voor zo'n server.

Wat is jullie idee hierbij? Hoe zouden jullie zoiets aanpakken?

[kwaakvaak_v2]

Klinkt als een gevalletje http://www.deployhq.com/how goed inrichten en klaar.

[Hmail]

Hmm, ik moet eerlijk zeggen dat ik 6 pond per maand wel wat prijzig vind. Zeker als het gaat om een tussenstap om uiteindelijk zelf zo'n systeem in te richten (zoals dus Buildmaster of Bamboo). Ik denk dat dat me nog net een stap te ver is.

Zelf heb ik redelijk wat kennis op servergebied, en ik ben ook niet bang om wat shell scripts in elkaar te draaien, maar ik ben eigenlijk benieuwsd naar welke stappen jullie zouden nemen.

[kwaakvaak_v2]

als je 6 pond al te veel vind, moet je lekker blijven klooien en vooral niet de uren rekenen die jezelf werkt om een bestaand wiel te heruitvinden

[raptorix]

Wij gebruiken Bitbucket in Combi met Bamboo, moet wel zeggen dat geld hier niet echt een issue is, wij deployen niet automatisch naar productie of acceptatie, wel naar test.

[Hmail]

kwaakvaak_v2 schreef op maandag 16 december 2013 @ 13:40:
als je 6 pond al te veel vind, moet je lekker blijven klooien en vooral niet de uren rekenen die jezelf werkt om een bestaand wiel te heruitvinden

Bij het implementeren van zo'n deploy systeem komen ook uren die ik zelf werk. Ik vind het niet erg om uiteindelijk geld voor zo'n systeem te betalen maar als ik aan kom met een voorstel 72 pond per jaar "want iemand van tweakers vond het een goed idee" verwacht ik niet dat ik enthousiaste gezichten krijg.

raptorix schreef op maandag 16 december 2013 @ 13:41:
Wij gebruiken Bitbucket in Combi met Bamboo, moet wel zeggen dat geld hier niet echt een issue is, wij deployen niet automatisch naar productie of acceptatie, wel naar test.

Hoe doe je dat deployen? Is dat automatisch na een push? Of heb je hier nog stappen tussen zitten? Hoe rol je daarna uit naar acceptatie/productie? Ook vanuit Bamboo?

[Ultimation]

Je zou die branch weer moeten mergen met de master? Na die merge kan die op de master worden gezet? De master kan dan weer op productie worden uitgerold?

[ Voor 31% gewijzigd door Ultimation op 16-12-2013 14:12 ]

[Hydra]

Hmail schreef op maandag 16 december 2013 @ 13:23:
Wat is jullie idee hierbij? Hoe zouden jullie zoiets aanpakken?

Op zoek gaan naar een andere werkgever. Er is geen enkel excuus voor het niet hebben van een acceptatieomgeving waar je code op test.

[ Voor 17% gewijzigd door Hydra op 16-12-2013 14:16 ]

[Hmail]

Ultimation schreef op maandag 16 december 2013 @ 14:11:
Je zou die branch weer moeten mergen met de master? Na die merge kan die op de master worden gezet? De master kan dan weer op productie worden uitgerold?

Ja, dat is inderdaad uiteindelijk het idee. Het gaat me alleen om de manier waarop: Wat is een goede manier om de branches ervoor (dus een ontwikkel-branch b.v.) automatisch uit te rollen op een ontwikkelomgeving. Ik kan natuurlijk een shell script maken en die als hook in git hangen zodat direct na een push een pull gedaan wordt van de andere server, maar ik neem aan dat het gebruikelijk is dat hier nog stappen tussen zitten. Welke stappen zijn hierin verstandig?

[Ultimation]

Je rolt toch geen ontwikkelbranch uit? Je vergelijkt je productie omgeving met de laatste versie van de master branch?

Ik zou het zo doen:

Je hebt de master branch. Gezien werkzaamheden gepland worden (neem ik aan) hebben deze een nummer of iets dergelijk. Ik denk dat je een plan omgeving of iets hebt? Storyboard? Dan maak je (automatisch) een branch aan met dat nummer. Bijvoorbeeld project_branch_sprint1_task3.

Daarna ga je de werkzaamheden doen en verricht je de tests in die branch. Goedkeuring door iemand anders/2e test. Wanneer akkoord merge met master branch + conflicten resolven (dat moet eigenlijk ook weer getest worden). Dan zijn die wijzigen verwerkt in de master branch.

De software die op de productie servers staat laat zichzelf/automagisch vergelijken met de revisie die op GIT staat en vanaf daar de laatste versie halen. Je kan ook zien per update welke bestanden zijn aangepast, die laat je updaten door software op de productieservers. Dan heb je er zelf geen nakijken meer aan. Natuurlijk moet je die software ook met een commando kunnen laten updaten wanneer het om hele kritieke updates gaat.

Hier op stage wordt een Python project gedraaid waarbij ze .pkg bestanden maken nadat de Jenkingstests geslaagd zijn. Die worden in een VM-template gezet en via Puppet uitgerold. Best een mooi proces om te zien.

[ Voor 8% gewijzigd door Ultimation op 16-12-2013 14:46 ]

[raptorix]

Hmail schreef op maandag 16 december 2013 @ 14:20:
[...]

Ja, dat is inderdaad uiteindelijk het idee. Het gaat me alleen om de manier waarop: Wat is een goede manier om de branches ervoor (dus een ontwikkel-branch b.v.) automatisch uit te rollen op een ontwikkelomgeving. Ik kan natuurlijk een shell script maken en die als hook in git hangen zodat direct na een push een pull gedaan wordt van de andere server, maar ik neem aan dat het gebruikelijk is dat hier nog stappen tussen zitten. Welke stappen zijn hierin verstandig?

Wij gebruiken MSBuild, commits op de Dev branches gaan naar de DEV server, en commits op Master naar test. Overigens zou je eventueel ook TeamCity kunnen gebruiken voor automatische builds.

[raptorix]

Ultimation schreef op maandag 16 december 2013 @ 14:42:
Je rolt toch geen ontwikkelbranch uit? Je vergelijkt je productie omgeving met de laatste versie van de master branch?

Ik zou het zo doen:

Je hebt de master branch. Gezien werkzaamheden gepland worden (neem ik aan) hebben deze een nummer of iets dergelijk. Ik denk dat je een plan omgeving of iets hebt? Storyboard? Dan maak je (automatisch) een branch aan met dat nummer. Bijvoorbeeld project_branch_sprint1_task3.

Daarna ga je de werkzaamheden doen en verricht je de tests in die branch. Goedkeuring door iemand anders/2e test. Wanneer akkoord merge met master branch + conflicten resolven (dat moet eigenlijk ook weer getest worden). Dan zijn die wijzigen verwerkt in de master branch.

De software die op de productie servers staat laat zichzelf/automagisch vergelijken met de revisie die op GIT staat en vanaf daar de laatste versie halen. Je kan ook zien per update welke bestanden zijn aangepast, die laat je updaten door software op de productieservers. Dan heb je er zelf geen nakijken meer aan. Natuurlijk moet je die software ook met een commando kunnen laten updaten wanneer het om hele kritieke updates gaat.

Hier op stage wordt een Python project gedraaid waarbij ze .pkg bestanden maken nadat de Jenkingstests geslaagd zijn. Die worden in een VM-template gezet en via Puppet uitgerold. Best een mooi proces om te zien.

Ja zo ongeveer dus, bij ons is Jira leidend qua versie nummers, wij gebruiken ook GitFlow voor het juist beheren van de branches: http://nvie.com/posts/a-successful-git-branching-model/

Wij releasen altijd vanaf Master, naar Acceptatie/Prod, op het moment dat er dus een hotfix plaats moet vinden kun je dat eenvoudig vanaf de Master branch doen en vervolgens weer terugmergen naar bijvoorbeeld de Development branche.

[kwaakvaak_v2]

Hmail schreef op maandag 16 december 2013 @ 14:09:
[...]

Bij het implementeren van zo'n deploy systeem komen ook uren die ik zelf werk. Ik vind het niet erg om uiteindelijk geld voor zo'n systeem te betalen maar als ik aan kom met een voorstel 72 pond per jaar "want iemand van tweakers vond het een goed idee" verwacht ik niet dat ik enthousiaste gezichten krijg.

Daarom kun je met het free account binnen 1 uurtje uitzoeken of het product doet wat het moet doen of niet.

Is denk ik nog steeds sneller dan zelf in 1 of meerdere dagen iets in elkaar te scripten/testen etc.

[TheNephilim]

Handig topic! Zal nog eens wat nalezen en bekijken als ik tijd heb.

Ik begrijp dat je van een bedrijf komt waar dergelijke dingen wel al gebruikt werden. En dat je nu bij een (voor jou) nieuw bedrijf aan de slag bent, waar dit nog niet het geval is. Toch?

kwaakvaak_v2 heeft wel een punt inderdaad. Je kunt misschien nu denken tijd te hebben voor het opzetten van een dergelijke omgeving, maar voor je alle puntjes op de i hebt... Dan komen er ook nog updates om de hoek kijken, of een andere manier van werken. Als je dan al tot over je oren in het werk zit, gaat het steeds verder achterlopen en ben je beter af met een kant en klare oplossing.

offtopic:
Wij zitten hier met twee mensen, ook webdevelopment, met hetzelfde probleem. De laatste keer dat we hier na (git/deploy/etc.) gekeken hebben, kwam ik tot het oordeel dat de projectjes simpelweg te klein zijn voor een deployment strategie. De 'basis' zetten we wel in git, net als andere onderdelen die terug komen.

Maar, voor elk project een repo/branch/oid. en een deployment strategie? Nee dat kan echt niet uit...

[Ultimation]

Deze manier van werken gaat wel veel voordelen bieden ten aanzien van je traditionele 'we kopiëren alles via FTP' manier van werken. Omdat je dit automatiseert maak je straks veel minder fouten en heb je een standaard workflow voor je werkzaamheden. Ook later wanneer het bedrijf verder groeit heb je hier veel profijt van.

Ik denk persoonlijk dat deze manier van werken uiteindelijk ook geld bespaard en het risico op menselijk falen verminderd omdat je het automatiseert.

[Hydra]

TheNephilim schreef op maandag 16 december 2013 @ 15:32:
Wij zitten hier met twee mensen, ook webdevelopment, met hetzelfde probleem. De laatste keer dat we hier na (git/deploy/etc.) gekeken hebben, kwam ik tot het oordeel dat de projectjes simpelweg te klein zijn voor een deployment strategie. De 'basis' zetten we wel in git, net als andere onderdelen die terug komen.

Ik vind het volkomen bizar dat er nog developers zijn die code niet / niet alle code in een sourcecontrol system hebben staan. Je hebt de code zeker volstaan met uitgecommente stukken die je "misschien nog een keer nodig hebt"?

[TheNephilim]

Hydra schreef op maandag 16 december 2013 @ 16:08:
[...]


Ik vind het volkomen bizar dat er nog developers zijn die code niet / niet alle code in een sourcecontrol system hebben staan. Je hebt de code zeker volstaan met uitgecommente stukken die je "misschien nog een keer nodig hebt"?

De code staat niet vol met allerlei outcommented code... het basisthema bevat wel enkele standaard 'onderdelen', die desgewenst gebruikt worden of niet. Bij aanmaken project (en kopiëren van basis thema) halen we (bijv.) ongebruikte post types weg (Wordpress hè).

We maken Wordpress thema's, voor (over het algemeen) simpele bedrijfswebsites. Af en toe een webshop, soms een wat groter project, maar het blijft allemaal vrij kleinschalig. De meeste websites zijn binnen een week klaar, en na oplevering horen we er jaren niks meer van. Tot de klant een aanpassing wil, of verhuist en niet meer kan vinden waar hij/zij het adres in de footer moet wijzigen.

Wat we wel in Git (lees Bitbucket) hebben staan, zijn de basis en enkele plugins. Dus waarop we steeds beginnen met bouwen (een parent theme), daarvoor gebruiken we wel git. Deployment is helemaal geen beginnen aan, het betreft altijd simpele consumenten hosting, waar we ftp en database gegevens van krijgen. Wordpress uploaden en installeren is nou niet bepaald rocket-science.

Ik snap de kritiek, maar per project git/deployment/etc. kost meer tijd dan het project zelf

[ Voor 9% gewijzigd door TheNephilim op 16-12-2013 17:03 ]

[Barryvdh]

Heel simpel kan je ook gewoon 2 versies beheren:
- ontwikkelomgeving
- productieomgeving

Ontwikkelen/testen/etc op je ontwikkelomgeving, wijzigingen opslaan in versiebeheer (Bitbucket is gratis voor kleine teams). Het enige wat je dan op je productieomgeving doet is de nieuwste versie ophalen vanuit Git (als je dus een 'stable' versie hebt. Voordeel met Git is dus ook dat als er toch iets fout was, je snel terug kan naar een vorige versie. Daarna kan je het uitbreiden zover je wil. Dus met git branches etc werken, meerdere omgevingen (per ontwikkelaar, losse acceptatie/staging server etc) of automatisch scripts draaien.

Wij gebruiken zelf tegenwoordig vooral Laravel en dan Rocketeer voor deployments. Dan kunnen we vanuit onze lokale server automatisch deployments doen. Rocketeer logt dan in via SSH op de productieserver, download de laatste versie in een nieuwe map, draait wat scripts (database migraties, composer install, assets maken, rechten goedzetten) en als hij klaar is, veranderd hij de symlink naar de nieuwe release map. Mocht er iets fout gaan kan je dus snel teruggaan naar de vorige versie door alleen de symlink aan te passen. Daarnaast worden bepaalde mappen (logs, uploads ed. ) gedeeld zodat die voor elke release bewaard blijven.
En met hostname detectie kan je detecteren welke omgeving je zit (kan Laravel automatisch iig) en op basis daarvan een andere database, error_reporting etc gebruiken.
Om een nieuwe versie online te zetten hoef ik dus (als de nieuwste versie in Git staat) dus alleen in te typen 'php artisan deploy' en een minuutje later staat alles online, zonder enige downtime.

Zonder Laravel kan je zoiets ook met Capistrano volgens mij (al komt Rocketeer binnenkort ook stand-alone, nu al op de development branch)

[Hmail]

Erg handige replies, thanks! Ik snap dat e.e.a verwarrend kan zijn voor ontwikkelaars die dagelijks met de allerbeste technieken hun werk van editor tot productie kunnen brengen, maar helaas is nog niet ieder bedrijf zover Het is dan vanuit het verleden zo gegroeid en zo lang er geen kalf verdrinkt lijkt het dempen van de put toch nog een erg grote stap.
Mijn idee is om uiteindelijk een goede manier te krijgen waarbij deployment vanzelfsprekend wordt i.p.v: Hier is een dure tool, daarmee voorkomen we problemen die we nu nog niet zien.

Ik denk dat Rocketeer en Capistrano ongeveer de tools zijn waar ik nu direct naar op zoek was, de andere systemen komen denk ik pas in de volgende stap van het proces naar voren maar de replies zijn erg bruikbaar om alvast over na te denken.

Stash heb ik op een vergelijkbare manier geïmplementeerd: Eerst de code via git laten doen, wachten op het commentaar dat het toch wel lastig is om snel een goed beeld te krijgen van de commits, dan voorstellen om een grafische tool te gaan gebruiken a la Bitbucket zodat het inzichtelijker wordt. De volgende stap is geautomatiseerde deployments, daarna ze duidelijker inzichtelijker maken.

TheNephilim schreef op maandag 16 december 2013 @ 17:00:
[...]
Ik snap de kritiek, maar per project git/deployment/etc. kost meer tijd dan het project zelf

Het jammere is dat dat idee bij ons bedrijf ook aanwezig is terwijl de projecten toch behoorlijk fors van aard zijn. Per slot van rekening is alles in-house ontwikkeld, en daar zit dus behoorlijk wat onderhoudswerk in. Door de voordelen van controle, workflow, kwaliteitsgaranties, automatiseren van handwerk hier tegenover te stellen denk ik dat we een aardig eind komen.
Maar dat is een lastige weg. Zeker als je dagelijkse werkzaamheden bestaan uit even snel een css aanpassing doorvoeren zodat de website ook op $useragent er goed uit ziet dan lijkt een deployment-traject met allerlei stappen meer op het bazooka-mug werk Het is dus zoeken om aan beide belangen te voldoen. En ik geloof dat ik hier een aantal erg bruikbare tips heb.

[ Voor 28% gewijzigd door Hmail op 16-12-2013 21:13 ]

[raptorix]

Wat vind je duur? Ik vind 20K helemaal niet duur als je beseft dat het van essentieel belang is dat dit soort zaken goed geregeld zijn, nu hebben wij ook klanten die 500K per dag op internet omzetten, dus dan is het niet normaal dat je ook geld voor dit soort dingen uitgeeft, maar mijn ervaring is dat je nooit mag besparen op goede tooling, al was het alleen al omdat je het geld heel simepel terug verdient.

[Hydra]

TheNephilim schreef op maandag 16 december 2013 @ 17:00:
Ik snap de kritiek, maar per project git/deployment/etc. kost meer tijd dan het project zelf

"git pull", nou, wat een werk!

Hou op met excuses te verzinnen. Die zijn er niet.

Hmail schreef op maandag 16 december 2013 @ 20:56:
Erg handige replies, thanks! Ik snap dat e.e.a verwarrend kan zijn voor ontwikkelaars die dagelijks met de allerbeste technieken hun werk van editor tot productie kunnen brengen, maar helaas is nog niet ieder bedrijf zover

Sorry hoor, maar dat is echt onzin. Deze "allerbeste technieken" zijn ten eerste extreem basaal, en ten tweede gewoon open source en dus gratis.

Het is dan vanuit het verleden zo gegroeid en zo lang er geen kalf verdrinkt lijkt het dempen van de put toch nog een erg grote stap.

Vanuit het heden zo gegroeid is wederom geen enkel excuus. Dat het nog nooit misgegaan is, is geen excuus omdat iedereen met het IQ hoger dan een wortel snapt dat dit niet de juiste manier van werken is.

Niemand verwacht dat je een volledige OTAP straat ofzo opzet, maar een 'test' omgeving waar je spul deployed en test is echt het minimum, en source-control is gewoon een complete must. Rechtstreeks op productie dingen fixen is zo enorm dom dat zelfs het hebben van maar 1 klant met een site die door niemand ooit bekeken is geen enkel excuus is: al mijn eigen zut, die niemand ooit gaat zien, staat gewooon in een git repo, puur en alleen omdat sourcecontrol een must is.

En ja, ik reageer wat boos omdat dit soort beunhazerij de reden is dat IT projecten een slechte naam hebben.

[ Voor 9% gewijzigd door Hydra op 16-12-2013 21:45 ]

[Hmail]

raptorix schreef op maandag 16 december 2013 @ 21:36:
Wat vind je duur? Ik vind 20K helemaal niet duur als je beseft dat het van essentieel belang is dat dit soort zaken goed geregeld zijn, nu hebben wij ook klanten die 500K per dag op internet omzetten, dus dan is het niet normaal dat je ook geld voor dit soort dingen uitgeeft, maar mijn ervaring is dat je nooit mag besparen op goede tooling, al was het alleen al omdat je het geld heel simepel terug verdient.

Helaas hebben wij niet dat soort klanten Duur zit hem voornamelijk in het aanlooptraject; het vinden van de beste tool voor onze situatie, en het ervaren raken met zulke tools. Ik ben ook zeker niet bang om er wat geld tegenaan te gooien, en een paar tientjes aanschafprijs zijn ook zeker wel te verdedigen, alleen moet ik wel goed weten wat voor concrete voordelen ze op de korte én lange termijn bieden.

Ik ga morgen maar eens met wat verschillende tools spelen en werken aan een plan voor goede implementatie.

[raptorix]

@hydra eens, er zijn ook tussenwegen, zo kun je een acceptatie desnoods fysiek naast een prod omgevig zetten, op die manier kun je functioneel op een gescheiden omgeving testen zonder dat dit echt extra geld kost, en een lokale GIT repository hoeft ook niet zoveel te kosten, hoewel de kosten van een backup plan waarschijnlijk duurder zijn dan hosted.

[raptorix]

Hmail schreef op maandag 16 december 2013 @ 22:01:
[...]

Helaas hebben wij niet dat soort klanten Duur zit hem voornamelijk in het aanlooptraject; het vinden van de beste tool voor onze situatie, en het ervaren raken met zulke tools. Ik ben ook zeker niet bang om er wat geld tegenaan te gooien, en een paar tientjes aanschafprijs zijn ook zeker wel te verdedigen, alleen moet ik wel goed weten wat voor concrete voordelen ze op de korte én lange termijn bieden.

Ik ga morgen maar eens met wat verschillende tools spelen en werken aan een plan voor goede implementatie.

Zoals gezegt is bitbucket voor kleine teams gratis, en dan heb je volgens mij ook nog eens Jira, ik zeg gewoon doen

[Hmail]

raptorix schreef op maandag 16 december 2013 @ 22:03:
[...]

Zoals gezegt is bitbucket voor kleine teams gratis, en dan heb je volgens mij ook nog eens Jira, ik zeg gewoon doen

We hebben Stash, dat is de enterprise variant voor bitbucket. Is wat overkill maar je weet zeker dat je de code in eigen beheer houdt. Dat was een wens en voor 10$ is zelfs een minuut daarover discussieren te duur Daar hebben we alleen geen Jira bij, maar dat is dezelfde prijs voor zo'n klein team, dus dat ga ik op korte termijn ook installeren.

[raptorix]

Hmail schreef op maandag 16 december 2013 @ 22:08:
[...]

We hebben Stash, dat is de enterprise variant voor bitbucket. Is wat overkill maar je weet zeker dat je de code in eigen beheer houdt. Dat was een wens en voor 10$ is zelfs een minuut daarover discussieren te duur Daar hebben we alleen geen Jira bij, maar dat is dezelfde prijs voor zo'n klein team, dus dat ga ik op korte termijn ook installeren.

Wij moesten in een relatief korte periode zowel onze source repositories als Jira migreren, Atalassian kon ons redelijk goede deal doen hoewel we ook een duitse partij hebben overwogen. Moet zeggen dat het redelijk soepeltjes liep, al was Jira wel een pain in the ass, omdat we bijna 8 jaar Jira moesten migreren

[TheNephilim]

Hydra schreef op maandag 16 december 2013 @ 21:43:
[...]


"git pull", nou, wat een werk!

Nee ik ontwikkel niet lokaal, maar op een test/preview/ontwikkel server waar de klant ook kijkt om te zien of het naar wens is. Dus een git pull is niet helemaal aan de orde Al zal je vast ook git op de server kunnen installeren en daar push/pull kunnen doen (met ssh). Echt handig is het allemaal echter niet

[kwaakvaak_v2]

smoesjes om er voor jezelf vooral geen tijd in hoeven te steken

Wij werken hier momenteel ook met een team van 3 ontwikkelaars, en het kost net zoveel moeite om even een git pull te doen, dan met FTP in te loggen en de boel te syncen. Niet dat wij dat doen overigens!


Voor projecten (dat is er precies 1 ivm een paranoia semi-overheid klant) waarbij direct op een remote server gewerkt moet worden, is de intergratie van sync en git in phpstorm erg geschikt.

De code staat op de server, phpstorm doet bij het opzetten van het project een sync waarbij alle bestanden lokaal gehaald worden. Die bestanden gaan in GIT (vanaf lokaal dus geen SSH nodig), bij opslaan wordt het naar de server ge-upload.Tussendoor doe ik regelmatig een commit zonder push naar origin (git remote) en als de feature klaar is een push.

Het is zoals ik hierboven ook al probeerde duidelijk te maken, vooral een kwestie van je toolchain goed inrichten en gewoon doen. En dat laatste ging hier ook niet zonder gemopper, want ze waren ruim 8 jaar gewend om het met ~backup mapjes etc te doen. Maar nu wil eigenlijk niemand meer zonder, vooral omdat GIT hun kont een paar keer gered heeft in belangrijke stressvolle projecten waarbij iemand per ongeluk de hele CSS folder van de server had weg gemikt etc.

[ Voor 3% gewijzigd door kwaakvaak_v2 op 17-12-2013 10:13 . Reden: nuancering ]

[Ultimation]

PHPStorm is inderdaad een mooie IDE waarbij dat goed werkt. Gebruikt het zelf ook.

[TheNephilim]

kwaakvaak_v2 schreef op dinsdag 17 december 2013 @ 10:11:Het is zoals ik hierboven ook al probeerde duidelijk te maken, vooral een kwestie van je toolchain goed inrichten en gewoon doen.

Dat! Dat is denk ik mijn grote probleem. Ik heb hier namelijk PhpStorm en heb het (bij aanschaf paar maanden geleden) helemaal geprobeerd met projecten/git/etc. Maar ... het was zo'n enorm geklooi dat ik er heeeeel snel klaar mee was .

Zou nog steeds niet weten hoe ik dat voor elkaar moet krijgen in PhpStorm, maar jou reactie zegt me dat het toch heel makkelijk moet kunnen.

[kwaakvaak_v2]

Wat wij doen is een beetje een combo van onderstaande video's, maar ipv commerciele GIT oplossing hebben we een VPS met gitlab erop.

http://blog.jetbrains.com...without-leaving-phpstorm/
http://tv.jetbrains.net/v...-intellij-idea-based-ides
http://tv.jetbrains.net/v...m-phpstorm-video-tutorial

[ Voor 3% gewijzigd door kwaakvaak_v2 op 17-12-2013 10:54 ]

[Hydra]

raptorix schreef op maandag 16 december 2013 @ 22:02:
@hydra eens, er zijn ook tussenwegen, zo kun je een acceptatie desnoods fysiek naast een prod omgevig zetten, op die manier kun je functioneel op een gescheiden omgeving testen zonder dat dit echt extra geld kost, en een lokale GIT repository hoeft ook niet zoveel te kosten, hoewel de kosten van een backup plan waarschijnlijk duurder zijn dan hosted.

Dan kun je beter een oude desktop als acceptatie gebruiken. Op productie draait alleen productie. Als jij door een fout al het geheugen gebruikt op een A/P systeem crashed dat alsnog gewoon, en zelfs gescheiden VMs kunnen impact hebben op elkaar.

TheNephilim schreef op dinsdag 17 december 2013 @ 09:51:
Nee ik ontwikkel niet lokaal, maar op een test/preview/ontwikkel server waar de klant ook kijkt om te zien of het naar wens is. Dus een git pull is niet helemaal aan de orde Al zal je vast ook git op de server kunnen installeren en daar push/pull kunnen doen (met ssh). Echt handig is het allemaal echter niet

Slap gelul, sorry.

[Miyamoto]

Interessante discussie, op het gesnauw van Hydra na.

Onbekend is onbemind. Het is makkelijk roep als je ervaren bent met de tools dat degenen die het niet gebruiken kortzichtig zijn en stom. Maar misschien zijn dergelijke tools niet voor iedereen zo basic. Je hebt een punt dat er veel gebeund wordt in de IT, maar ik kan uit de posts van TS niet opmaken dat dat hier aan de hand is. Geen enkel (ok, vast wel een enkele...) software bedrijf start met een volledige 100% juiste (sowieso: wat is juist?) toolchain en configuratie. Al doende leert men.
TS kan bovendien wel een pakket aanschaffen, onder het mom "er over praten is al te duur", maar dat geldt alleen als duidelijk is wat een pakket doet en kan doen. Vandaar zijn vraag volgens mij ook.

Het feit dat er meerdere ideeën worden aangedragen bewijst ook dat er dus geen ideale oplossing is, maar dat deze afhankelijk zijn van verschillende factoren. Zaak is dus om deze duidelijk te krijgen.

[PatrickH89]

Waarbij (ondanks de manier hoe Hydra dit uit) ik het wel eens ben met dat je tegenwoordig niet meer weg (zou moeten kunnen) kunt komen met op productie aanpassingen maken en geen versiebeheer gebruiken.

[danslo]

Jij mag het gesnauw vinden, wat Hydra zegt klopt gewoon. Tuurlijk heeft niet elk ontwikkel bedrijf (vooral beginnend) een volledige OTAP stack voor elke klant, en ander fancy spul als integratie tests, een eigen deployment server (denk jenkins/hudson), etc.

Maar het allerminste wat je zou verwachten is:

1. Versiebeheer. Absoluut essentieel. Hint: Bitbucket heeft oneindig gratis private repositories.
2. Scheiding tussen productie en je andere omgevingen.
3. Een goed branching model. Deze is redelijk populair.
4. Een simpele deployment strategie. DeployHQ is hiervoor echt ideaal. En als je 7 pond per maand teveel vind dan vraag ik me af met welke klanten je bezig bent. Met hun webhooks (die prima met bitbucket samenwerken) kan je ook automatische deployments instellen na een push op een bepaalde branch (bijv develop naar test, master naar productie).

Ga alsjeblieft niet het wiel opnieuw proberen uit te vinden - begin gewoon met een goede basis. Daarna kan je e.v.t. verder kijken.

[ Voor 5% gewijzigd door danslo op 17-12-2013 12:28 ]

[Barryvdh]

DeployHQ ziet er wel interessant uit trouwens. Volgens mij een beetje hetzelfde principe als wat ik doe, alleen doe ik het via command line en de configuratie in php.
En je kan er dus 1 gratis proberen en daarna zo'n 50 cent per maand per project, lijkt me ook wel betaalbaar inderdaad.

[Hydra]

Miyamoto schreef op dinsdag 17 december 2013 @ 12:07:
Interessante discussie, op het gesnauw van Hydra na.

Sorry maar ik heb gewoon een lage bullshittolerantie. Er is geen enkel excuus om niet al je code in een DVCS te hebben.

Barryvdh schreef op dinsdag 17 december 2013 @ 12:36:
DeployHQ ziet er wel interessant uit trouwens. Volgens mij een beetje hetzelfde principe als wat ik doe, alleen doe ik het via command line en de configuratie in php.

Ik ben niet zo'n fan van het laten rondslingeren van Amazon keys en login informatie tenzij dit gewoon 100% noodzakelijk is. Dus ik vind er best wat voor te zeggen dat je deployment gewoon met eigen scripts doet. Zelf hebben wij ook een simpel script om acceptatie naar productie te syncen, da's gewoon command-line gebaseerd. Maar claimen dat iets basaals als git 'te veel moeite' kost is echt enorme onzin, dat is gewoon luiheid en niet de moeite nemen ff te wennen aan iets als git. Een deploy van een master branch hoeft echt niet meer werk zijn dan "git pull" in de commandline in te typen.

[ Voor 59% gewijzigd door Hydra op 17-12-2013 13:08 ]

[kwaakvaak_v2]

ik neem aan de amazon toch ook wel iets van deploykeys heeft?

[Hydra]

kwaakvaak_v2 schreef op dinsdag 17 december 2013 @ 14:11:
ik neem aan de amazon toch ook wel iets van deploykeys heeft?

Ik weet zelf niet enorm veel van amazon (doet beheer voor ons), maar je wil niet de 'verkeerde' keys publiek laten:
http://vertis.io/2013/12/...ised-litecoin-mining.html

[cytherea]

Helemaal eens dat je alles versiebeheer moet krijgen en van daaruit deployen op welke manier dan ook.

Alleen zelf heb ik vaak genoeg meegemaakt dat een andere ontwikkelaar de manier van werken niet begrijpt (of wil begrijpen) en het rechtstreeks hacken via FTP wel makkelijk vind. Het opvoeden van de rest is nog een flinke uitdaging en niks is zo erg als vanuit git deployen en daarbij wijzigingen van een ander mee te overschrijven.

Ik zou dit soort systemen en methoden van werken vooral stap voor stap introduceren en misschien bij een project op proef en vooral iedereen erin betrekken. Met alleen fancy tools ben je er nog niet, de mensen moeten ook meewillen.

[TheNephilim]

cytherea schreef op dinsdag 17 december 2013 @ 14:35:
Ik zou dit soort systemen en methoden van werken vooral stap voor stap introduceren en misschien bij een project op proef en vooral iedereen erin betrekken. Met alleen fancy tools ben je er nog niet, de mensen moeten ook meewillen.

Juist de tools die het makkelijk zouden moeten maken, horen de drempel te verlagen voor mensen die er eigenlijk mee moeten werken... toch?

[Hydra]

TheNephilim schreef op dinsdag 17 december 2013 @ 14:38:
Juist de tools die het makkelijk zouden moeten maken, horen de drempel te verlagen voor mensen die er eigenlijk mee moeten werken... toch?

Het probleem is gewoon dat een hoop developers excuses verzinnen om dingen maar niet anders te hoeven doen, ook als die excuses nergens op slaan.

[cytherea]

TheNephilim schreef op dinsdag 17 december 2013 @ 14:38:
[...]


Juist de tools die het makkelijk zouden moeten maken, horen de drempel te verlagen voor mensen die er eigenlijk mee moeten werken... toch?

Klopt, zo zie ik het ook. Maar mensen die het al jaren via FTP doen zijn heel moeilijk aan versiebeheer en een professionele ontwikkel workflow te krijgen. Heb het al een aantal keer meegemaakt en uiteindelijk maar opgegeven en vertrokken.

[Barryvdh]

cytherea schreef op dinsdag 17 december 2013 @ 14:35:
Helemaal eens dat je alles versiebeheer moet krijgen en van daaruit deployen op welke manier dan ook.

Alleen zelf heb ik vaak genoeg meegemaakt dat een andere ontwikkelaar de manier van werken niet begrijpt (of wil begrijpen) en het rechtstreeks hacken via FTP wel makkelijk vind. Het opvoeden van de rest is nog een flinke uitdaging en niks is zo erg als vanuit git deployen en daarbij wijzigingen van een ander mee te overschrijven.

Ik zou dit soort systemen en methoden van werken vooral stap voor stap introduceren en misschien bij een project op proef en vooral iedereen erin betrekken. Met alleen fancy tools ben je er nog niet, de mensen moeten ook meewillen.

Gewoon die ontwikkelaars geen toegang geven tot de productieserver. Kan het ook niet per ongeluk verkeerd gaan.
En ik neem aan dat hij het ook snel afleert, of gaat hij steeds aan zijn baas uitleggen dat hij een dag werk kwijt is omdat hij vertikt op de goede manier te werken?

Wat je, als tussenstap, ook kan doen is een lokale (gedeelde) server op zetten en daar werk je op, net zoals je vroeger zou doen. Bijvoorbeeld als je stagiairs/front-enders etc die geen git denken te kunnen gebruiken. Dan kan je vanaf die server pushen naar versiebeheer en na testen etc, push je vanaf daar ook naar productie. Dan heb je wel alles in versiebeheer staan en losse omgevingen, maar is de overgang makkelijker. Maar dat werkt natuurlijk alleen in kleine teams (bijvoorbeeld 1 programmeur, 1 front-ender/ontwerper die tegelijk werken)

[Hydra]

cytherea schreef op dinsdag 17 december 2013 @ 14:44:
Klopt, zo zie ik het ook. Maar mensen die het al jaren via FTP doen zijn heel moeilijk aan versiebeheer en een professionele ontwikkel workflow te krijgen. Heb het al een aantal keer meegemaakt en uiteindelijk maar opgegeven en vertrokken.

Dat hoort ook opgelegd te worden vanuit je CIO (/lead dev), whatever. Als dat niet gebeurt en mensen door blijven klooien kun je inderdaad beter een betere baan zoeken. Leer je waarschijnlijk ook meer.

[TheNephilim]

Hydra schreef op dinsdag 17 december 2013 @ 14:42:
[...]


Het probleem is gewoon dat een hoop developers excuses verzinnen om dingen maar niet anders te hoeven doen, ook als die excuses nergens op slaan.

Wat, als je het wel heel graag wil, maar niet voor elkaar krijgt? Mja, zal wel weer eens een topic openen ofzo. Eerst maar eens dat hier eerder genoemde lijstje helemaal volgen en lezen.

[Hydra]

TheNephilim schreef op dinsdag 17 december 2013 @ 15:06:
Wat, als je het wel heel graag wil, maar niet voor elkaar krijgt? .

Andere baan zoeken. Serieus. Je wil als beginner niet bij zo'n toko werken. Je leert veel meer bij een bedrijf dat z'n zaakjes op orde heeft.

[TheNephilim]

Hydra schreef op dinsdag 17 december 2013 @ 15:25:
[...]


Andere baan zoeken. Serieus. Je wil als beginner niet bij zo'n toko werken. Je leert veel meer bij een bedrijf dat z'n zaakjes op orde heeft.

Er moet altijd iemand de eerste zijn hè

[kwaakvaak_v2]

Ja maar Hydra heeft wel een punt, je moet het gewoon afdwingen!.

Wij zijn hier gewoon gestopt met het live zetten van kleine wijzigingen als het niet in GIT stond en alle access via FTP gewoon ingetrokken.

Heeft ongeveer 2 weken gemopper en gesteun opgeleverd, maar nadat de klagers even bij het grote operhoofd (lees directie) mochten komen uitleggen waarom x nog niet live stond bij y was het vrij snel gedaan met het klagen.

Stap 1 is dus, zorg dat je het management mee hebt, en de ervaring is dat die vrij snel over zijn als je ze verteld dat er gewoon minder ruimte is voor fouten en je gelijk kunt zien wie de fout heeft geintroduceerd.

Ik geloof ook niet in het gefaseerd invoeren van dit soort triviale veranderingen, ets met zachte heelmeesters en gapende wonden.

[TheNephilim]

kwaakvaak_v2 schreef op dinsdag 17 december 2013 @ 16:19:
Ja maar Hydra heeft wel een punt, je moet het gewoon afdwingen!.

Wij zijn hier gewoon gestopt met het live zetten van kleine wijzigingen als het niet in GIT stond en alle access via FTP gewoon ingetrokken.

Heeft ongeveer 2 weken gemopper en gesteun opgeleverd, maar nadat de klagers even bij het grote operhoofd (lees directie) mochten komen uitleggen waarom x nog niet live stond bij y was het vrij snel gedaan met het klagen.

Stap 1 is dus, zorg dat je het management mee hebt, en de ervaring is dat die vrij snel over zijn als je ze verteld dat er gewoon minder ruimte is voor fouten en je gelijk kunt zien wie de fout heeft geintroduceerd.

Ik geloof ook niet in het gefaseerd invoeren van dit soort triviale veranderingen, ets met zachte heelmeesters en gapende wonden.

Zal er verder niets meer over zeggen; dan kan ik beter zelf een topic openen. Maar we zijn maar met z'n tweeën en vanuit een behoefte in een nu fulltime bezigheid gerold. Dus geen management, geen ladingen collega's die niet willen. Gewoon het git/deploy/etc. gebeuren niet voor elkaar kunnen krijgen op een voor mij werkbare manier.

Ik kan veel leren en dat moet ook wel lukken, maar bij eerdere pogingen kwam ik altijd wel weer iets tegen in het geheel, waar ik niks mee kon. Sinds een tijdje gebruik ik PhpStorm, dus misschien nu serieus eens werk van maken. Ik lees hier dat het juist makkelijk is en prima werkt met deze IDE.

Maar goed, ik zal dus wel een topic openen als ik er mee bezig ga .

[Hydra]

TheNephilim schreef op dinsdag 17 december 2013 @ 16:33:
Gewoon het git/deploy/etc. gebeuren niet voor elkaar kunnen krijgen op een voor mij werkbare manier.

Ik interpreteerde "niet voor elkaar kunnen krijgen" als dat je je mededevelopers niet meekreeg. Dit is dus gewoon incompetentie van jouw kant?

[TheNephilim]

Hydra schreef op dinsdag 17 december 2013 @ 16:42:
[...]


Ik interpreteerde "niet voor elkaar kunnen krijgen" als dat je je mededevelopers niet meekreeg. Dit is dus gewoon incompetentie van jouw kant?

Yup!

[Kajel]

Ik ben het volledig met Hydra eens. Sterker nog, ik zou niet bij een toko willen werken waar de developers niet al uit zichzelf hebben ontdekt hoe handig versioncontrol is, hoe dom het is om te deployen via FTP, hoe dom het is om dingen op productie aan te passen via FTP etc. Die developers hebben toch interesse in hun eigen vak? Die lezen toch ook wel eens een blog/tweakers.net/the interwebz? Ze kunnen beter weten!
Zulke "developers" moet verboden worden ooit nog een regel te programmeren...

Een goede deployment strategie, OTAP-straat, Build server (Jenkins/Bamboo/Whatever) etc. opzetten, is "half the fun"!

[drm]

De discussie over of je wel of geen VCS nodig hebt ga ik maar niet eens op in. Iedereen die daarover uberhaupt een discussie aan zou willen gaan is gewoonweg niet serieus te nemen.

Wat is jullie idee hierbij? Hoe zouden jullie zoiets aanpakken?

Je moet het probleem niet groter maken dan het is. Een "testserver" kan in de praktijk gewoon betekenen dat je op dezelfde FTP-omgeving twee mapjes hebt, 1 met productie-code en 1 met testcode. Het is zelfs denkbaar dat die twee gewoon met dezelfde database verbinden, mits je de risico's goed inschat (en beperkt).

Deploy automation in de meest eenvoudige vorm is een kwestie van een sync¹ doen van een source tree. In de praktijk zul je gaan zien dat het dan handig is om:

1. Te kunnen zien welke versie live staat en wat de verschillen zijn met de versie die je live wilt gaan zetten
2. "Dry runs" te doen
3. Terug te kunnen rollen naar vorige versies
4. Te zorgen dat iedereen in je team dingen live kan zetten (ook de niet-devvers)

Dat kan allemaal zo simpel zijn als inloggen op een server en een scriptje uitvoeren dat "deploy" heet. Het is maar net wat voor jullie praktisch blijkt.

Je moet dus ook eerst nadenken over je strategie (welke problemen wil je precies op gaan lossen) en dan pas over tooling. Je kunt door veel te lezen over de beschikbare tools wel op ideeen komen, maar ze hoeven niet je strategie te bepalen.

Verder lees ik in je verhaal vooral een probleem van code-organisatie en niet zo zeer deployment. Dat is een veel lastigere klus, maar daarom ook veel leuker. Wat je daarmee het beste kunt doen is:

1. zorgen dat je losse (testbare) componenten maakt van de shared code
2. Daar versienummers aan hangt, dependencies definieert en changelogs van bij gaat houden
3. Afspraken maken over wie verantwoordelijk is voor welk component
4. Zorgen dat de verschillende instances van de site die gebruik maken van die shared code vastleggen welke versie van de code ze gebruiken (bijvoorbeeld met composer)
5. Zorgen dat er een proces is wat de kwaliteit bewaakt.

Dat laatste kan simpelweg zijn een aantal vaste dingen testen (met de hand), maar kan ook zo ver gaan als continuous integration of zelfs continuous delivery. Ook hiervoor geldt dat het meer gaat om afspraken dan automatisering. Alles wat je afspreekt kun je altijd nog automatiseren. Automatisering gebruik je om de menselijke fout in je proces te beperken, niet om het proces opzich te definiëren.

Unit tests zijn een goed idee voor backend code, maar met tools als Behat, Selenium (en alles wat je tegenkomt als je daar naar gaat googlen) kun je functionele en front-end logica goed testen.

Als je wilt kan ik nog wel eens wat meer vertellen over hoe het bij ons georganiseerd is.

¹) Voor FTP gebruik(te) ik altijd lftp (een command line tooltje dat ook een "mirroring" functie heeft), maar ik zou je aan willen raden om zo veel mogelijk naar SSH over te stappen en met rsync, git push of sshfs te gaan werken

[ValHallASW]

drm schreef op zaterdag 28 december 2013 @ 12:52:
¹) Voor FTP gebruik(te) ik altijd lftp (een command line tooltje dat ook een "mirroring" functie heeft), maar ik zou je aan willen raden om zo veel mogelijk naar SSH over te stappen en met rsync, git push of sshfs te gaan werken

Ik ben wat dat betreft heel happy met git-ftp: https://github.com/git-ftp/git-ftp . Het voldoet aan punten 1-3 die je noemt (maar niet aan 4 - alles wat gedeployed wordt moet in git zitten, en daarmee is het al meteen lastig voor niet-technische collega's). In mijn geval is dat geen issue, aangezien ik toch de enige ben die er mee werkt :-) Toch ben ik verdomde blij met snel deployen én snel rollbacken.

[drm]

goeie tip