Developers omgeving ervaringen

[semyazaruax]

Ha Tweakers, voor het bedrijf waar ik nu werk zijn wij bezig een professionaliseringsslag te maken. Ons development team word groter en we willen de dingen nu graag professionaliseren. Mijn vraag nu aan jullie is simpel, wat bevelen jullie aan -en wat zijn jullie eigen ervaringen? Hiermee doel ik dan op het volgende (we gebruiken allemaal PHPStorm, Webstorm en GitKraken).

- Jenkins, WMcity of een andere Continious Deployment Tool, of helemaal geen CDT? en waarom deze keuze?

- Vagrant, Docker, een andere of niks, en zo ja waarom deze keuze?

- Lokaal werken, online werken (of via Vagrant bijvoorbeeld) hiermee in het achterhoofd te houden dat er soms 5 of meer developers aan het zelfde project kunnen werken. Mergen met GitKraken is geen probleem maar wat is de meest efficiënte werkmanier? lokaal werken of gewoon online en dan met een test.mijndomein.nl en een live.mijndomein.nl om het zo even te zeggen of wat is jullie ervaring?

Dit soort dingen eigenlijk. Ik weet niet de juiste naam hiervoor maar een soort van "werkomgeving" zeg maar. Hoe ziet die van jullie er uit en wat zouden jullie mij kunnen aanbevelen om eens in te verdiepen?

In het kort is het zo dat wij grote projecten maken waaraan meerdere developers tegelijkertijd werken. We vinden het fijn om een "test" omgeving te hebben. Als alles werkt dan gaat het naar een "live" omgeving. We werken met Gitlabs (met GitKraken) als versiebeheer systeem. De talen die wij voornamelijk gebruiken (en databases) zijn:

HTML, CSS (SASS), PHP, Javascript, Typescript, Angular, NodeJS, MySQL(i), PDO. Natuurlijk de gebruikelijke dingen als Artisan (Laravel), NPM, en overige dingen die veel gebruikt worden.

Wij hebben momenteel Amazone servers met het Linux besturingssystemen draaien. Hierbinnen draait momenteel Jenkins, welke ook volledig werkt (dit was meer een test voor ons).

Ik hoop dat jullie wat suggesties voor mij hebben zodat ik een beetje een idee heb hoe andere dit aanpakken

[ Voor 11% gewijzigd door semyazaruax op 11-09-2017 08:38 ]

[Hydra]

Welke problemen probeer je precies op te lossen? Dat moet je eerst eens in kaar gaan brengen. We gebruiken in het project waar ik nu op zit de zaken die jij beschrijft, maar wel met redenen.

Ons project is een back-end met een flink aantal Java microservices. Deze worden automatisch gebouwd, getest, in een docker container verpakt en in ons kubernetes cluster gedeployed. Hiervan hebben we er vier; DEV, TST, ACC en PRD. Voor een dergelijke architectuur is CI/CD eigenlijk een voorwaarde; dat wil je niet allemaal met de hand doen.

Voor CI/CD zijn wij overgestapt van Jenkins naar Gitlab CI. Voor een groot deel omdat onze code in Gitlab staat en het mooi integreert. Jenkins is vrij out en zwaar. Maar Jenkins heeft wel weer als voordeel dat er voor vrijwel alles een plugin is.

Wij gebruiken Kubernetes als container orchestration tool. Werkt voor ons perfect. Je hebt er eigenlijk als het eenmaal staat geen omkijken meer naar.

Wat het belangrijkste is in zo'n 'professionaliseringsslag' is testen: zonder automatische tests is CI/CD vrijwel waardeloos. Ik weet niet of jullie dat op orde hebben maar zo niet; begin daar.

[Davidshadow13]

Wij hebben ook onze projecten een aantal maanden geleden gemigreerd van Jenkins naar GitLab CI, dat is qua integratie en gebruiksgemak echt een stap vooruit al merk je wel dat bij GitLab de CI/CD tooling nog een beetje in de kinderschoenen staat en nog niet alle functies die Jenkins heeft erin zitten. Ben zelf al een paar keer een vastgelopen omdat een triviale functie niet beschikbaar is maar daar is omheen te werken en het product zelf is in volle ontwikkeling. Al ben ik zelf eigenlijk nog meer fan van TeamCity maar dat terzijde.

