[Java] Buildstraat as a service

[GarBaGe]

Iedereen in de software ontwikkeling weet wat een builstraat is.
Een setje van services om van je broncode tot aan werkende software te komen.

Op ons bedrijf staat zo'n straat lokaal.
Echter we kijken naar mogelijkheden om dit als een dienst af te nemen ipv alles lokaal.
Nu zijn er veel cloud providers ( digital ocean, cloud foundry, cloudbees, etc) die wolkjes aanbieden, maar dan moet je zelf de applicaties installeren en onderhouden ( via containers)
We zoeken naar meer en willen graag ook de applicaties onderhouden hebben.
De voorkeur gaat uit naar een oplossing zonder vendor lock-in. Dus IBM Bluemix is geen optie.

Waar zoek ik naar?
- source repo (bv github)
- buildserver (bv jenkins of teamcity)
- binary repo (bv nexus)
- qa (bv sonar)

Mogelijkheden tot uitbreiding, bv jira erbij

Wie van jullie heeft al een dergelijke setup?
Wat zijn jullie ervaringen hiermee?
Hoe flexibel zijn de oplossingen? Is het bv mogelijk om bij het bouwen een JDK + JCE te gebruiken ipv de default JDK met slecht beperkte cryptografische mogelijkheden?
Hoe werkt identificatie en autorisatie van de tools? Is er een gemeenschappelijke ldap of sso?

[ValHallASW]

Gezien je met Jira wilt integreren (en je dus toch al aan Atlassian vast zit): Bitbucket en Bamboo?

Andere oplossingen zijn Travis, Cloudbees, CircleCI, Appveyor (als je op Windows wilt bouwen), ...

Uiteindelijk is het onmogelijk om op basis van je post een zinnig advies te geven -- je zult eerst zelf helder moeten hebben wat je precies nodig hebt, en dan zal je gewoon rond moeten gaan kijken om te bepalen wat de mogelijkheden, kosten, en risico's zijn.

[GarBaGe]

Ik ben vooral geïnteresseerd in ervaringen van anderen.
Wat zijn jullie ervaringen met oplossingen zoals Travis, Cloudbees etc?

[Ed Vertijsment]

Wij hebben voor onze private repo's nog altijd een Jenkins machine staan, wij willen over naar jenkinsfiles zodat je "configuration as code" hebt en het makkelijker op andere machines/overal kan draaien, maar voor nu is dat nog allemaal in eigen beheer.

