Setup om efficient code te testen

[Lulukai]

oeaeuaoeu

[ Voor 97% gewijzigd door Lulukai op 16-08-2014 10:02 ]

[Cartman!]

Gewoon wel lokaal een webserver draaien, ik werk op windows en heb nagenoeg nooit problemen dat het op *nix ineens niet werkt. Eerder dat op een windows server het niet werkt juist

Bovendien heb je meestal eerst nog een staging- en/of acceptatie-omgeving voordat je naar live pusht dus evt. problemen met rechten zou je dan al tegenkomen op die omgevingen.

[Mental]

Je hebt genoeg texteditors die een plugin hebben (of native functionaliteit) waarmee je bestanden op een ftp server kan openen; bij opslaan gebeurt dat dus direct op de ftp.

[Lulukai]

Cartman! schreef op donderdag 20 oktober 2011 @ 10:53:
Bovendien heb je meestal eerst nog een staging- en/of acceptatie-omgeving voordat je naar live pusht dus evt. problemen met rechten zou je dan al tegenkomen op die omgevingen.

De website die ik nu maak (en de andere ook) zijn relatief eenvoudig dus verschillende testomgevingen zouden voor mij echt overkill zijn. Versiebeheer zou ik wel kunnen gebruiken, maar dat lijkt me dan weer te moeilijk om op te zetten of gemakkelijk te gebruiken

Mental schreef op donderdag 20 oktober 2011 @ 10:55:
Je hebt genoeg texteditors die een plugin hebben (of native functionaliteit) waarmee je bestanden op een ftp server kan openen; bij opslaan gebeurt dat dus direct op de ftp.

Dit is wel handig!

[Stoffel]

ruyckske schreef op donderdag 20 oktober 2011 @ 10:56:
[...]

De website die ik nu maak (en de andere ook) zijn relatief eenvoudig dus verschillende testomgevingen zouden voor mij echt overkill zijn. Versiebeheer zou ik wel kunnen gebruiken, maar dat lijkt me dan weer te moeilijk om op te zetten of gemakkelijk te gebruiken

Toch is dat niet eens een vrijblijvende tip maar absoluut vereist als je serieus wil ontwikkelen. Werken op productie is heiligschennis en dan ook nog niet terug kunnen omdat je geen versiebeheer hebt al helemaal. Zo lastig is het allemaal niet, ik zou het ter harte nemen.

[Lulukai]

Ik wil wel, maar het in de praktijk opzetten en zelf starten zonder ervaring vind ik nogal lastig. Op GoT wordt er meestal enkel gezegd "gebruik GIT/SVN"

[Verwijderd]

Tja... Als je het niet wilt proberen omdat je het lastig vind, zul je het ook nooit leren. Hoe eerder je je inleest in bv. GIT of SVN, hoe eerder je het niet meer lastig vind. Zonder jezelf ergens over in te lezen en gewoon proberen, zul je ook niet veel leren.

[Cartman!]

SVN is wel het simpelste wat er is... download Tortoise SVN en installeer het. Dan op een lege map "create repository here" kiezen, volgende klikken en klaar. Dan je files erin en als je denkt dat het nodig is kies je voor "Commit". Ben je iets kwijt dan check je in je log waar t mis gegaan is en kun je de files terughalen.

Direct op je productie-omgeving editten snap ik goed maar is gewoon niet aan te raden, 1 keer een foutje maken en je site is stuk of je bent je goede versie van je file kwijt wegens een stomme fout of corruptie.

[hiekikowan]

Ik werk altijd via Notepad++ (onder Windows) of gEdit (onder Linux). Overigens vond ik op internet meerdere artikelen over FTP-support in Textwrangler.

[DexterDee]

Ik gebruik op de Mac om te coderen Komodo IDE. Dat is een programmeeromgeving die praktisch alle belangrijke zaken bevat, zoals versiebeheer, remote drive support en een volledige debug omgeving. Er is ook een gratis variant met minder functies: Komodo Edit.