Daarnaast ben ik het met @Hydra eens dat CI tooling eigenlijk weinig zin heeft als je geen geautomatiseerde tests hebt. Wij hebben een deployment straat met een Unit test build welke draait voor elke build en een set integratietesten welke elke nacht draaien. Alleen builds die alle tests doorstaan worden gedeployed (of in ons geval gebouwd en upgeload naar onze release site).

Ik zou als twee belangrijke speerpunten aanraden op te kijken naar geautomatiseerde tests. Dat is eigenlijk zowel unit testen van je code als integratie testen met bijvoorbeeld Selenium. Daarnaast zou ik eens kijken naar je versioning en of je dat op orde is. Semver (http://semver.org/) is daar een mooie oplossing voor en is makkelijk in Git te integreren.

[Hydra]

Davidshadow13 schreef op maandag 11 september 2017 @ 09:12:
Semver (http://semver.org/) is daar een mooie oplossing voor en is makkelijk in Git te integreren.

Wij hadden dat waarbij het gewoon <major>.<minor>.<builnummer> was maar voor onze services hebben we dat gewoon losgelaten en gebruiken gewoon alleen het buildnummer. Ook omdat we naar dagelijkse releases toewillen. Maar voor public facing spul is dat natuurlijk anders.

[Bigs]

Workflow is belangrijker dan tools.. hebben jullie wel eens nagedacht over een pull request workflow? Daarbij commit niemand meer direct naar master, maar doet een collega altijd eerst een (code) review. Dit heeft bij ons de kwaliteit en samenwerking een stuk verbeterd. Een tool als Gitlab kan hier uitstekend bij helpen en biedt een mooi geïntegreerd pakket van versiebeheer, issue tracker en CI/CD.

Wat betreft Docker/Vagrant (tijdens development neem ik aan), ook hier gaat het om workflow. Het doel is bij ons om nieuwe ontwikkelaars/machines snel aan de gang te hebben en consistente omgevingen te hebben (iedereen dezelfde versies van alles etc.). Eerst gebruikten we Vagrant met Puppet provisioning en inmiddels gebruiken we een combinatie van Docker met een lokale applicatie server (blog) zodat we maximale prestaties halen. Voor beiden geldt dat minimaal een persoon zich behoorlijk in de materie zal moeten verdiepen om een goed resultaat te halen. Dus ook hier is de vraag wat is je doel? Als jullie applicatie op dit moment prima ontwikkeld kan worden door het installeren van puur PhpStorm dan is het wellicht overkill.

[ Voor 11% gewijzigd door Bigs op 11-09-2017 09:35 ]

[Hydra]

@Bigs

Stukje over je blog:

Since I was getting excited about Docker anyway I put together a small Dockerfile to run our Rails app itself in a Docker container. This was easy enough and worked very well, but provided no performance benefit. As we did not want to run the app in Docker during development I decided to forego that on CI right now since it saves us from maintaining a Dockerfile and storing heaps of large Docker images in our registry.

Een image layer bevat alleen wat je erin stopt. Dus je stored niet bij iedere update van je applicatie de hele chain; alleen de laatste stap. Daarom maak je vaak een eigen 'base' image waar je runtime spul in staat en daarbovenop een applicatie image die iedere keer met een nieuwe versie geupdate wordt. Die zijn niet groter dan je applicatie zelf is.

[Laurens-R]

Bigs schreef op maandag 11 september 2017 @ 09:32:
Workflow is belangrijker dan tools.. hebben jullie wel eens nagedacht over een pull request workflow? Daarbij commit niemand meer direct naar master, maar doet een collega altijd eerst een (code) review. Dit heeft bij ons de kwaliteit en samenwerking een stuk verbeterd. Een tool als Gitlab kan hier uitstekend bij helpen en biedt een mooi geïntegreerd pakket van versiebeheer, issue tracker en CI/CD.

Doen wij ook binnen 1 van mijn projecten. Ik ben QA manager op dat project en het maakt mijn werk een stuk gemakkelijker Een senior dev die het werk controleerd en geen rotzooi toelaat in master. Heerlijk!

[Bigs]

Laurens-R schreef op maandag 11 september 2017 @ 10:45:
[...]


Doen wij ook binnen 1 van mijn projecten. Ik ben QA manager op dat project en het maakt mijn werk een stuk gemakkelijker Een senior dev die het werk controleerd en geen rotzooi toelaat in master. Heerlijk!

Dat en als je het goed aanpakt krijg je een positieve boost in je cultuur waar mensen elkaar op een positieve manier feedback geven en kennis uitwisselen naar aanleiding van praktijkvoorbeelden.

_{Waarschuwing: Het kan ook aanleiding zijn tot eindeloze discussies over code stijl die er anders nooit waren geweest..}

[ Voor 11% gewijzigd door Bigs op 11-09-2017 11:01 ]

[semyazaruax]

Goede antwoorden! dankjullie wel! veel informatie al

Ik zal proberen om goed uit te leggen wat wij willen bereiken en via welke manier.

Wij willen bij elk project zo snel mogelijk kunnen beginnen. Dus elke developer moet snel en simpel binnen no-time een nieuw project kunnen starten, of deel nemen aan een bestaand project waarin dingen gebruikt kunnen worden zoals Ruby, NPM, Node, Angular, PHP, PDO en MySQL bijvoorbeeld. Het scheelt tijd als dit niet elke keer opnieuw geïnstalleerd en geconfigureerd hoeft te worden.

Binnen één en het zelfde project kunnen meerdere developers werken. Bijna nooit in de zelfde bestanden, maar het kan wel voorkomen. We werken via Scrum (net mee begonnen) wat inhoud dat het werk wat we maken door ons zelf getest gaat worden (we gaan ook Unit testing gebruiken!). Nadat het door ons goedgekeurd is word het op de "echte live server" gezet en een laatste keer bekeken (getest) door iemand anders.

Er zit dus een tussen fase in, in het ideale plaatje. Dus alles staat op server (of locatie) A. Hier word het ontwikkeld en getest, waarna het naar server (of locatie) B gezet wordt.


Voorheen was het rommelig, sommige werkten lokaal, sommige direct online, en zo voort. Aan het eind alles pushen (en mergen dus) en klaar, Jenkins zet het meteen live (geen push naar development maar naar live). Geen echte worflow dus

Ons doel is eigenlijk om een goede, soepele manier te vinden van werken. Developers werken op x-omgeving, vervolgens gaat het naar een testomgeving (als we lokaal werken bijvoorbeeld) en daarna naar een live omgeving. Alles in versiebeheer en automatisch gebuild en online gezet. Nieuwe projecten kunnen snel en simpel gemaakt worden zonder "server" kennis nodig te hebben.

Hoop dat het zo een klein beetje duidelijk is we zoeken dus eigenlijk gewoon een goede manier van werken van A tot Z, omdat we nu eigenlijk niks hebben en gewoon aan hebben lopen kloten, grofweg gezegd

[Hydra]

semyazaruax schreef op maandag 11 september 2017 @ 11:01:
Wij willen bij elk project zo snel mogelijk kunnen beginnen. Dus elke developer moet snel en simpel binnen no-time een nieuw project kunnen starten, of deel nemen aan een bestaand project waarin dingen gebruikt kunnen worden zoals Ruby, NPM, Node, Angular, PHP, PDO en MySQL bijvoorbeeld. Het scheelt tijd als dit niet elke keer opnieuw geïnstalleerd en geconfigureerd hoeft te worden.

Maar dat doe je neem ik aan eenmalig? Dingen als databases installeer ik nooit meer, dat doe ik via Docker. Maar je ontwikkelspullen zelf, inclusief bijvoorbeeld een IDE, is altijd nog een kwestie van installeren. Docker is niet echt een oplossing voor het 'snel' op laten starten van een nieuwe dev. Vooral als die persoon ook nog eens nooit met Docker gewerkt heeft.

Waar Docker wel handig in kan zijn is als je als dev met meerdere versies van hetzelfde platform moet werken. Dus als je verschillende versies van NodeJS bijvoorbeeld tegelijkertijd moet gebruiken.

Binnen één en het zelfde project kunnen meerdere developers werken. Bijna nooit in de zelfde bestanden, maar het kan wel voorkomen. We werken via Scrum (net mee begonnen) wat inhoud dat het werk wat we maken door ons zelf getest gaat worden (we gaan ook Unit testing gebruiken!). Nadat het door ons goedgekeurd is word het op de "echte live server" gezet en een laatste keer bekeken (getest) door iemand anders.

Ik neem aan dat jullie Git gebruiken voor versie management?

En je zult eerst aan de slag moeten gaan met unit testen. Aan CI/CD beginnen heeft voor jullie op dit moment echt helemaal geen zin. Je deployed het dan automatisch. En dan? Het moet met de hand getest worden. Dan kun je net zo goed met de hand een deploy script runnen.

Er zit dus een tussen fase in, in het ideale plaatje. Dus alles staat op server (of locatie) A. Hier word het ontwikkeld en getest, waarna het naar server (of locatie) B gezet wordt.

Ik vind het nog nieteens het ideale plaatje. Het is echt de basis. Je deployed op een test server en nooit rechtstreeks op productie.

Je werkt hoe dan ook altijd lokaal. Je gaat niet rechtstreeks op een gedeelde server code zitten aanpassen. Die gedeelde server is om te kijken of je zooi nog samenwerkt met andere changes, niet om de aanpassingen te doen.

Ons doel is eigenlijk om een goede, soepele manier te vinden van werken. Developers werken op x-omgeving, vervolgens gaat het naar een testomgeving (als we lokaal werken bijvoorbeeld) en daarna naar een live omgeving. Alles in versiebeheer en automatisch gebuild en online gezet. Nieuwe projecten kunnen snel en simpel gemaakt worden zonder "server" kennis nodig te hebben.

Je moet beginnen om dit (werk lokaal, integratie op een test omgeving, dan een push naar productie) er eerst kwa procedures in te krijgen. Tooling lost geen mensenproblemen op.

Laurens-R schreef op maandag 11 september 2017 @ 10:45:
Doen wij ook binnen 1 van mijn projecten. Ik ben QA manager op dat project en het maakt mijn werk een stuk gemakkelijker Een senior dev die het werk controleerd en geen rotzooi toelaat in master. Heerlijk!

Da's niet helemaal het idee achter 'peer reviews' maar goed. Ik snap dat je die aanpak hanteert als het niveau erg uiteenloopt.

[ Voor 7% gewijzigd door Hydra op 11-09-2017 11:17 ]

[semyazaruax]

Duidelijk antwoord Hydra en volledig ter rechte punten! ik ga mij zelf dan eerst hier eens in verdiepen. Onze keuzen was op PHP Unit gevallen, mede omdat we met Laravel werken en het hier al in zit en wij tevreden zijn hierover. Ik ga wat onderzoek doen en zal later delen wat ons besluit is geworden. Dankjewel voor jullie antwoorden, veel stof om over na te denken en veel goede punten!

P.S. één vraag... stel iedereen werkt lokaal... aan het zelfde project. Ik maak een wijziging in de database... dan moet iedereen die handmatig ook doen... dit is toch niet handig? kan dit op een snelle en efficiënte manier?

Overigens als laatste aanvulling. We hebben hier (oh my god lol...) mensen zitten die met Windows werken, mensen met MacOS en een paar met Linux. Vandaar dat we een "unified" omgeving wilde waarin het niet veel uitmaakte

[ Voor 37% gewijzigd door semyazaruax op 11-09-2017 11:31 ]

[Bigs]

semyazaruax schreef op maandag 11 september 2017 @ 11:20:
[..]

P.S. één vraag... stel iedereen werkt lokaal... aan het zelfde project. Ik maak een wijziging in de database... dan moet iedereen die handmatig ook doen... dit is toch niet handig? kan dit op een snelle en efficiënte manier?

[..]

Ik neem aan dat Laravel iets wel als database migraties heeft?

Zo te horen hebben jullie nog een hoop werk te verzetten. Maak eens een prioriteitenlijst voor jezelf en ga rustig met een of twee punten tegelijk aan de slag.

[semyazaruax]

Klopt Laravel heeft migrations, maar een custom website niet echt. Dan moet je handmatig elke keer de aanpassingen doorvoeren bij alle andere mensen haha... is daar niks op te verzinnen?

[Bigs]

semyazaruax schreef op maandag 11 september 2017 @ 11:44:
Klopt Laravel heeft migrations, maar een custom website niet echt. Dan moet je handmatig elke keer de aanpassingen doorvoeren bij alle andere mensen haha... is daar niks op te verzinnen?

Je weet het antwoord al: Een framework gebruiken zodat je het wiel niet elke keer opnieuw hoeft uit te vinden.

Standaardisatie is ook onderdeel van professionaliteit.

[jbdeiman]

semyazaruax schreef op maandag 11 september 2017 @ 11:44:
Klopt Laravel heeft migrations, maar een custom website niet echt. Dan moet je handmatig elke keer de aanpassingen doorvoeren bij alle andere mensen haha... is daar niks op te verzinnen?

Zeker wel, maar dat vergt wel tijd aan jullie kant: Voor die standaardisatie moet je zorgen dat bij een deploy altijd bepaalde "database patches" gedaan worden, dan hoeft men dit niet handmatig te doen.

[semyazaruax]

Oke duidelijke antwoorden weer. Ik merk dat we inderdaad eerst een lijstje moeten maken met wat we nu willen, en via welke weg voordat we keuzes kunnen gaan maken. Ook met oog op het patches zoals je net al vertelde

Nogmaals dank allemaal, super informatie hier in korte tijd!

[Laurens-R]

Hydra schreef op maandag 11 september 2017 @ 11:16:
[...]

Da's niet helemaal het idee achter 'peer reviews' maar goed. Ik snap dat je die aanpak hanteert als het niveau erg uiteenloopt.

Je hebt helemaal gelijk, maar ik probeerde in mijn stelling vooral aan te geven hoe het mij als QA manager helpt in mijn dagelijkse werk helpt op een pragmatisch niveau. Ik begrijp heel goed dat het voor het team in het algemeen nog veel meer voordelen heeft, maar die liet ik voor het gemak even buiten beschouwing Voor mij als QA manager is het gemakkelijk dat een dergelijk systeem een controle proces afdwingt. Dan weet ik zeker dat men uberhaubt een peer-review doet. Dat maakt het voor mij ook makkelijker om aan te tonen naar de stakeholders dat wij onze zaken procesmatig goed op orde hebben en heb ik een systeem waarin ik meetbaar op basis van rapportages kan aantonen dat het proces bij ons functioneerd

Het 1 sluit het ander niet uit

[ Voor 6% gewijzigd door Laurens-R op 11-09-2017 12:42 ]

[Hydra]

semyazaruax schreef op maandag 11 september 2017 @ 11:20:
P.S. één vraag... stel iedereen werkt lokaal... aan het zelfde project. Ik maak een wijziging in de database... dan moet iedereen die handmatig ook doen... dit is toch niet handig? kan dit op een snelle en efficiënte manier?

Database changes moeten een onderdeel van je deployment worden. Daar heb je tools als Flyway voor. Als je CI/CD doet kun je dat niet meer handmatig gaan doen; zo'n tool houdt zelf bij welke changes gedaan worden.

Dan hoef je dat dus alleen nog maar in je locale env te doen, maar dat is simpel. Dat doe ik zelf ook in m'n lokale database (we gebruiken Cassandra).

Overigens als laatste aanvulling. We hebben hier (oh my god lol...) mensen zitten die met Windows werken, mensen met MacOS en een paar met Linux. Vandaar dat we een "unified" omgeving wilde waarin het niet veel uitmaakte

Ja, da's logisch. Dan is Docker erg handig. Wat natuurlijk niet wegneemt dat je als je op windows linux docker containers wil Deployen altijd nog onderwater een kleine Linux VM hebt draaien. Docker is geen VM namelijk; het is process isolation.

Laurens-R schreef op maandag 11 september 2017 @ 12:40:
Je hebt helemaal gelijk, maar ik probeerde in mijn stelling vooral aan te geven hoe het mij als QA manager helpt in mijn dagelijkse werk helpt op een pragmatisch niveau. Ik begrijp heel goed dat het voor het team in het algemeen nog veel meer voordelen heeft, maar die liet ik voor het gemak even buiten beschouwing Voor mij als QA manager is het gemakkelijk dat een dergelijk systeem een controle proces afdwingt. Dan weet ik zeker dat men uberhaubt een peer-review doet. Dat maakt het voor mij ook makkelijker om aan te tonen naar de stakeholders dat wij onze zaken procesmatig goed op orde hebben en heb ik een systeem waarin ik meetbaar op basis van rapportages kan aantonen dat het proces bij ons functioneerd

Het ging me er vooral om dat peer reviews betekent dat iedereen elkaar reviewt. Niet dat een paar senior devs de juniors reviewen.

[ Voor 28% gewijzigd door Hydra op 11-09-2017 13:42 ]

[Bigs]

Hydra schreef op maandag 11 september 2017 @ 13:41:
[...]

Ja, da's logisch. Dan is Docker erg handig. Wat natuurlijk niet wegneemt dat je als je op windows linux docker containers wil Deployen altijd nog onderwater een kleine Linux VM hebt draaien. Docker is geen VM namelijk; het is process isolation.


[...]

Dat is op de Mac ook het geval, maar dat werkt aardig transparant. Dus in die zin kan ik Docker zeker aanbevelen.

[Hydra]

Bigs schreef op maandag 11 september 2017 @ 13:49:
Dat is op de Mac ook het geval, maar dat werkt aardig transparant. Dus in die zin kan ik Docker zeker aanbevelen.

Idem