Inrichten groot webdev project

[RickyHeijnen]

We hebben allemaal wel eens op het punt gestaan dat er een nieuw project gaat beginnen en dat alles ingericht moet worden. Op dat punt ben ik nu... Een nieuwe klant binnengehaald voor een groot project, althans groter dan ik tot nu toe gedaan heb. Ik werk als zzp'er dus heb weinig tot geen ervaring met echt grotere projecten waar meerdere mensen bij betrokken zijn. Nu weet ik dat op voorhand al dat dit een project is voor meerdere jaren en dat er op een later moment ook andere programmeurs aan gaan werken. Dus ik wil daar nu alles al goed op inrichten.

Al een aantal dagen ben ik aan het googlen, zoeken, blogs aan het lezen maar ik kom weinig best practices tegen die gaan over het inrichten van een webdevelopment project (in dit geval PHP/MySQL) al voordat je ook maar 1 letter code hebt geschreven. Vandaar dat ik hoop via jullie wat ervaringen te horen en tips waar ik aan moet denken en welke tools gebruik je.

Op basis van wat ik ken en wat ik gelezen heb kom ik een beetje uit op het volgende:
- Git repository aanmaken
- Naast de live omgeving ook een test omgeving inrichten
- Development omgeving lokaal draaien dmv Vagrant+Virtualbox

En zaken die ik nog niet helemaal helder heb:
- Hoe kan ik deployen naar test of live? Welke tool gebruik je daarvoor? Ik vind uploaden via FTP eng bij grotere projecten.
- Hoe houden jullie wijzigingen bij aan database structuur, zodat die op test en live ook op het juiste moment goed meekomen? En hoe communiceer je dat naar andere teamleden in het development proces?

Ik ben erg benieuwd naar jullie ervaringen.

[Verwijderd]

Werk je op Windows of Linux?

[pachacuti]

Er zijn massa's deployment tools.
Wij gebruiken momenteel Jenkins maar moeten binnenkort overschakelen naar Bamboo
Wij hebben een git hook ingesteld dat indien we pushen op de git develop branch, jenkins automatisch de testserver update. Deployen naar productie doen we ook via Jenkins maar handmatig.

Databasewijzigingen worden doorgaans met migrations opgelost. Bij de meeste PHP frameworken is dit meestal wel aanwezig ( symfony , laravel, standalone library )

Nog enkele pro-tips:
- Gebruik een bestaand framework, ga het wiel niet opnieuw uitvinden.
- Indien mogelijk, provisioneer je vagrantbox dmv ansible/puppet/chef, zo zit elke developer op dezelfde softwareversies te werken.
- Documenteer je code goed en indien mogelijk/tijd schrijf unittests.

[Ed Vertijsment]

Ik sluit mij aan bij het bovenstaande met wellicht wat aanvullingen:

Op basis van je post neem ik aan dat je met meerdere mensen samenwerkt, in dat geval wil je duidelijk hebben wie wat doet (frontend/backend/hosting etc) en hoe die rollen samenwerken. Vervolgens wil je ervoor zorgen dat verschillende rollen goed samen kunnen werken. Een toffe ingerichte GIT repo is leuk maar zonder menselijke communicatie gaat dat nog steeds tekort schieten Zorg evoor dat verschillende mensen van verschillende rollen goed kunnen communiceren.

Als voorbeeld neem ik een single page application (SPA) die zijn data via een backend haalt middels een REST API. De frontender is dan bezig met alles laten werken aan de voorkant, maar ook met het uitlezen/aansturen van de REST API. Hiervoor is hij/zij dan afhankelijk van de backender die de API moet implementeren, hier is communicatie voor nodig.

Een les die ik geleerd heb is dat er niets boven menselijke communicatie gaat. Vergader eens in de zoveel tijd hoe dingen aangepakt gaan worden en besluit hoe dingen verder besproken gaan worden (bijvoorbeeld slack of een ander medium). Als het een groot project is het de moeite waard om af en toe te luchten met een borrel en samen (opnieuw) over dingen na te denken.

Een ding wat je wil voorkomen is alles puur op techniek fixeren, zonder menselijke inzet loopt je project immers altijd op niets uit. Dat neemt niet weg dat je niet wil nadenken over OTAP, deployment en verschillende disciplines etc, zoals hiervoor al is genoemd. Mijn advies daarnaast is alleen vooral te zorgen dat je alle betrokkenen bij het project meesleept/motiveert/aanspoort om voor de volle 100% het project tot een goed einde te brengen.

[RickyHeijnen]

Verwijderd schreef op vrijdag 28 april 2017 @ 23:29:
Werk je op Windows of Linux?

Werk zelf op Windows maar de applicatie komt in een Linux omgeving te draaien.

Uiteraard ga ik het wiel niet opnieuw uitvinden en ga een framework gebruiken. Maar dat is een andere discussie. Unittest is een goede tip. Zit nu beetje te stoeien met composer. Nooit verkeerd om iets professioneler te worden op dat gebied.