Het is erg gebruikelijk dat programmeurs lokaal ontwikkelen. Het testen van code kan dan immers zonder dat iemand er last van heeft. En ook in professionele omgevingen zitten er soms wel eens verschillen tussen een ontwikkel PC en de live server. Dit wordt opgelost door de code eerst op een test/staging omgeving te testen die identiek aan de live server is ingericht. Op die manier kan er weinig fout gaan.

[Woet]

Coda aanschaffen is de beste keuze die ik ooit heb gemaakt.
Ik raad je aan om de trial te gebruiken en weet zeker dat je na een paar dagen om bent

[kwaakvaak_v2]

Mijn setup voor lokaal ontwikkelen op mijn diverse macjes is,
mamp-pro om sites op lokaal te draaien
phpstorm als IDE (werkt ook prima voor HTML/CSS etc)
Transmit omdat het een fatsoenlijke FTP client is
Acorn, om plaatjes te maken/bewerken.
Sequel PRO als mySQL manager
en textmate als editor voor als ik een losse file wil bewerken, maar dat wordt vermoedelijk sublime2 als die uit komt.

En GIT met github voor persoonlijke projecten, zakelijk gebruiken wij SVN en gebruik ik afwisselend smartSVN of de ingebouwde SVN tools van phpstorm.

Meer heb ik eigenlijk niet nodig, mamp pro zorgt voor het makkelijk aan kunnen maken van virtuele projecten en kan switchen tussen php 5.2.x en 5.3.x

En versiebeheer is een must have, als je dat niet gebruikt kun je net zo goed direct stoppen met ontwikkelaar zijn. Dat is net zoiets als een kok die geen lepel gebruikt, omdat ie met zijn vinger ook kan roeren.

[DexterDee]

Woet schreef op donderdag 20 oktober 2011 @ 11:22:
Coda aanschaffen is de beste keuze die ik ooit heb gemaakt.
Ik raad je aan om de trial te gebruiken en weet zeker dat je na een paar dagen om bent

Ik heb Coda en Komodo IDE naast elkaar gedraaid en getest en ik ben zelf voor Komodo gegaan. Ik vind Coda een zeer goed product, maar Komodo had net een aantal unique selling features zoals de geweldige visuele regex editor die voor mij de doorslag gaven.

Overigens, als je direct remote op het bestandssysteem van de server wil werken heb je software als Transit (van de makers van Coda ) en ExpanDrive. Hiermee kun je een remote drive met (S)FTP mounten en gebruiken in heel OSX.

[Lulukai]

Cartman! schreef op donderdag 20 oktober 2011 @ 11:15:
SVN is wel het simpelste wat er is... download Tortoise SVN en installeer het. Dan op een lege map "create repository here" kiezen, volgende klikken en klaar. Dan je files erin en als je denkt dat het nodig is kies je voor "Commit". Ben je iets kwijt dan check je in je log waar t mis gegaan is en kun je de files terughalen.

Ga ik eens aan beginnen, je kan het inderdaad enkel leren door te proberen.

Direct op je productie-omgeving editten snap ik goed maar is gewoon niet aan te raden, 1 keer een foutje maken en je site is stuk of je bent je goede versie van je file kwijt wegens een stomme fout of corruptie.

Maar het is zo gemakkelijk

Enige wat ik me afvraag is 'hoe' je kan zeggen welke code lokaal uit je repostiroy moet worden gedraaid.

[ Voor 6% gewijzigd door Lulukai op 20-10-2011 11:44 ]

[kwaakvaak_v2]

je draait geen code direct in je repository, je draait code in je sandbox die een checkout is van je repository.

[Cartman!]

ruyckske schreef op donderdag 20 oktober 2011 @ 11:39:
Maar het is zo gemakkelijk

Totdat je 1 keer een bug/fout/whatever hebt, dan sla je jezelf voor je kop dat je het op deze manier doet... Of als je een klant krijgt die na een aanpassing zegt: nah, doe toch maar hoe t vorige week was. Jij moet t opnieuw maken, ik trek het uit SVN

[zwippie]

Je zou ook kunnen rsyncen van je dev naar de productie omgeving. Mits je SSH access hebt op de productieserver natuurlijk. Dit is ook prima te combineren met versiebeheer.

Het voordeel van rsync boven een git/svn checkout naar productie is dat je sommige (configuratie) bestanden kunt excluden. Er zijn bijna altijd wel 1 of 2 bestanden verschillend op de dev/prod omgeving.

[Lulukai]

Ik ben begonnen met Coda en heb ook een SVN opgezet, hele goede tutorial hier: http://basementjack.com/u...version-beanstalk-how-to/ Nu nog eens uitzoeken hoe ik met MAMP een bepaalde versie van die code kan draaien.

[ Voor 21% gewijzigd door Lulukai op 20-10-2011 15:27 ]

[Wizz15]

zwippie schreef op donderdag 20 oktober 2011 @ 12:16:
[...]

Het voordeel van rsync boven een git/svn checkout naar productie is dat je sommige (configuratie) bestanden kunt excluden. Er zijn bijna altijd wel 1 of 2 bestanden verschillend op de dev/prod omgeving.

In mijn ervaring zijn die 1 of 2 bestanden vaak configuratie files die voor de hele applicatie/website gelden. Wij gebruiken Git als versiebeheer (voorheen SVN) en kunnen zowel lokaal, op staging als op productie op dezelfde codebase draaien, terwijl de configuratie voor elke server toch echt anders is.

De oplossing is namelijk simpel: neem in je .htaccess of virtualhost-configuratie een environment variabele op die aangeeft welke configuratie er gebruikt moet worden. Laat de applicatie vervolgens aan de hand van die environment variabele de juiste configuratie laden. Geen gehannes met files excluden die je vervolgens toch weer handmatig een keer moet updaten omdat er iets gewijzigd is, gewoon alles in versiebeheer en laat de server het maar uitzoeken

Ik werk overigens ook met PhpStorm (niet gratis, maar prijs is eerlijk). Voorheen met Netbeans, Eclipse PDT, Komodo en andere IDE's gewerkt. PhpStorm is echter een blijvertje. Werkt ook op mac, maar heb een Ubuntu virtual machine met daarop mijn webserver, MySQL, MongoDB, etc. Scheelt resources als ik mijn mac prive wil gebruiken.

Tip aan de TS: kijk eens naar Homebrew. Is een handige package manager onder OSX welke het installeren van verschillende software vergemakkelijkt. Scheelt een hoop qua configuratie van software, en ook het compleet verwijderen van software is gebeurd in een oogwenk. Nodigt ook uit tot expirmenteren met andere talen/technieken op webdevelopment gebied Wil je bijvoorbeeld Nginx proberen in plaats van Apache? Met 'brew install nginx' ben je meteen op weg

[Verwijderd]

Je hoort sowieso op een speciaal daarvoor ingerichte server te ontwikkelen. Je wilt andere instellingen dan op een productieserver, en je wilt nooit iets op de productieserver zetten dat niet is getest. Een simpel loopje kan een server compleet onbruikbaar maken!

[koendenb]

Ik ken je probleem volledig en gebruik ook textwrangler.

Mijn oplossing hiervoor is de gratis software (ftp client): Cyberduck (kost 20 euro in appstore, gratis op hun website)

Als je een bestand opslaat wordt het direct ge-upload naar je server.

Met een beetje settings veranderen kan je d.m.v. een dubbelclick op je bestand in cyberduck (ftp client) het bestand openen in je editor (textwrangler, dreamweaver, texteditor) en met opslaan is alles ge-upload.

