Super, skoda iba, ze u dost firiem sa tieto postupy zvrhnu na klasicku byrokraciu. Tj mame jenkins, metriky, jira, javadoc , predpisanie formatovanie a na konci v kode sracky len preto, ze kvalita kodu vyzaduje aj cas na co vacsina firiem .... .a realita je buzeracia, ze riadok je dlhsi ako 100znakov lebo tomuto kriteriu rozumie aj debil ale to ze uz v prvej verzii sa musia robit v kode "sialenosti" aby to slo (ved potom to fixneme) to pre zmenu netrapi skoro nikoho. Ved jenkins hlasi ok, pokrytie testami super(ale realne pokryte tak 20% a aj to len spravne parametre) a dokumentacia tiez (citaj eclipse generuje stuby pre javadoc). Uz len treba vygenerovat grafy pre vedenie a do firemneho platku napisat odu na projekt. Samozrejme plus fotka teamu plna optimizmu.
Tyhle nastroje je potreba brat s rezervou. Veci jako SonarQube jsou eye-candy pro management. Nekdo bez zkusenosti, bez praxe, muze snadno zkontrolovat jestli se vyvojari "neflakaji". Pokud to ale nasadi manager bez praxe, a pouziji se kontroly ktere vytvoril uhrovity pubertak bez zkusensti tak je z toho "prus**r".
Schvalne se kouknete na stackoverflow kolik zoufalcu se snazi napsat SQL dotaz "GROUP BY" tak aby v nem nebylo "GROUP BY". Jenom proto, aby jim kod prosel touhle sr**kou.
Bohuzel i Jave existuji ruzne ideologie, a jeden ze zpusobu, jak ostatnim vnutit svoje nabozenstvi je vytvorit test pro Sonar, ktery neco vynucuje.
Tyhle nástroje musí sloužit pro vývojáře a být nastaveny podle jejich potřeb. Pokud o tom jak to mají dělat rozhoduje někdo jiný jinde, tak to nikdy nebude dobře fungovat (a to platí i pro případy, kdy tomu skutečně lépe rozumí - viz různé offshoringové historky).
Druhá věc je, že z každého pravidla musí existovat výjimka - musí ji ale někdo zodpovědně schválit a zvážit. Háček je ale v tom zodpovědně.
Třetí věc je, že hlavním problémem ve vývoji SW jsou lidé, takže se jedná a vždy bude jednat o válku různých ideologií (protože lidé ideologie mají - pokud někdo tvrdí že ideologii nemá, tak to většinou znamená jen že tu svoji nepočítá nebo ji považuje za přírodní zákon).
1) Bamboo jako samostatne stojici jednotka nema smysl, jeho sila je jako kolecko v soukoli Atlassian stacku. kdybych nemel Jira a bitbucket na svym tak se nikdy nerozhodnu pro bamboo.
2) jestlize Bamboo konci tak je vice nez ocekavatelne, ze jeho ulohu maji prevzit nove Pipelines v bitbucketu - tedy reakce prave na gitlab CI.
tak tendle clanek je snuska bludu. na konci zmateny shrnuti Jak jsme si ukázali, kontinuální integrace zahrnuje řadu činností. Pokud je má odbavovat člověk, prostor pro chyby je velký, časová náročnost a požadavky na znalosti také nejsou zanedbatelné.. nic jsme si neukazali a o nicem takovem nebyla zminka
1. rikat, ze Bamboo je neprehledny, protoze ma stages, jobs etc... Jenkins je CI, Bamboo je CD
2. $800 za rocni licenci? pokud todle je drahy a "vyplati se" se nakonfigurovat Jenkins, tak nevim kolik by mel stat profi nastroj. a opet na konci uplny rozpor Jeho výběr mohou ovlivňovat různá kritéria, osobně navrhuji nebrat v potaz jenom cenu samotného nástroje, ale i to co umí a jak dobře se s ním pracuje – notifikace, možnost integrace na další služby, uživatelské rozhraní.
3. zacinat clanek notifikacema? chvili jsme myslel, ze jsem preskocil nejaky odstavec, ale ono ne
4. nasel jsem ublognuti, kde je podezrele dost textu zkopirovano sem. nemel by byt tendle clanek oznacen jako reklamni?
5. mateni pojmu CI a CD!!!
celkove clanek o nicem. sigh
muze mi prosim autor osvetlit:
> reálný provoz se pak pohybuje od 800 dolarů za rok.
My realne provozujeme Bamboo za $10 / rok. Ano jsme mala firma. Ale firma ktera potrebuje tu vyssi licenci, ze by mela problem s tema par drobnyma? Stejny je to s jira. Jsem si jisty, ze az budu mit celkem 10 useru v jira tak budu mit spoustu jinych starosti nez resit nejakej tisic dolacu za licenci.
Cenová politika Atlassianu je dost zrádná. Začali jsme používat v týmu Confluence s argumentem, že do 10 uživatelů je to jen za $10. Po nějakém čase se ukázalo, že tam občas potřebují i lidé z byznysu a najednou ejhle, 16-25 uživatelů za $100.
Bamboo to samé. Teď vám stačí 10 jobů za $10. Až budete potřebovat jednáctý, musíte vytáhnou těch $800 nebo začít dělat workaroundy (jako kolegové, kteří kvůli cenové politice GitHubu nasekali nesouvisející projekty do jednoho repozitáře) nebo řešit, kam migrovat jinam.
Odpověď na tvou otázku je právě ve slově důležitý. Není pro nás důležitá. Ale začala se používat pro pár lidí (asi 7) s argumentem, že kvůli $10 nebude ani koukat na jiná řešení. Teď jsou tam 2 nebo 3 stránky, které by se hodili i ostatním a pro 16 lidí je to najednou $100 (samozřejmě, že jsme to zvládli)
V mém příspěvku ale nešlo o konkrétní případ, ale spíš o upozornění, že produkty Atlassianu jsou pro malé týmy levné a pak se skokově zdraží. Každý si samozřejmě může rozhodnout, jestli za to dostává adekvátní hodnotu.
Nečetl jsem první díl, takže nevím zda to v něm nebylo, ale chybí mi uvedení hlavních problémů Jenkinse:
Docela bych rád viděl porovnání, jak si v těchto bodech vede Bamboo.
kdysi sme pouzivali gerrit https://gerrit-review.googlesource.com/Documentation/ a libil se mi. je to ale 5-6let zpatky
Sefove Atlassianu ti vojeli segru nebo co? Nahod nejaky konkretni cokoliv - project managment, time tracking, wiki, github-like rizeni kodu. Dej tip aspon na jeden jediny konkretni pouzitelny nastroj nebo jejich kombinaci ktery mi pokryje PROVAZANE to co mi dava jira - confluence - bitbucket - bamboo.
Já opravdu nevím, co konkrétně tobě dává Jira, to je tvůj problém. Jen ti můžu říct, že další rok práce s tím paskvilem s uživatelskou "přívětivostí" a "intuitivním" workflow ve stylu Lotus Notes a nekonečným množstvím ignorovaných bugů spolu s představou soudruhů z Atlassian, že rozdělením gigantického hovna na tři menší a implementací "moderního" flat designu vznikne z hovna voňavá růže, by mě spolehlivě přivedl do blázince.
Stale jsi neukazal rozumnou alternativu. Custom workflow, custom screeens, scrum, kanban. Tohle vsechno by asi dokazal jiny nastroj. Ale potrebuju to propojit s nejakym rozhranim pro git. Dale propojeni s dobrou wiki.
Ja kdyz poprve poznal Jiru na projektu pro kontraktora tak jsem taky myslel, ze si prostrelim obe kolena. Furt jen vypisy issues a mizerna pouzitelnost... Pak jsem to trochu zkoumal a nasadil si to pro sebe vcetne Agile a vlastniho workflow a screens. Najednou je to v podstate takove jednoduche ala Trello s vyrazne sirsima schopnnostma(kdyz jsou potreba) a integraci wiki a gitu.
Nadavas na Jira, ale podle me tva zloba patri integratorovi. Stejne jsem to zazil s Helios Orange. Prodali licence a spokojenost, na implementaci se v podstate vybodli a vsichni ve firme vcetne vedeni byli zrali na skok z okna. Ja to bral jinak, videl jsem ty uzasne moznosti(po prechodu z money S3). Po roce intenzivni prace na implementaci ciste s internimi silami z toho bylo neco perfektniho a lidi zacali duverovat, ze v tom nastroji najdou vzdy vse co potrebuji (vcetne jasnych dukazu kdyz nekdo neco posral). Stejne je na tom Drupal. Kdyz takovy SW nainstalujes neumi nic. Ale zaroven v sikovnych rukach dokaze cokoliv.
Nejsem expert na Jiru, ale vim, ze kdyz se tomu venuje patricna pece na zacatku (default filtry, boardy, workflow, screens, permissions atd) tak je z toho velmi dobry produkt se skvelou pouzitelnosti.
Redakce z toho neudělala seriál, ale něco první díl od stejného autora vyšlo před 2 týdny: https://www.root.cz/clanky/kontinualni-integrace-lek-na-lidske-chyby-v-deploymentu/
Každopádně pokud je to opravdu myšleno jako seriál, tak by mu pomohla trocha editorské práce.
Chtel bych ze septat jake problemy myslis?
* klikaci gui jde hodne obejit pomoci DSL a veci jako jenkisfile
* tohle muze byt neprijemne, ale nejak jsem to nikdy neresil, jednou za cas udelam update a malokdyneco resim
* tohle preci taky neni problem? proste si stahnu jen refspec ktery chci? Nebo jsem nepochopitl problem?
Zdravím, stejně jako Vás mě zaujalo porovnávání GUI. Nechápu, jak někdo může vůbec jen uvažovat o používání něčeho takového pro CI. Bamboo neznám, ale cca 2 roky se starám o takové lehké testování, takže základ byl:
1. nahodit Jenkins (pomohly konexe s QA, takže zneužívám jeden list z jejich produkčního Jenkinsu)
2. udělat konfiguraci pomocí souborů. Protože mám rád YAML, napsal jsem si tool v pythonu (jenkinsapi, python-jenkins) co z YAML souboru vytvoří několik View a joby pomocí templatů.
Po půl roce mi kolega řekl o Jenkins-job-builderu. Fakt jsem to hledal v komentářích, když už ne ve článku, protože co vím je to v podstatě standard pro definování jobů v jenkinsu. Neumí to vytvářet view, ale vzhledem k širokému použití jsem na něj migroval. Opět konfigurace přes YAML, ale má podporu pro spoustu pluginů a umožňuje pěkně definovat a hlavně udržovat v čase velké množství konfigurací. A jak jinak, než samozřejmě v gitu, takže člověk lehce zjistí, kdy co kde rozbil, může opravit a opět vylepšit.
Takže za mě rozhodně nedostatečná, protože si nedovedu představit, že by někdo i jen malý projekt udržoval pomocí GUI klikátka.