[Verwijderd]

Ik werk zelf puur op Linux (ben geen actieve ontwikkelaar overigens) en weet dat er veel mogelijk is als je sec Linux gebruikt. Zo heb ik zelf het uitrollen van websites geautomatiseerd via GIT. Dus als ik lokaal een wijziging doe dan hoef ik hem alleen maar te committen om hem in productie te brengen. Zoals hierboven geopperd zou je dit kunnen baseren of de branch, zodat je niet je staging vervuild met je productie.

[ Voor 16% gewijzigd door Verwijderd op 28-04-2017 23:50 ]

[Gomez12]

Tja, wat noem jij een groot project?
De punten die je zelf opnoemt vind ik eigenlijk al van toepassing voor de 1-page static site van de bakker op de hoek.
Maar daar zou ik dan ook gelijk onderscharen (als je met meerdere mensen gaat werken):
- Goed ticketsysteem gebruiken

Bij een groot project ga ik eerder denken aan :
- OTAP-opzetten (zodat je klant ook goed kan testen)
- CI-server ernaast draaien (zodat je builds snel failen als ze fout zijn en er niet iemand even snel een commit aan het einde van de dag doet waardoor de boel niet meer werkt)
- Duidelijke coding-regels hebben (bijv spatie of tab), welke je exact kiest is niet zo relevant als ze maar voor iedereen gelijk zijn.

[Mister GT]

Ik stond een tijd geleden ook voor hetzelfde probleem. Na meerdere oplossing te hebben geprobeerd gebruik ik al een poosje dezelfde toolset voor de gehele development cycle. Welke tools je precies kunt gebruiken ligt natuurlijk ook aan het beschikbare budget en het aantal developers dat actief werkt aan de codebase.

Bitbucket gebruik ik voor Git repositories. Je kunt bij Bitbucket ongelimiteerd private repositories aanmaken voor max. 5 personen per repository. Voor kleinere teams is dit meer dan voldoende. Daarnaast gebruik ik CircleCI voor testing en deployment. CircleCI is gratis voor één concurrent build container, wat dus betekent dat je een build tegelijkertijd kunt testen/deployen. Dit is goed te doen als je niet met meerdere developers frequent code aan het committen bent. Daarnaast is de integratie van CircleCI met Bitbucket erg prettig en werkt het eigenlijk vlekkeloos. Bitbucket biedt zelf ook sinds korte tijd een eigen CI aan onder de naam "Pipelines". Hier heb ik zelf nog niet naar gekeken maar het zal waarschijnlijk een prima alternatief zijn. Uiteraard is het voor CI erg belangrijk dat je voldoende unit/feature/integration tests hebt.

Voor development heb ik op mijn laptop een aantal Docker containers runnen (phpdocker.io kun je makkelijk wat Docker config files genereren). Eén voor pgsql en een voor Apache/PHP. Dmv wat fixtures kan ik makkelijk dummy data in de database pompen als ik dat nodig heb. Wijzigingen aan de db structuur kun je eenvoudig bijhouden in migrations. Gezien ik gebruik maak van Symfony gebruik ik hiervoor de DoctrineMigrationsBundle.

[RickyHeijnen]

Gomez12 schreef op zaterdag 29 april 2017 @ 09:01:
Tja, wat noem jij een groot project?

Tsja, wat voor mij een groot project is, hoeft voor jou misschien niet groot te zijn. In dit geval heb ik het over een project waarbij ik weet dat er de komende 10 jaar structureel aan doorontwikkeld zal moeten worden. In eerste instantie begin ik er zelf alleen aan, maar de verwachting is groot dat ik binnen een jaar er een extra programeur op ga zetten en misschien ook nog wel een derde.
Het is dus niet zo, zoals iemand hierboven schreef, dat er een team van verschillende partijen (frontenders, backenders/hosting) aan gaat werken.

Gomez12 schreef op zaterdag 29 april 2017 @ 09:01:
De punten die je zelf opnoemt vind ik eigenlijk al van toepassing voor de 1-page static site van de bakker op de hoek.

Dat is de theorie, in de praktijk is dat natuurlijk niet zo. Ten eerste omdat er bij dat soort klanten altijd te weinig budget is en te veel wensen haha. Ik werk nu ruim 10 jaar voor mezelf en bouw maatwerk webbased backoffice systemen. Het is nog bijv. nog nooit nodig geweest om een aparte testomgeving op te zetten. Ik werk lokaal via wamp en de klant test het uiteindelijk in productieomgeving. De klant communiceert via mail of whatsapp; het zijn altijd korte lijntjes.
Ik begrijp goed dat dit alleen kan als je alleen werkt. Als er al een tweede developer bij komt dan is er al direct veel meer structuur nodig in een project.

Deze applicatie zal ook veel koppelingen bevatten met API's van leveranciers van data en leveranciers van goederen. Ik krijg dan veel te maken met API keys, user/pass gegevens, klantnummers, testdata en gegevens van directe contactpersonen van leveranciers maar bijv. ook uitleg over vaktermen, hoe bepaalde zaken geimplementeerd moeten worden (FO), of vragen die via de mail gesteld worden die voor iedereen belangrijk zijn. Hoe communiceer je dat binnen een team? Mijn eerste ingeving is dan een wiki opzetten waar iedereen alles in kwijt kan. Is dat een veelgebruikte oplossing? En zo ja, geef je de klant hier ook toegang toe?

[Haan]

Hier staan misschien nog wat tips waar je iets mee kan: Omgaan met aantekeningen en documentatie.

Verder is het beheren van keys een van de lastigste dingen die er zijn, in je eentje zal het nog meevallen, maar in een team krijg je er bijvoorbeeld mee te maken dat je niet wil dat iedere developer toegang heeft tot productie keys. Probleem is dan bijvoorbeeld waar je die keys opslaat (inchecken in Git is bijvoorbeeld niet zo'n goed idee en hoe je bij productie deployments met die keys omgaat).
Wij gebruiken bijvoorbeeld een KeePass database waarin productiegegevens staan (accounts, keys, certificaten e.d.) waar een zeer beperkt aantal personen toegang toe heeft.

O ja, nog een tip: automatiseer zoveel mogelijk en zo snel/vroeg mogelijk. Dat kost je in eerste instantie (veel) tijd, maar dat ga je op de lange termijn absoluut terugverdienen.

[ Voor 11% gewijzigd door Haan op 01-05-2017 08:44 ]

[Gomez12]

RickyHeijnen schreef op maandag 1 mei 2017 @ 08:12:
[...]
Dat is de theorie, in de praktijk is dat natuurlijk niet zo.

Sorry hoor, maar ook bij een professionele zzp'er hoort dit gewoon de praktijk te zijn.

Ten eerste omdat er bij dat soort klanten altijd te weinig budget is en te veel wensen haha.

Het aantal wensen/het budget heeft in basis niets te maken met jouw werkwijze (ok, je uurtarief stijgt er iets door, maar het kost niet meer uren om het op werkwijze a of b te doen)

Hoe communiceer je dat binnen een team? Mijn eerste ingeving is dan een wiki opzetten waar iedereen alles in kwijt kan. Is dat een veelgebruikte oplossing? En zo ja, geef je de klant hier ook toegang toe?

Je hebt een aantal te onderscheiden dingen :
- Algemene data die niets met programmeren te maken heeft (je api-inlogs etc) dit kan je in een wiki kwijt (alhoewel ik het een onhandige vorm vind, ik heb liever gespecialiseerde programma's per soort gegevens, maar je lijkt nu nog niet te kunnen bevatten wat voor gegevens je gaat krijgen dus doe maar een wiki, maar persoonlijk heb ik liever een password-keeper voor inlogs, een crm voor telefoonnrs etc) In basis zou ik je klant geen directe toegang hiertoe geven.
- Programma documentatie. Dit kan wel weer goed in een wiki, alleen deze wiki moet wel toegankelijk zijn voor de klant zodat die ook de documentatie kan beoordelen.
- Bugs/vragen etc hiervoor moet je gewoon een ticketsysteem neerzetten. Hier moet je klant wmb ook toegang toe krijgen (scheelt je een sloot mailtjes als : Wat is de status van)
- Planningssysteem, zodat het voor jou en je klant duidelijk is wat hij wanneer kan verwachten (en eigenlijk nog belangrijker zodat hij kan zien wat er naar achteren verschuift als hij functie x naar voren wil halen)
- Urenregistratie systeem. Waarbij je per ticket je uren registreert.

En het lijkt nu alsof je 10 systemen moet opzetten, maar het is meer een werkwijze die je moet opzetten. In een Jira oid zit gewoon al 80/90% van wat ik hierboven opschrijf

[Swedish Clown]

RickyHeijnen schreef op maandag 1 mei 2017 @ 08:12:
[...]

Tsja, wat voor mij een groot project is, hoeft voor jou misschien niet groot te zijn. In dit geval heb ik het over een project waarbij ik weet dat er de komende 10 jaar structureel aan doorontwikkeld zal moeten worden. In eerste instantie begin ik er zelf alleen aan, maar de verwachting is groot dat ik binnen een jaar er een extra programeur op ga zetten en misschien ook nog wel een derde.
Het is dus niet zo, zoals iemand hierboven schreef, dat er een team van verschillende partijen (frontenders, backenders/hosting) aan gaat werken.

Ik probeer niet de botte lul uit te hangen maar weet je zeker dat je jezelf als (jonge) zzp'er een project van 10 jaar op de hals wilt halen? Even los van het feit dat ik niet de indruk krijg dat je er klaar voor bent, wil je jezelf voor 10 jaar vastzetten als zzp'er of mogelijkerwijs het project halverwege in de steek moeten laten of over te dragen. En Joe zit dat contractueel? Wat als je het project in de steek laat of moet overdragen? Zitten daar boetes aan vast of is hierover niks vastgelegd in het contract?

Ik heb er moeite mee om in te zien hoe een project van 10 jaar aan een zzp'er wordt overgelaten...

Los van bovenstaande, zorg voor een fatsoenlijke OTAP straat, deploy via Jenkins of soortgelijke, gebruik docker/vagrant voor lokaal development en lees je in over git-crypt voor het bewaren van je secrets. Dit gecombineerd met gpg keys moet zeker in de basis een goed begin zijn.

Oh en stap vandaag nog af van communicatie via mail of whatsapp maar switch naar iets als JIRA. Daar zal je werk een stuk overzichtelijker van worden

[ Voor 5% gewijzigd door Swedish Clown op 01-05-2017 19:48 ]

[Ramon]

Voor deployment kan je bijv https://deployhq.com/ gebruiken, of, voor deployment + git hosting http://beanstalkapp.com/

Beanstalk heb ik zelf op mijn vorige baan gebruikt, werkte prima!

Verwijderd schreef op vrijdag 28 april 2017 @ 23:29:
Werk je op Windows of Linux?

Dat onderscheid is tegenwoordig irrelevant, je kan gewoon Linux op Windows draaien:

[ Voor 43% gewijzigd door Ramon op 01-05-2017 20:37 ]

[DJMaze]

RickyHeijnen schreef op vrijdag 28 april 2017 @ 23:42:
Werk zelf op Windows maar de applicatie komt in een Linux omgeving te draaien.

En ga je dan CR+LF of LF gebruiken als EOL?

RickyHeijnen schreef op maandag 1 mei 2017 @ 08:12:
Tsja, wat voor mij een groot project is, hoeft voor jou misschien niet groot te zijn. In dit geval heb ik het over een project waarbij ik weet dat er de komende 10 jaar structureel aan doorontwikkeld zal moeten worden. In eerste instantie begin ik er zelf alleen aan, maar de verwachting is groot dat ik binnen een jaar er een extra programeur op ga zetten en misschien ook nog wel een derde.
Het is dus niet zo, zoals iemand hierboven schreef, dat er een team van verschillende partijen (frontenders, backenders/hosting) aan gaat werken.

Is het dan niet verkapte loondienst? (Checken bij de belastingdienst)
Wat als jij ziek/arbeidsongeschikt wordt?
etc. etc. etc.

RickyHeijnen schreef op maandag 1 mei 2017 @ 08:12:
Ten eerste omdat er bij dat soort klanten altijd te weinig budget is en te veel wensen haha.

Dan zou ik toch even de contracten nakijken. Geen budget = gezeik met betalen.

RickyHeijnen schreef op maandag 1 mei 2017 @ 08:12:
Het is nog bijv. nog nooit nodig geweest om een aparte testomgeving op te zetten. Ik werk lokaal via wamp en de klant test het uiteindelijk in productieomgeving. De klant communiceert via mail of whatsapp; het zijn altijd korte lijntjes.
Ik begrijp goed dat dit alleen kan als je alleen werkt. Als er al een tweede developer bij komt dan is er al direct veel meer structuur nodig in een project.

Je werkwijze klopt niet, zelfs niet als je alleen werkt.
Ik heb ook een éénmanszaak zonder personeel, maar:
- alles staat in repositories
- de hosting heeft automatische backups
- alles volgens PCI DSS, ISO 27001, ISO 9001, NEN 7510 en ISAE 3402 type 1 (kost bakken met geld)
- zonder PGP geen gevoelige data over e-mail/whatsapp
- een bedrijf met personeel is mijn backup bij onverwachte staking van mijn werkzaamheden (en ik help hun waar nodig)

Als je deze middelen niet op orde hebt, zou ik als ik jou was de opdracht nog maar eens heroverwegen.

Ik begrijp wel waarom je klus aanneemt. Elk vast inkomen is een zorg minder en scheelt je veel investering in het zoeken naar werk.
Daarbij is dus een felicitatie ook wel gepast, dus bij deze: gefeliciteerd!

[ Voor 4% gewijzigd door DJMaze op 01-05-2017 20:46 ]

[RickyHeijnen]

DJMaze schreef op maandag 1 mei 2017 @ 20:42:
En ga je dan CR+LF of LF gebruiken als EOL?

Ik heb alleen mn IDE in Windows. Ontwikkelen, testen en productie is in Linux dus gebruik LF als EOL. Maar snap niet goed waarom deze vraag relevant is?

DJMaze schreef op maandag 1 mei 2017 @ 20:42:
Is het dan niet verkapte loondienst? (Checken bij de belastingdienst)
Wat als jij ziek/arbeidsongeschikt wordt?

Dat sowieso niet, ik bedien meerdere klanten waar ik al jaren voor werk. Werk gewoon vanuit mijn eigen kantoor en zeker niet meer dan 20% van m'n tijd zal in dit project gaan zitten.

DJMaze schreef op maandag 1 mei 2017 @ 20:42:
Je werkwijze klopt niet, zelfs niet als je alleen werkt.
Ik heb ook een éénmanszaak zonder personeel, maar:
- alles staat in repositories
- de hosting heeft automatische backups
- alles volgens PCI DSS, ISO 27001, ISO 9001, NEN 7510 en ISAE 3402 type 1 (kost bakken met geld)
- zonder PGP geen gevoelige data over e-mail/whatsapp
- een bedrijf met personeel is mijn backup bij onverwachte staking van mijn werkzaamheden (en ik help hun waar nodig)

Als je deze middelen niet op orde hebt, zou ik als ik jou was de opdracht nog maar eens heroverwegen.

Dan werk jij in een ander segment van de IT branche dan ik. Ik hanteer voor ICT begrippen een laag uurtarief, niet omdat ik niet rijk wil worden, maar omdat ik juist automatisering toegankelijk wil maken voor de kleine ondernemer die geen € 60+ per uur kan betalen, maar wel graag vooruit wilt komen door te automatiseren. Dat is voor mij een bewuste keuze.

Ik begrijp dat het jarenlang vasthouden aan een dezelfde werkwijze (development via Wamp, uploaden via FTP, communicatie via mail/whatsapp, testen in productie) mij nu in deze positie heeft gebracht dat ik even een inhaalslag moet maken, maar dat is ook de reden voor het openen van dit topic

DJMaze schreef op maandag 1 mei 2017 @ 20:42:
Ik begrijp wel waarom je klus aanneemt. Elk vast inkomen is een zorg minder en scheelt je veel investering in het zoeken naar werk.
Daarbij is dus een felicitatie ook wel gepast, dus bij deze: gefeliciteerd!

De reden van het aannemen van deze klus is omdat deze persoon mij hier zelf persoonlijk voor benaderd heeft omdat hij mijn werkwijze kent. Vast inkomen is niet de reden. Dank voor de felicitatie

Uit een aantal reacties hierboven krijg ik het beeld dat sommigen het idee hebben ik als een of andere prutser bezig ben. Laat ik even voorop stellen dat ik me profileer als een PHP developer en me ook altijd verdiep in de laatste ontwikkelingen op PHP vlak. Ik hoop na een aantal van jullie tips (waarvoor dank ) uitgeprobeerd te hebben ook de projectmanagement taken wat professioneler aan te kunnen pakken.

[DJMaze]

RickyHeijnen schreef op dinsdag 2 mei 2017 @ 11:07:
Ik heb alleen mn IDE in Windows. Ontwikkelen, testen en productie is in Linux dus gebruik LF als EOL. Maar snap niet goed waarom deze vraag relevant is?

Simpel.
- Als je FTP client op "text" mode staat i.p.v. "binary" gaat ie de line endings aanpassen.
- Als iemand anders werkt op Windows en zijn editor staat op CR+LF krijg je vreemde kapriolen in je bestanden
- Git/Mercurial zien line-endings binair, dus als iemand bestanden opslaat met CR+LF terwijl het LF was, dan is het hele bestand aangepast (en niet die ene regel)

E-mails zijn trouwens altijd CR+LF

[ Voor 17% gewijzigd door DJMaze op 02-05-2017 13:43 ]

[Creepy]

Met git kan je prima configgen wat ie met de line endings moet doen zodat ze altijd op dezelfde manier in de repo staan. Dat lost alle vreemde capriolen en diffs op. Zit je alleen nog met de FTP. Maar FTP gebruiken voor deployments. Pak dan iets van SCP.

[MSalters]

Sowieso, je deployt een .tgz of andere package. Los deployen van honderden html, js, css filetjes is geen succces. Dus die line endings zijn niet zo'n probleem, de package is een binary (want gecomprimeerd).

Maar met ^^ramon. Met de Windows 10 Creator update kun je zelfs cross-subsystem processen opstarten, dus vanuit Bash kun je gewoon Notepad starten en vanuit CMD.EXE vi.

[RickyHeijnen]

Mister GT schreef op zaterdag 29 april 2017 @ 17:34:
Voor development heb ik op mijn laptop een aantal Docker containers runnen (phpdocker.io kun je makkelijk wat Docker config files genereren). Eén voor pgsql en een voor Apache/PHP. Dmv wat fixtures kan ik makkelijk dummy data in de database pompen als ik dat nodig heb. Wijzigingen aan de db structuur kun je eenvoudig bijhouden in migrations. Gezien ik gebruik maak van Symfony gebruik ik hiervoor de DoctrineMigrationsBundle.

Ik ben zelf al een aantal weken bezig met Oracle Virtualbox icm Vagrant. Ik begrijp dat Docker wel degelijk iets anders is dan Vagrant, maar kom er niet goed achter wat het wezenlijke verschil is. Iemand die dat misschien kan toelichten?

[Ramon]

MSalters schreef op dinsdag 2 mei 2017 @ 15:56:
Sowieso, je deployt een .tgz of andere package. Los deployen van honderden html, js, css filetjes is geen succces. Dus die line endings zijn niet zo'n probleem, de package is een binary (want gecomprimeerd).

Mwah, als je een tool hebt die een diff doet en automatisch de wijzigingen upload, dan kan dat ook 'los' via FTP.

Ik denk dat het voor TS belangrijk is dat de workflow zo simpel mogelijk is. Zeker als je, zoals je zegt, er 20% van je tijd mee bezig bent wil je dat als je eens een weekje of wat er niets aan hebt gedaan en er terug aan gaat werken, dat je niet bent vergeten wat je allemaal moet doen voor een deploy. Jenkins heb ik ook wel eens naar gekeken en dat lijkt me voor de TS niet geschikt want het is echt een vak apart om dat goed in te richten, niet echt iets voor een 1-dag-in-de-week-klus.

Ook als je anderen makkelijk bij je project wil betrekken is het belangrijk om het simpel te houden.

[Gomez12]

RickyHeijnen schreef op dinsdag 2 mei 2017 @ 19:55:
[...]
Ik ben zelf al een aantal weken bezig met Oracle Virtualbox icm Vagrant. Ik begrijp dat Docker wel degelijk iets anders is dan Vagrant, maar kom er niet goed achter wat het wezenlijke verschil is. Iemand die dat misschien kan toelichten?

Op zijn simpelst gezegd : Virtualbox emuleert een 100% x86 pc, als je die opstart zie je ook echt een bios logo etc voorbij komen. Dat is gewoon echt 100% een pc in je pc.

Docker is slechts een subset van een OS. En emuleert geen x86 calls maar voert die native uit.

Je ziet het bijv aan het opstarten, bij Virtualbox ben je gewoon 10 seconden opstarttijd oid kwijt omdat de hele x86 en daarna het hele OS geboot moet worden waarna pas het programma start.
Bij Docker start je enkel het programma en zorgt je OS voor de scheiding, oftewel je programma start meteen.

Let wel dat dit supersimpel gezegd is en zeker qua Virtualbox is het een erg oude weergave, vanwege optimalisaties en om snelheid te krijgen is de keiharde scheiding die er vroeger was steeds meer doorbroken.

Ramon schreef op dinsdag 2 mei 2017 @ 21:21:
[...]
Mwah, als je een tool hebt die een diff doet en automatisch de wijzigingen upload, dan kan dat ook 'los' via FTP.

Tja, je kan het ook aan een monnik dicteren die het voor je opschrijft zoals het in de middeleeuwen ging, maar effectief en efficiënt is het niet en zeker niet professioneel.

Ik denk dat het voor TS belangrijk is dat de workflow zo simpel mogelijk is.

Er is niet veel simpelers als een goed ingerichte CI.

Zeker als je, zoals je zegt, er 20% van je tijd mee bezig bent wil je dat als je eens een weekje of wat er niets aan hebt gedaan en er terug aan gaat werken, dat je niet bent vergeten wat je allemaal moet doen voor een deploy. Jenkins heb ik ook wel eens naar gekeken en dat lijkt me voor de TS niet geschikt want het is echt een vak apart om dat goed in te richten, niet echt iets voor een 1-dag-in-de-week-klus.

Jenkins is ook niet voor een 1-dag-in-de-week-klus. Dat soort tools hoor je gewoon te gebruiken bij elke klus als je een beetje professioneel wil pretenderen te zijn.

Juist al die hobby-bob oplossingen als ftp die difft en automatisch upload etc zijn zo ingewikkeld als de pest als je het goed wilt doen. Want eens ga je een asset erbij moeten zetten van 200MB oid en dan gooi je dus gewoon de hele site offline voor een onbepaalde tijd. Of je vergeet een keer te minifyen en al je js en css wordt even opnieuw automatisch geupload.
Voordat je het weet heb je met jouw "simpele oplossing" 10-tallen scripts etc draaien hele beschrijvingen over wat in welke volgorde moet draaien etc en je mag geen enkel foutje maken.

Terwijl jenkins gewoon simpel is : Je commit iets in je Versie Controle Systeem en je hebt een pakketje klaarstaan wat je kan deployen. Je hoeft nergens aan te denken, want alle stappen zijn beschreven binnen Jenkins en gebeuren zolang jij er niets aan verandert op dezelfde manier.

Desgewenst kan je ook in Jenkins beginnen met simpel uploaden via ftp bij een commit (alleen doe dat dan wel alleen op je test-omgeving want je gaat anders continue je live site slopen)

[cracking cloud]

Alles wat hierboven genoemd is + zorg dat er vooraf nagedacht is over security en dat het vooral geen dingetje achteraf is wat er nog ingeprutst moet worden. Gebruik daarvoor bestaande frameworks. Als je een pluralsight abbo hebt, bekijk dan eens wat filmpjes van Troy Hunt.

[Ramon]

Gomez12 schreef op dinsdag 2 mei 2017 @ 23:47:
[...]

Op zijn simpelst gezegd : Virtualbox emuleert een 100% x86 pc, als je die opstart zie je ook echt een bios logo etc voorbij komen. Dat is gewoon echt 100% een pc in je pc.

Docker is slechts een subset van een OS. En emuleert geen x86 calls maar voert die native uit.

Je ziet het bijv aan het opstarten, bij Virtualbox ben je gewoon 10 seconden opstarttijd oid kwijt omdat de hele x86 en daarna het hele OS geboot moet worden waarna pas het programma start.
Bij Docker start je enkel het programma en zorgt je OS voor de scheiding, oftewel je programma start meteen.

Let wel dat dit supersimpel gezegd is en zeker qua Virtualbox is het een erg oude weergave, vanwege optimalisaties en om snelheid te krijgen is de keiharde scheiding die er vroeger was steeds meer doorbroken.


[...]

Tja, je kan het ook aan een monnik dicteren die het voor je opschrijft zoals het in de middeleeuwen ging, maar effectief en efficiënt is het niet en zeker niet professioneel.

Tja als in jouw mening enkel Jenkins professioneel is en andere tools zoals hierbovengenoemde beanstalk blijkbaar amateuristisch, dan zijn we snel uitgediscussieerd natuurlijk.

Tis natuurlijk wel cool om te schermen met "professioneel" dit en dat. Maar professioneel betekent alleen of iemand er geld mee verdient. Heeft dus weinig te maken met welke tools je wel of niet gebruikt.

[...]

Er is niet veel simpelers als een goed ingerichte CI.


[...]

Jenkins is ook niet voor een 1-dag-in-de-week-klus. Dat soort tools hoor je gewoon te gebruiken bij elke klus als je een beetje professioneel wil pretenderen te zijn.

Juist al die hobby-bob oplossingen als ftp die difft en automatisch upload etc zijn zo ingewikkeld als de pest als je het goed wilt doen. Want eens ga je een asset erbij moeten zetten van 200MB oid en dan gooi je dus gewoon de hele site offline voor een onbepaalde tijd. Of je vergeet een keer te minifyen en al je js en css wordt even opnieuw automatisch geupload.
Voordat je het weet heb je met jouw "simpele oplossing" 10-tallen scripts etc draaien hele beschrijvingen over wat in welke volgorde moet draaien etc en je mag geen enkel foutje maken.

Terwijl jenkins gewoon simpel is : Je commit iets in je Versie Controle Systeem en je hebt een pakketje klaarstaan wat je kan deployen. Je hoeft nergens aan te denken, want alle stappen zijn beschreven binnen Jenkins en gebeuren zolang jij er niets aan verandert op dezelfde manier.

Desgewenst kan je ook in Jenkins beginnen met simpel uploaden via ftp bij een commit (alleen doe dat dan wel alleen op je test-omgeving want je gaat anders continue je live site slopen)

Volgens mij bedoelen we hetzelfde maar anders. Persoonlijk heb ik goede ervaringen met bovengenoemde beanstalk voor deployments, binnen 10 minuten heb je daar een setup met een testomgeving en een live-omgeving en een commit hook voor automatische deployments naar de testomgeving. Ik zou dat geen hobby-bob oplossing nemen.

Mijn ervaring met Jenkins echter was dat het zo uitgebreid was dat je er snel de weg in kwijt kan raken, maar dat is al een aantal jaar geleden, misschien is het inmiddels eenvoudiger op te zetten.

Ik wil maar zeggen, use the right tool for the job. Als de TS alles moet gaan doen wat hier in dit topic langskomt dan issie 2 maanden verder voordat er een letter code is geschreven. Het is ook prima om gedurende het project te groeien (zeker als dat toch 10 jaar gaat duren heb je daar tijd zat voor ). Je hoeft niet vanaf dag 1 een OTAP straat te hebben, OTP kom je ook een heel eind mee.

[Gomez12]

Ramon schreef op woensdag 3 mei 2017 @ 08:34:
[...]
Tja als in jouw mening enkel Jenkins professioneel is en andere tools zoals hierbovengenoemde beanstalk blijkbaar amateuristisch, dan zijn we snel uitgediscussieerd natuurlijk.

Het is een beetje jammer dat je in je ftp-post je niets zei over beanstalk maar dat dat een losse post was. Daardoor had ik de connectie gemist.

Beanstalk is in principe hetzelfde als Jenkins (of welke andere CI oplossing dan ook)

Ik begreep uit je ftp-post dat jij wilde voorstellen om vanaf je lokale schijf met filezilla oid wat files te gaan kopiëren.

Tis natuurlijk wel cool om te schermen met "professioneel" dit en dat. Maar professioneel betekent alleen of iemand er geld mee verdient. Heeft dus weinig te maken met welke tools je wel of niet gebruikt.

Tja laat ik het er maar ophouden dat dat jouw mening is, het neefje van de baas wat voor 5 euro per uur en 3 marsen werkt verdient er ook geld mee, maar ik noem hem niet professioneel.

[...]
Ik wil maar zeggen, use the right tool for the job. Als de TS alles moet gaan doen wat hier in dit topic langskomt dan issie 2 maanden verder voordat er een letter code is geschreven. Het is ook prima om gedurende het project te groeien (zeker als dat toch 10 jaar gaat duren heb je daar tijd zat voor ). Je hoeft niet vanaf dag 1 een OTAP straat te hebben, OTP kom je ook een heel eind mee.

Tuurlijk hoeft hij niet alles gelijk te doen, alleen ik zou het wel zo snel mogelijk zo goed mogelijk proberen in te regelen. Dan is het maar een maand zonder een letter code te schrijven, dit had al tig tijd geleden gebeurt moeten zijn.
Dit is simpelweg achterstallig onderhoud en hoe langer je dat uitstelt hoe ingewikkelder het wordt.

[Hiroj]

Je kan je in structurering al snel verdwalen, omdat er zoveel mogelijkheden zijn. Mijn advies is dan ook om alles met kleine stappen te implementeren.

Zo is het opzetten en gebruiken van GIT een goede eerste stap. Ook is het kijken naar bijv. Docker interessant om de juiste omgeving(en) lokaal in te richten, waar straks de applicatie op draait.

Wanneer je daadwerkelijk een applicatie hebt staan voor de klant, zou ik pas gaan kijken naar geautomatiseerde deployment. Je zit dan ook veel verder in de OTAP procedure.

Verder zou ik je willen aanraden, mits je het niet al doet, om PSR standaarden aan te houden. Zo kan een nieuwe ontwikkelaar zich prima wegwijs vinden in jouw code.

[DJMaze]

Hiroj schreef op donderdag 4 mei 2017 @ 08:12:
Zo is het opzetten en gebruiken van GIT een goede eerste stap.

Ik zou in zijn geval voor Mercurial kiezen ivm de handige GUI's op Windows OS.

Hiroj schreef op donderdag 4 mei 2017 @ 08:12:
Verder zou ik je willen aanraden, mits je het niet al doet, om PSR standaarden aan te houden.

Dit vind ik er van

PSR is leuk, maar geen heilige graal en bevat ook fouten.

En zo heeft iedereen gelukkig de vrijheid en een eigen mening hoe ze iets willen aanpakken

[ Voor 8% gewijzigd door DJMaze op 04-05-2017 09:54 ]

[RickyHeijnen]

Natuurlijk ga ik niet alles tegelijk doen, dat gaat ook niet omdat het in de praktijk altijd maar moet blijken wat voor mij het fijnste werkt. Al doende kom ik daar wel achter. Ik was vooral benieuwd naar de keuzes die jullie gemaakt hebben en do's en dont's.

Ik had al een account bij Github. Het is puur gevoel, maar ik heb het idee dat Github veel meer is ingericht op het delen, bijdragen en forken van open source projecten. Ik heb zitten kijken naar Beanstalk en het lijkt erop dat die tool (o.a. door de goede deployment tools) zich beter leent voor klant projecten. Maargoed eerst maar eens even mee stoeien. Ik ben wel bekend met Git zelf, dus dat is allemaal niet meer nieuw.

Ik ben nu ook bezig een OTP-straat op te zetten (OTAP is hiervoor echt overkill). Ik gebruik local.klantnaam.nl om lokaal te werken (met aanpassing in m'n hosts file). Logischerwijs zou ik dan test.klantnaam.nl gebruiken (uiteraard password protected) waar de klant kan testen en voortgang kan zien. Hoe doen jullie dit meestal?

[Stoelpoot]

RickyHeijnen schreef op vrijdag 5 mei 2017 @ 11:48:
Natuurlijk ga ik niet alles tegelijk doen, dat gaat ook niet omdat het in de praktijk altijd maar moet blijken wat voor mij het fijnste werkt. Al doende kom ik daar wel achter. Ik was vooral benieuwd naar de keuzes die jullie gemaakt hebben en do's en dont's.

Ik had al een account bij Github. Het is puur gevoel, maar ik heb het idee dat Github veel meer is ingericht op het delen, bijdragen en forken van open source projecten. Ik heb zitten kijken naar Beanstalk en het lijkt erop dat die tool (o.a. door de goede deployment tools) zich beter leent voor klant projecten. Maargoed eerst maar eens even mee stoeien. Ik ben wel bekend met Git zelf, dus dat is allemaal niet meer nieuw.

Ik ben nu ook bezig een OTP-straat op te zetten (OTAP is hiervoor echt overkill). Ik gebruik local.klantnaam.nl om lokaal te werken (met aanpassing in m'n hosts file). Logischerwijs zou ik dan test.klantnaam.nl gebruiken (uiteraard password protected) waar de klant kan testen en voortgang kan zien. Hoe doen jullie dit meestal?

GitLab heeft ook gratis private projecten en build tools. Het werkt IMO ook erg fijn, net als GitHub.