Voor enige vragen kan je altijd een DM sturen

[Bosmonster]

De vraag was toch hoe efficient te coden?

Iedere wijziging uploaden via FTP lijkt me dan per definitie ongewenst, dus snap die reacties niet zo.

Ontwikkel op een server (of desnoods je eigen systeem als je niet zo vaak of professioneel ontwikkelt) die net zo ingericht is als je live server.

SVN of GIT is natuurlijk een welkome extra, als je toch een server draait.

[MuddyMagical]

Voor verschillende hobby projecten werk ik in Netbeans (PHP) en gebruik de FTP functionaliteit daarin om mijn files op een subdomein te plaatsen. Daarnaast gebruik ik Assembla als SVN. Hierdoor heb ik een versiebeheer waarmee ik kan werken.

[koendenb]

ruyckske schreef op donderdag 20 oktober 2011 @ 10:49:
Ondertussen ben ik het wel al beu om voor elke kleine wijzing de files te moeten uploaden...
Wat is jullie workflow op code op te slaan en te testen?

Ik vertel gewoon hoe ik het doe, ik vind dit een makkelijke manier om mijn bestanden op te slaan, up te loaden en te testen.

[xtra]

Ctrl+C/Ctrl+V heeft bij mij lang voldaan als versiebeheer. Werkte prima samen met filediff.
SVN gebruik ik nu vooral om bestanden op meer plekken beschikbaar te hebben. Versiebeheer is mooi meegenomen. Vooral bij kleine projecten mis ik de discipline om verschillende wijzigingen netjes gescheiden te houden tussen commits.

Ontwikkelen doe ik met een lokale webserver (Ctrl+S / F5). Testen liefst op een subdomein op de uiteindelijke server want dat lijkt het meest op productie.

[Lulukai]

Ik gebruik nu Coda samen met SVN. Maar ik heb afbeeldingen die ik in de source van mijn map steek, maar het is niet de bedoeling dat die in de SVN gaan natuurlijk, enkel de code hoort daar. Wat is de common practice voor dit?

[DexterDee]

Alles gaat normaliter in SVN: code, statische content, database structuur dump, test data, test cases, documentatie, etc...

Op die manier heb je versies van alles en als je een release maakt, weet je later nog precies welke versie van de documentatie, database structuur, etc.. bij die versie van de code hoorde.

[Lulukai]

Dus per definitie is SVN een veelvoud groter dan de ruimte die je bij je webhost inneemt?

[DexterDee]

Dat ligt eraan. Ik neem niet aan dat jij voor je hobbyprojectjes uitgebreide functionele, technische en test documentatie gaat schrijven. Een database structuur dump zou ik in elk geval wel in Subversion bewaren. Maar over het algemeen is een SVN repository inderdaad groter dan wat je "in productie" zet op een webhost.

[messi]

Wij ontwikkelen op een mac (en ik in dit geval met Sublime2). Alle code is lokaal uitgechecked uit een GIT repository (develop branch) en ik draai alles lokaal (Ruby on Rails/Sinatra).

Als de code goed genoeg is gaat het de remote repository in (GitHub) en vervolgens gaat de CI server de code testen in zijn eigen omgeving.

Slagen alle testcases dan wordt het hele zooitje ge-deployed naar een staging server waar de klant het een en ander goed kan keuren.

Daarna komt alles in de Master branch terecht die altijd deploybaar is naar de productie servers. m.a.w. iedere gek kan bij ons de master branch deployen en dat moet altijd goed gaan

Afbeeldingen als sprites en backgrounds gaan ook de Git repository in. De rest staat in de .gitignore zodat het niet meegaat.

[Lulukai]

Bedankt voor iedereen om al te reageren! Het is handig om direct met een goede setup te kunnen starten.
@messi: enorm mooie persoonlijke website.

[ Voor 17% gewijzigd door Lulukai op 22-10-2011 21:32 ]