Voor open source libraries die wij onderhouden gebruiken wij Travis, dit integreert mooi met GitHub (er zijn ook andere tools voor bijvoorbeeld projectplanning die mooi met GitHub integreren. Travis werkt ook met "configuration as code" en dit werkt prima.

Het nadeel van Travis is dat het lastig kan zijn de build pipeline op te zetten, dit omdat je niet even een VM in kan om te debuggen.

[Hydra]

Wij gebruiken Gitlab on-prem voor source hosting, reviews en CI. Persoonlijk vind ik Gitlab CI veel beter werken dan Jenkins. Ik heb geen ervaring met de hosted versie en ga er vanuit dat het hetzelfde werkt. Tegenwoordig heeft het ook issue tracking / agile boards maar daarvoor gebruiken wij Jira.

We gebruiken ook Sonar en Nexus. Ook deze hosten we zelf (of nouja, een clubje van de ING doet dat voor ons). Ook daar zijn vast wel 'cloud' versies van te vinden. Gitlab kan in ieder geval docker containers en artifacts opslaan.

Ed Vertijsment schreef op zondag 17 september 2017 @ 10:49:
Wij hebben voor onze private repo's nog altijd een Jenkins machine staan, wij willen over naar jenkinsfiles zodat je "configuration as code" hebt en het makkelijker op andere machines/overal kan draaien, maar voor nu is dat nog allemaal in eigen beheer.

Kijk ook eens naar Gitlab. De repository zooi integreert erg netjes met de pipeline zooi, het zijn simpele config files in je repo. Daarnaast heeft Gitlab een erg goeie API: ik heb onlangs een release tooltje gemaakt dat al onze services kan releasen bovenop deze API.

[ Voor 37% gewijzigd door Hydra op 18-09-2017 10:34 ]

[Falcon]

Is er een specifieke reden om dit als dienst te willen afnemen?

[SiErRa]

Falcon schreef op maandag 18 september 2017 @ 10:40:
Is er een specifieke reden om dit als dienst te willen afnemen?

Ik vermoed dat het stiekem best veel uurtjes kost om het te beheren, die je liever aan software ontwikkelen besteedt.

Je definitie van een buildstraat is wel duidelijk, en daar heb ik geen voorbeelden van kunnen vinden bij 1 partij.
Maar er zijn partijen die complete ontwikkelstraat hosted aanbieden. Dus inclusief werkplekken, source repository, work item tracking, buildservers, testservers en zaken als SonarQube en Nexus. Die je waarschijnlijk niet allemaal hoeft af te nemen.

De reden dat ik dit ken, is dat mijn werkgever deze dienst aanbiedt, maar ik kom zo geen alternatieven tegen, al vermoed ik dat die er wel zijn. Om niet als een spammer over te komen mag je er zelf even naar googlen of mij een dm sturen

Ik kan dus geen objectieve review geven over een product van mijn eigen werkgever en daarnaast ben ik alleen gebruiker van de Microsoft variant van zo'n ontwikkelstraat.

[Tubby]

Klopt, dit soort dingen kunnen best bewerkelijk zijn om zelf in de lucht te houden.

En waar je terecht kan is ook afhankelijk van je bouwproces, als je specifiek praat over het CI gedeelte loopt het nogal snel in de papieren.

Als je een all-in-one oplossing zoekt moet je echt even kijken naar Gitlab, daar kun je b.v. ook voor het uitvoeren van de CI jobs met eigen runners werken zodat je de kosten een beetje binnen de perken houdt. Voor dingen als codeanalyse (SonarQube e.d.) moet je echt voor losse oplossingen kijken die wellicht ook weer te koppelen zijn.

Dat laatste geldt overigens ook voor je ticketing systeem. Als je op dit moment een eigen jira draait kun je die gewoon koppelen aan je de meeste van dit soort tooling. Probeer niet alles in 1 keer op te lossen zou ik zeggen . Maar voor de code-hosting ben ik zelf wel tevreden met bitbucket, dat is overal wel te gebruiken en is redelijk betaalbaar voor private repositories.

De wens voor gemeenschappelijke authenticatie moet je een beetje laten varen als je veel met cloud-tools werkt. Al werken een aantal tools wel met bitbucket authenticatie en wordt SAML2.0 (en dus office365) ook wel meer gemeengoed op dit vlak.

Voor je binary repo geldt een beetje hetzelfde als voor je CI, dit loopt nogal snel in de papieren aangezien de meeste afrekenen in GB's en zeker als je veel met feature versies werkt en/of docker images kan dat nogal snel gaan. Reken dat vooral ff door met je huidige private repo getalletjes .

[ Voor 30% gewijzigd door Tubby op 22-09-2017 16:05 . Reden: aanvulling authenticatie / binary repo ]

[Verwijderd]

Hydra schreef op maandag 18 september 2017 @ 10:30:
Wij gebruiken Gitlab on-prem voor source hosting, reviews en CI. Persoonlijk vind ik Gitlab CI veel beter werken dan Jenkins.

Dit kan ik beamen. Gitlab heeft écht hele mooie tooling voor wat betreft CI. Doordat je ook in Gitlab per project een Docker Registry erbij krijgt, kan je je applicaties dus direct als Docker images opslaan in Gitlab zelf.
In het geval van Java kan je vrij gemakkelijk bijvoorbeeld eerst je applicatie packagen als *.tar.gz, en met een ADD instructie in een Dockerfile de boel in een image gooien. Als je je image dan bijvoorbeeld laat deriveren van de openjdk:jre-alpine image, heb je in dat geval een overhead van ~80MB.

Dat is precies hoe ik het doe, en dat werkt echt perfect.

offtopic:
ben ik de enige wiens nekharen recht overeind gaan staan bij de term "buildstraat"?

[Hydra]

De overhead in size heeft niks te maken met je base image