- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Peter Norton szerint a programozói hatékonyság növelésének legfontosabb eszköze a feladat halogatása. Mélységesen egyetértek vele!
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
- Fölösleges meetingek törlése
- A fejlesztő csapatoknak világos feladatok és autonómia adása
- Működő, no-nonsense CI infrastruktúra (valaki akassza fel Jenkinst, mert egy felhasználó-ellenséges vizuális trágyadomb)
- Gyorsan és kevés előzetes beállítással lefuttatható tesztek. (go test vagy mvn run test-nél ne legyen bonyolultabb, ha DB vagy API kell, ideálisan a teszt húzzon fel egyet.)
- Kellő idő hagyása innovációra, új dolgok kipróbálására, vagy takarításra a csapat saját hatáskörén belül.
- A hozzászóláshoz be kell jelentkezni
A leírtakkal egyetértek, Jenkins UI "véleményes", de ezt ők is látják, már dolgoznak rajta, kérdés mire jutnak vele.
Te melyik CI eszközt javaslod a Jenkins helyett (open-source, self hosted, jobokat lehessen kódban definiálni, legyen web ui, ahol az eredményeket értelmesen lehet követni)?
- A hozzászóláshoz be kell jelentkezni
+1, mi használtunk Jenkins-t, de nem tudom, azon vizuálisan mit kell nézegetni. :)
Ha megvolt a pull request a masterbe, akkor automatikusan indult a build. Volt egy-két speciális eset, amikor manuálisan kellett triggerelni, pl. bizonyos fájlokban ha módosítás volt, arra ment egy külön test suite. Ilyenkor a pull requestre rákerült egy komment, benne egy link, amit ha megnyomtál, az egyből elindította a megfelelő Jenkins buildet. Ha végzett, és zöld volt, akkor megjelölte a kommentben, hogy okés.
Másfél évig dolgoztam a projekten, szerintem a Jenkins UI-t konkrétan egyszer sem láttam. :)
- A hozzászóláshoz be kell jelentkezni
Mit használsz logok nézegetésére és artifactok letöltésére?
Plusz, ami nekem a GitHub Actionsben nagyon tetszett, hogy a futás közben tudsz a logba warningokat írni és azt egyből összeköti a Pull Request forráskód-review-jával.
- A hozzászóláshoz be kell jelentkezni
Ha teljesen open source-t szeretnél, nem tudok sajnos erre jó eszközt. Nekem nagyon jó tapasztalataim vannak a GitHub + self hosted runner kombóval, nagyon jól megcsinálták. Ebben a projektben eléggé kimaxoltuk, amit ki lehetett hozni a CI interfaceből.
- A hozzászóláshoz be kell jelentkezni
gitlab ci-vel van tapasztalatod? mennyivel jobb a githubos megoldás?
- A hozzászóláshoz be kell jelentkezni
Semennyi. Kolléga nézegette párhuzamosan a GitHubos kisérleteimmel, meg lehet csinálni ugyanazokat a dolgokat, de jóval reszelősebb. (Plusz neked kell hostolnod a magját.)
- A hozzászóláshoz be kell jelentkezni
A gitlab esetében is tudsz a gitlab.com-on projektet tartani, s oda is be tudsz dobni a saját self hosted runnereket 1-1 projektre, szóval szerintem ez nem issue. Nálunk kicsit komplexebb k8s környezeteket is menedzsel gitlabos CI, én meg vagyok vele elégedve. Mi ~5 éve, még egy nagyon régi Jenkins+Gerrit felállásról migráltunk ide, nem bántuk meg.
- A hozzászóláshoz be kell jelentkezni
Fölösleges meetingek törlése
Vagy megtölteni őket tartalommal, ha már úgyis van. :)
Több csapatnál látom, hogy a hatékonyság jegyében állandóan azon pörögnek, hogy egy planning/review hogy legyen rövidebb, miközben alapvető kérdések maradtak nyitva a user story-kban, szar volt a becslés, stb.
- A hozzászóláshoz be kell jelentkezni
YMMV, erősen. Feladatkörtől és cégkultúrától függ, hogy mennyi meetingre van szükség.
- A hozzászóláshoz be kell jelentkezni
Rá kell lépni a scrum master + csapat nyakára, hogy legyen jobb a definition-of-ready.
Ha van jó DoR akkor a csapatnak könnyű dolga van pipálni a kritériumokat és kisebb lehetősége van elbliccelni a gondolkozást.
Én sokszor azt látom, hogy gondos tervezés és lelkiismeretes végiggondolás helyett a felszínesség és a kapkodás jellemzi a kódereket, meg persze a végeláthatatlan rinyálás.
Egy jó DoR-el ezeket mind lehet kezelni.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni