Hoe efficiënt code testen op een VPS?

[kmsch]

Beste Tweakers,

Ik ben een PHP-applicatie aan het bouwen die communiceert met de API van een betalingsprovider. Communicatie naar de betalingsprovider toe verloopt prima. Periodiek geeft de API echter ook terugkoppeling naar mij toe in de vorm van POST-requests, die ik niet ontvang omdat ik een lokale webserver heb draaien.

Om dit te fixen upload ik nu steeds mijn code naar een VPS, waar ik API-requests wel gewoon goed kan ontvangen. Probleem is dat ik voor elke paar regels code mijn synchronisatiescript moet aanroepen, dan een aantal permissies moet goedzetten op de VPS en dan pas kan kijken of mijn code werkt. Dit duurt steeds een seconde of tien en is tijdens het developproces best vervelend.

Kan dit efficiënter naar jullie beste weten? Het synchronisatiescript is een rsync-script naar een Ubuntu VPS met Apache.

Alvast bedankt!

Gr,
Koen

[CH4OS]

Om gemakkelijk de code elders te krijgen, zou ik het lekker simpel houden en Git (GitHub, BitBucket of een eigen GitLab installatie) gaan gebruiken, dat doe ik namelijk ook voor mijn hobby projectje (via BitBucket), daar is een tool als rsync eigenlijk ook niet voor bedoeld.
Dan hoef je ook niet alles steeds opnieuw te uploaden en kun je ook makkelijker een versie terug of zelfs van complete branch switchen, als blijkt dat de aanpassing bijvoorbeeld meer kwaad doet dan goed.

Bedoel je echt inhoudelijk testen van de code, dan kun je eens kijken naar bijvoorbeeld PHPunit. Daarmee automatiseer je tests, bijvoorbeeld aan de hand van bug reports. Voordeel met die tests is dat je in de toekomst dergelijke bugs dus kan voorkomen, omdat je daar specifiek op test. Zo weet je dus ook 100% zeker dat de kwaliteit van jouw code alleen maar kan stijgen en oude bugs niet meer terug kunnen komen.

[Voor 105% gewijzigd door CH4OS op 01-08-2017 16:05]

[EddoH]

kmsch schreef op dinsdag 1 augustus 2017 @ 15:54:
Beste Tweakers,

Ik ben een PHP-applicatie aan het bouwen die communiceert met de API van een betalingsprovider. Communicatie naar de betalingsprovider toe verloopt prima. Periodiek geeft de API echter ook terugkoppeling naar mij toe in de vorm van POST-requests, die ik niet ontvang omdat ik een lokale webserver heb draaien.

Om dit te fixen upload ik nu steeds mijn code naar een VPS, waar ik API-requests wel gewoon goed kan ontvangen. Probleem is dat ik voor elke paar regels code mijn synchronisatiescript moet aanroepen, dan een aantal permissies moet goedzetten op de VPS en dan pas kan kijken of mijn code werkt. Dit duurt steeds een seconde of tien en is tijdens het developproces best vervelend.

Kan dit efficiënter naar jullie beste weten? Het synchronisatiescript is een rsync-script naar een Ubuntu VPS met Apache.

Alvast bedankt!

Gr,
Koen

Waarom automatiseer je het proces niet verder door ook de file permissies automatisch goed te laten zetten?
Alternatief is je webserver ook vanaf buiten benaderbaar te laten zijn. Lijkt mij eigenlijk nog makkelijker.

10 seconden vidn ik overigens niet veel. Je moest eens weten hoe lang hier een build op de cross-compile server duurt voor ik kan testen...

CH40S schreef op dinsdag 1 augustus 2017 @ 15:57:
Om gemakkelijk de code elders te krijgen, zou ik het lekker simpel houden en Git gaan gebruiken.
Dan hoef je ook niet alles steeds opnieuw te uploaden en kun je ook makkelijker een versie terug of zelfs van complete branch switchen.

Ik had ook ooit eens collega die Git ging gebruiken om zijn code te syncen op 2 machines. Wat je dan krijgt is alleen maar halfbakken commits omdat je even op de server wat wilt gaan testen.
Tenzij je altijd consequent je commits squashed als je klaar bent met testen lijkt het me erg onwenselijk. Git is een versiebeheersysteem, geen sync-tool.

[CH4OS]

EddoH schreef op dinsdag 1 augustus 2017 @ 16:05:
Ik had ook ooit eens collega die Git ging gebruiken om zijn code te syncen op 2 machines. Wat je dan krijgt is alleen maar halfbakken commits omdat je even op de server wat wilt gaan testen.
Tenzij je altijd consequent je commits squashed als je klaar bent met testen lijkt het me erg onwenselijk. Git is een versiebeheersysteem, geen sync-tool.

Tja, als je Git niet goed gaat gebruiken, dan krijg je inderdaad een rotzooi. Je pushed dan eigenlijk ook pas dingen naar git, op het moment dat het development werk voor de feature of de bug klaar is. Je moet dus inderdaad niet elke poep en scheet gaan pushen met Git, dan ga je aan het doel van Git voorbij.

[Voor 6% gewijzigd door CH4OS op 01-08-2017 16:08]

[Afvalzak]

Direct editten op de VPS is de snelste manier, maar of je daar blij van wordt

[EddoH]

CH40S schreef op dinsdag 1 augustus 2017 @ 16:07:
[...]
Tja, als je Git niet goed gaat gebruiken, dan krijg je inderdaad een rotzooi. Je pushed dan eigenlijk ook pas dingen naar git, op het moment dat het development werk voor de feature of de bug klaar is. Je moet dus inderdaad niet elke poep en scheet gaan pushen met Git, dan ga je aan het doel van Git voorbij.

Maar hoe kun je nou een 'correcte' push doen als je je code nooit getest hebt? Je kunt immers je code pas testen als je pusht.

[CH4OS]

EddoH schreef op dinsdag 1 augustus 2017 @ 16:10:
Maar hoe kun je nou een correcte push doen als je je code nooit getest hebt? Je kutn immers je code pas testen als je pusht.

Hij heeft toch een lokale development omgeving? Dus testen nadat je hebt gepushed is natuurlijk een beetje onzin, want voordat je pushed kan je ook al testen. Vervolgens push je naar de VPS om bijvoorbeeld de klant of de tester te laten testen. Daarna kan je het deployen naar live.

[Voor 29% gewijzigd door CH4OS op 01-08-2017 16:11]

[rnark]

Wat ook een optie is een tunnel naar je lokale testomgeving, ik gebruik hiervoor ngrok.

[EddoH]

CH40S schreef op dinsdag 1 augustus 2017 @ 16:10:
[...]
Hij heeft toch een lokale development omgeving?

Het hele probleem is dat hij daar niet lekker op kan testen en daarom op de VPS test...

[mithras]

Als je nu een tijdelijke tunnel legt van die vps naar je eigen localhost en daar de callback overheen stuurt, kan je je ip adres van je vps als callback gebruiken. Die krijg je dan door op je localhost. Is echt de makkelijkste manier van testen om het lokaal te houden.

[kmsch]

rnark schreef op dinsdag 1 augustus 2017 @ 16:11:
Wat ook een optie is een tunnel naar je lokale testomgeving, ik gebruik hiervoor ngrok.

Ga ik proberen, thanks! Dit lijkt precies te doen wat ik nodig heb

Gewoon poorten opengooien kan hier niet (studentenflat, allemaal routers, niemand eigen modem), maar misschien dat dit werkt.

Bedankt voor de reacties overigens allemaal, echt chill

[Voor 6% gewijzigd door kmsch op 01-08-2017 16:14]

[CH4OS]

EddoH schreef op dinsdag 1 augustus 2017 @ 16:12:
Het hele probleem is dat hij daar niet lekker op kan testen en daarom op de VPS test...

Dan kun je aan de hand van branches toch een en ander ondervangen? Is misschien niet helemaal as intended, maar werkt dan op zich best prima. Zo kan je per ticket / case dan immers ook code toevoegen en uiteindelijk naar master mergen. Dan hoef je dus ook niet onnodig vaak te pushen naar de master branch.

Een hoop gedoe is switchen van branches en af en toe pullen, echt niet.

[Voor 7% gewijzigd door CH4OS op 01-08-2017 16:16]

[Stoelpoot]

CH40S schreef op dinsdag 1 augustus 2017 @ 16:14:
[...]
Dan kun je aan de hand van branches toch een en ander ondervangen? Is misschien niet helemaal as intended, maar werkt dan op zich best prima. Zo kan je per ticket / case dan immers ook code toevoegen en uiteindelijk naar master mergen. Dan hoef je dus ook niet onnodig vaak te pushen naar de master branch.

Je hebt wel gelijk dat Git inderdaad heel fijn is, maar daar heeft de TS niks aan. TS ontwikkeld een product wat callbacks krijgt van een externe service, en daar is zn huidige netwerksituatie niet geschikt voor. Een VPS is een goede manier om daarmee te testen.

[Comgenie]

Als je Windows hebt als ontwikkel machine kan een tool zoals dit ook helpen. Daarmee krijg je een netwerk schrijf direct naar je linux VPS toe die je vervolgens in je IDE kan gebruiken. Zelf gebruik ik het vooral om dingen snel te testen op een Raspberry PI. Er zal vast ook zoiets beschikbaar zijn voor Linux.

[Voor 6% gewijzigd door Comgenie op 01-08-2017 16:19]

[EddoH]

CH40S schreef op dinsdag 1 augustus 2017 @ 16:14:
[...]
Dan kun je aan de hand van branches toch een en ander ondervangen? Is misschien niet helemaal as intended, maar werkt dan op zich best prima. Zo kan je per ticket / case dan immers ook code toevoegen en uiteindelijk naar master mergen. Dan hoef je dus ook niet onnodig vaak te pushen naar de master branch.

Een hoop gedoe is switchen van branches en af en toe pullen, echt niet.

Je beschrijft nu gewoon goed gebruik van Git, niet een ideale methode om er mee naar je testserver te syncen.
Er is mijn inziens geen enkele goede reden om Git als synchronisatie service te gebruiken. Daar zijn rsync en consorten beter in. Maar laten we het topic verder niet te veel vervuilen.

kmsch schreef op dinsdag 1 augustus 2017 @ 16:13:
[...]


Ga ik proberen, thanks! Dit lijkt precies te doen wat ik nodig heb

Gewoon poorten opengooien kan hier niet (studentenflat, allemaal routers, niemand eigen modem), maar misschien dat dit werkt.

Bedankt voor de reacties overigens allemaal, echt chill

Behalve de reeds genoemde tunneloplossing kun je ook een simpele SSH tunnel gebruiken.

[Voor 22% gewijzigd door EddoH op 01-08-2017 16:23]

[CH4OS]

Comgenie schreef op dinsdag 1 augustus 2017 @ 16:18:
Als je Windows hebt als ontwikkel machine kan een tool zoals dit ook helpen. Daarmee krijg je een netwerk schrijf direct naar je linux VPS toe die je vervolgens in je IDE kan gebruiken. Zelf gebruik ik het vooral om dingen snel te testen op een Raspberry PI. Er zal vast ook zoiets beschikbaar zijn voor Linux.

Voor Linux heb je tooltjes zoals sshfs (een sftp verbinding is immers niets anders dan een file transfer over een ssh verbinding). Daarmee kan je een sftp connectie mounten aan een folder.

Al heb ik niet de indruk dat de machine waar @kmsch vanaf werkt een Linux machine is en is enkel de VPS dat.

[Voor 7% gewijzigd door CH4OS op 01-08-2017 16:22]

[Hydra]

Waarom maak je niet gewoon een simpele tool die mock POST requests naar jou toe doet? Het is de normaalste zaak van de wereld om externe dependencies weg te mocken.

Beetje bizar overigens dat dit verzand in manier om die code op z'n VPS te krijgen. Dat is z'n onderliggende probleem helemaal niet.

[Voor 29% gewijzigd door Hydra op 01-08-2017 17:42]

[Solopher]

In eerste instantie zal ik zeggen:
Waarom zet je je ontwikkeling omgeving/VPS omgevingen niet om naar Docker?

Dan zijn ze namelijk beiden gelijk. Het enige wat je dan hoeft te doen indien je een deploy naar je VPS wil doen is even een image opnieuw builden, en deze vervolgens binnen halen op je VPS.
Om eenvoudig te beginnen zou je dit kunnen doen met een simpel bashscript, maar ik denk dat je uiteindelijk gewoon een CI/CD omgeving wil hebben waarmee je ook automatisch code test.

Maar mocht dit teveel werk zijn , en aangezien je al een linux VPS hebt? https://blog.rodneyrehm.d...localtunnel-or-ngrok.html Een Revese SSH tunnenl Het voordeel hier: Je kunt hier ook TLS gebruiken (ik neem aan dat dit verplicht is vanuit de bank).

[Anoniem: 420461]

Ik heb in PHPStorm het uploaden naar mijn server onder een hotkey hangen, dus in plaats Ctrl-S gebruik ik die, en dan Alt-Tab en F5. Geen moeilijk gedoe...

[Hydra]

Solopher schreef op dinsdag 1 augustus 2017 @ 22:04:
Dan zijn ze namelijk beiden gelijk. Het enige wat je dan hoeft te doen indien je een deploy naar je VPS wil doen is even een image opnieuw builden, en deze vervolgens binnen halen op je VPS.

Dit kan je prima automatiseren trouwens. Als ik een nieuwe versie van mijn blog naar bitbucket push gaat er een trigger af die een webhook op mijn jenkins installatie (staat op m'n VPS) aanroept. Deze bakt een nieuwe statische site, maakt hier een docker image van, en brengt deze nieuwe docker image up via docker compose.

[Yarisken]

Ansible misschien ? Maak een playbook voor een copy en op het einde zet je met een commando de rechten goed.

[Montaner]

Als je bv. htdocs/www op je VPS via FTP benaderbaar maakt, kan je ook een tool gebruiken om een ftp dir toe te voegen als netwerklocatie en rechtstreeks daarop te ontwikkelen. Aangezien hij dan gewoon wordt gezien als Windows dir, kan ieder willekeurig versiebeheersysteem hier ook mee omgaan.

Bv: https://southrivertech.com/products/webdrive/

[Crazy-]

Misschien interessant om je Webhook url te laten leiden naar https://requestb.in

Dan zie j daar de callbacks van betaalprovider

Eventueel kan je lokaal Postman gebruiken en de betaalprovider requests simuleren

[Megamind]

Crazy- schreef op dinsdag 8 augustus 2017 @ 13:39:
Misschien interessant om je Webhook url te laten leiden naar https://requestb.in

Dan zie j daar de callbacks van betaalprovider

Eventueel kan je lokaal Postman gebruiken en de betaalprovider requests simuleren

Dit. Beetje vreemde antwoorden hier die niet echt op de vraag slaan.

Testen doe je lokaal, en als de API goed gedocumenteerd is kan je prima een replay doen naar je lokale omgeving.

[Daniel.]

CH40S schreef op dinsdag 1 augustus 2017 @ 16:07:
[...]
Tja, als je Git niet goed gaat gebruiken, dan krijg je inderdaad een rotzooi. Je pushed dan eigenlijk ook pas dingen naar git, op het moment dat het development werk voor de feature of de bug klaar is. Je moet dus inderdaad niet elke poep en scheet gaan pushen met Git, dan ga je aan het doel van Git voorbij.

Een aparte branch aanmaken daar alles eerst zo maken dat het werkt en dan mergen met develop.of master?

Geen probleem toch?

[CH4OS]

ShittyNL schreef op woensdag 9 augustus 2017 @ 06:15:
Een aparte branch aanmaken daar alles eerst zo maken dat het werkt en dan mergen met develop.of master?

Geen probleem toch?

Dat is toch ook precies wat ik ergens in dit topic al zei?

Daarnaast hebben payment providers vaak ook een testing- danwel sandboxomgeving.

[Voor 12% gewijzigd door CH4OS op 09-08-2017 09:04]

[Hydra]

Sowieso is de TS niet meer geinteresseerd kennelijk.

[kmsch]

Hydra schreef op woensdag 9 augustus 2017 @ 09:02:
Sowieso is de TS niet meer geinteresseerd kennelijk.

Sorry, ik zal hier nog even op terugkomen.

Ngrok was de perfecte oplossing voor mijn probleem. Dus dank aan iedereen en @rnark in het bijzonder voor de antwoorden