Přejít k navigační liště

Zdroják » Různé » Phabricator – geniální nástroj pro vývoj

Phabricator – geniální nástroj pro vývoj

Články Různé

Mnoha lidem může znít věta v názvu článku „geniální nástroj“ nadneseně, ale já jsem, po téměř roce a půl každodenního používání, z Phabricatoru pořád jako na větvi. Phabricator jsem si jednoduše zamiloval.

„Jak je možné, že je něco tak dobrého zadarmo?“ (konkrétně Apache licence) a hlavně „Proč jsem na něj nenarazil dřív?“ Tyto otázky mě napadají téměř denně.

Co je Phabricator zač?

Jedná se sadu nástrojů integrovaných do jedné aplikace s webovým rozhraním. Souhlasím, to nezní moc sexy. Všechny funkce, které Phabricator nabízí, nejspíš dokážete pokrýt instalací jiné svobodné aplikace, ale obrovské kouzlo Phabricatoru je ve vzájemné provázanosti aplikací a ucelenosti celého systému.

Za těch zhruba 20 let ve vývoji, jsem už používal mnoho nástrojů (Bugzilla, Redmine, Microsoft Team Foundation Server, Project, Atlassian Jira, Trello a další), ale Phabricator mě fakt dostal svou jednoduchostí, uživatelskou přívětivostí a neuvěřitelnou přizpůsobitelností.

Uvedu zde krátký výčet funkcí, abych vás taky nalákal a později se jim budu věnovat podrobněji. Jsou to například:

  • Správa zdrojových kódů – Git, SVN, Mercurial
  • Projektové řízení, správa a distribuce úkolů a bug tracking
  • Code review
  • Automatizace a audit
  • Wiki
  • Vychytané vyhledávání
  • Webové rozhraní a otevřené API (s Pythonem se dá bezva kouzlit)
  • A mnoho dalších – dnes se jedná o zhruba 50 aplikací

Snad jsem vás teď trochu navnadil a budete číst dále.

Historie a současnost

Phabricator vznikl ve společnosti Facebook. Následně byl uvolněn pod Apache licencí a o jeho další vývoj se stará samostatná společnost Phacility. Ta se na svém webu phacility.com příliš svou historií nechlubí, nicméně na webu i Wikipedii lze najít články, které původ Phabricatoru dokládají.

Hlavním vývojářem je Evan Priestley, který je dnes i v roli CTO. Evan je asi vtipálek. Aplikace je protkána slovními hříčkami a přesmyčkami. Mnoho aplikací je pojmenováno tak, aby se v názvu vyskytovalo písmeno F, které je psáno jako PH. Namátkou Phacility, Phabricator, Dipherential, Phriction a další. Taky čas od času narazíte na zábavné drobnůstky typu „Cat Facts“ a jiné hříčky. Při vývoji vám asi to nijak nepomůže, ale jak se říká „s úsměvem jde všechno líp“.

Vývoj Phabricatoru je, jak jinak, řízen pomocí Phabricatoru a je veřejně dostupný na adrese secure.phabricator.com.

O tom, jaké funkce Phabricator bude mít, rozhoduje společnost Phacility dle zájmu platících zákazníků.

Zdrojové kódy Phabricatoru a pomocných aplikací jsou zveřejněny na GitHubu https://github.com/phacility/phabricator a po naklonování repozitáře zjistíte, že první commit je z ledna roku 2011.

Vývoj je kontinuální, tým denně přidá několik změn a stable verze je uvolňována každý týden. O tom se můžete přesvědčit na interní wiki https://secure.phabricator.com/w/changelog/

K dispozici je komunitní uživatelské fórum na adrese https://discourse.phabricator-community.org/ kam aktivně přispívají sami autoři.

Phabricator používá mnoho známých společností. Já jsem narazil například na Wikimedia, která provozuje vlastní fork na https://phabricator.wikimedia.org/ a taky KDE https://phabricator.kde.org/.

Situace v Česku je trochu jiná. Zde Phabricator není příliš populární. Alespoň podle výsledků vyhledávání se tak jeví. Z vlastní zkušenosti ale mohu potvrdit, že jej používá několik společností ze skupiny Jablotron.

A jedna perlička na závěr tohoto exkursu. V historii vývoje Phabricatoru najdete i pražskou stopu Jakuba Vrány.

Instalace a provoz

Phabricator můžete provozovat na vlastním serveru. To bude asi případ většiny instalací. Společnost Phacility ale nabízí i hosting na komerční bázi. Dokonce si jej můžete zdarma, po omezenou dobu, vyzkoušet bez nutnosti instalace na adrese https://admin.phacility.com/

Stačí se pouze zaregistrovat a můžete si ve webovém rozhraní vytvořit vlastní instanci serveru.

Pro ty, kteří by se rozhodli provozovat vlastní instanci, pak jen doplním, že Phabricator je LAMP aplikace. Potřebujete tedy Linuxový server, na kterém poběží MySQL, Apache nebo ngix, PHP a GIT. Mimo Linuxu jsou podporovány i další příbuzné operační systémy, ale rozhodně nelze použít Windows OS.

K instalaci samotné toho moc nenapíšu. Je to zbytečné. Opakoval bych pouze to, co je velmi dobře popsáno v instalačním návodu na webu https://secure.phabricator.com/book/phabricator/article/installation_guide/

Krátká odbočka. Veškerá dokumentace Phabricatoru, včetně návodů a technické dokumentace, je vytvořena pomocí integrované aplikace Diviner.

Aplikace – Applications

Jak jsem psal výše, Phabricator se dnes skládá z přibližně 50 aplikací. Jejich seznam je uveden na adrese https://secure.phabricator.com/applications/

Aplikaci spustíte buď z odkazu v hlavním menu, nebo ze seznamu aplikací. Také můžete zadat jméno aplikace do adresního řádku webového prohlížeče, např. https://secure.phabricator.com/project/ pro přístup k aplikaci Project, nebo https://secure.phabricator.com/dashboard/  pro Dashboard atd.

Aplikace bych rozdělil do tří základních skupin.

  • Aplikace starající se o běh samotného Phabricatoru. Zde patří třeba Config, Auth apod.
  • Uživatelské aplikace, které slouží k vývoji. Tyto poskytují hlavní funkce Phabricatoru – Diffusion, Differential, Maniphest. Jsou aktivně používané a rozvíjené.
  • Prototype aplikace, které většinou nejsou moc použitelné, autoři je aktivně nevyvíjejí – například Phragment.

Úkoly – Maniphest

Aplikace Maniphest je základem Phabricatoru. Položky, o které se aplikace stará, se jmenují Task. Pojmenovat Maniphest česky „Úkoly“ může být dost zjednodušující.

On totiž Maniphest (asi opravdu raději zůstanu u originálního názvu) nabízí mnohem víc, než je seznam úkolů. V agilním světě by bylo nejtrefnějším pojmenováním prostě Backlog.

Nevím kolik úkolů Maniphest zvládne evidovat. Pravděpodobně hodně. Samotné Phacility dnes eviduje cca 13 500 úkolů v souvislosti s vývojem Phabricatoru. KDE je na nějakých 25 000. Wikimedia těžko uvěřitelných 238 000.

Maniphest je neuvěřitelně pružný. Můžete si jej snadno upravit k obrazu svému. K tomu se ale teprve dostaneme. Pojďme se podívat na samotný Task.

Task

Ve výchozí konfiguraci má Task následující atributy:

  • Type – typ úkolu. Základním typem je Task, můžete si ale vytvářet vlastní podtypy, třeba BUG.
  • Pořadové číslo s prefixem T (tedy např. T1234). Toto je jediný atribut, který nejde změnit.
  • Title – název úkolu.
  • Asigned To – přiřazený uživatel
  • Status – stav ve kterém se úkol nachází (Open, Closed atd.) Stavový diagram je plně konfigurovatelný.
  • Priority – priorita úkolu
  • Story points – příznivci Scrumu moc dobře vědí
  • Description – popis úkolu.
  • Visible To – oprávnění k prohlížení úkolu. Způsobů, jak určit kdo může daný úkol vidět je hodně. Budu se jim věnovat později.
  • Editable By – oprávnění k úpravám úkolu.
  • Tags – značky, ty jsou extra důležité. Jejich použití je na další samostatnou kapitolu, nebojte, dočkáte se
  • Subscribers – seznam uživatelů jenž obdrží emailem notifikace o jakékoliv změně úkolu
phab_task_new

Phabricator – nový úkol

Editor

Phabricator používá při editaci textu odlehčený značkovací jazyk Remarkup. Velkou výhodou je, že už při zápisu textu rovnou vidíte náhled toho, co píšete.

Na běžné úkony, jako tučné písmo či vložení odkazu, jsou zde k dispozici běžná tlačítka. Syntaxe je ale jednoduchá a brzy si na ni zvyknete a na tlačítka si ani nevzpomenete. Pokud si přece jen nebudete vědět rady, pak stačí kliknout na ikonku knihy v záhlaví editoru a otevře se vám stránka s nápovědou.

Formulář pro zadání lze snadno upravit. Můžete například některé pole skrýt (například Story points pokud nepoužíváte Scrum). Nebo můžete vybraným atributům předdefinovat výchozí hodnoty – typicky Tag.

Historie úkolu

Jakmile je úkol založen, začne Phabricator zaznamenávat veškerou aktivitu, která s úkolem souvisí, a zobrazuje ji ve formě logu v detailu úkolu.

Zaznamenává se úplně vše. Jakékoliv změny v názvu, popisu úkolu, prioritě, komentáře k úkolu ap.

Phabricator zaznamenává veškerou aktivita související s úkolem. Například pokud upravím zdrojový kód a do commit message uvedu číslo úkolu ve formátu T1234, pak je tento commit automaticky svázán s úkolem a zobrazí se v jeho detailu.

Další velmi oblíbenou funkcí je vzájemné odkazování mezi úkoly. Opět stačí kdekoliv v popisu úkolu či komentáři zmínit číslo úkolu ve formátu Txxxx a tento je automaticky provázán i s odkazem na referencovaný úkol. Referencované úkoly se pak přehledně zobrazí v detailu úkolu.

phab_task_base

Phabricator – úkol s komentářem a historií

Jak už jsem se zmínil zmínil Evan je vtipálek, a proto se tlačítko pro uložení nejmenuje prachobyčejně „Save“, ale „Set Sail for Adventure“

Stromová struktura úkolů

Úkoly lze řadit do stromové struktury. Způsobů, jak stromovou strukturu vytvořit, je několik.

Nejčastěji používaným způsobem je vytvoření pod-úkolu. Při tomto způsobu založení dojde u nově zakládaného úkolu k předvyplnění atributů rodičovského úkolu. Nemusíte tedy znovu definovat atributy jako Visible To, Editable By, Tags, Subcribers atd. Atributy lze dále libovolně měnit.

Vazbu mezi rodičovským úkolem a potomkem můžete kdykoliv přidat či odebrat. Úkol může mít nejen více potomků, ale i více rodičů. Můžete tak vytvářet složité stromové struktury, které vám pomohou se v úkolech orientovat. Na druhou stranu se dá ve stromech snadno ztratit. Osobně používám stromové struktury přibližně do třetí úrovně.

Co mi na stromové struktuře mi asi nejvíc vadí, je nemožnost ji sbalit a rozbalit, abych se v ní lépe vyznal. Hádám, že to souvisí s možností úkolu mít více rodičů. Dávám raději přednost filtrování a vyhledávání úkolů, hodně pak používám projektový workboard.

Graf stromové struktury je opět zobrazen v detailu úkolu.

phab_task_graph

Phabricator – stromová struktura v detailu úkolu

Vyhledávání a filtrování úkolů

Maniphest má v sobě zabudovanou funkci pro filtrování úkolů, kterou nazývá query. Já budu používat český výraz filtrování, který podle mě lépe vystihuje funkci.

K dispozici jsou předdefinované filtry jako „Open Tasks“, „Assigned“ nebo „Authored“

S tím si ale nevystačíte, a proto Phabricator nabízí možnost si vyrobit filtry vlastní pomocí „Advanced Search“. Filtrovat a vyhledávat můžete podle všech atributů úkolu.

Výsledky můžete dále seskupovat a řadit, nebo exportovat do souboru. Například do formátu CSV, JSON nebo TXT.

Poté, co si vlastní filtr vyladíte, jej můžete uložit pro budoucí použití. Zde pozor na jednu zvláštnost. Pokud chcete uložený filtr ještě upravit, doporučuji jej uložit pod novým názvem. Phabricator totiž umožňuje dát více filtrům tentýž název a brzy se v nich ztratíte.

Mojí velmi oblíbenou funkcí je hromadná editace vyfiltrovaných úkolů – Bulk Edit. Po sprint review tag == Sprint x vyfiltruji nedokončené Status == Open úkoly a hromadně je přesunutu do dalšího sprintu tag = Sprint y. A mám přípravu na sprint planning částečně hotovou.

Phabricator má také výborný full textový vyhledávač. Nejen pro prohledání úkolů (title, description i comment), ale i dalších aplikace jako wiki, ale i commit messages ap.

phab_task_query_result

Phabricator – výsledky filtrování

Projects

Aplikace Projects slouží k organizaci úkolů a je tak velmi úzce propojena s aplikací Maniphest.

Na rozdíl od většiny aplikací pro správu projektů a úkolů, je ve Phabricatoru vazba mezi projektem a úkolem velmi volná. Každý úkol může existovat bez jakékoliv vazby na projekt, nebo jich mít naopak několik. Na první pohled to může být matoucí, ale jakmile si na tento systém zvyknete, není cesty zpět.

Ono totiž je totiž Project ve Phabricatoru velmi flexibilním útvarem. Jedná se vlastně o skupinu objektů, které něco spojuje dohromady. Co konkrétně je těmto objektům společné, je už jen na vás a vašich potřebách a fantaziích.

Projekty mohou být použity klasicky pro sdružení úkolů souvisejících s vývojem nějakého produktu. Můžete založit projekt jako tag a použít jej pouze jako jednoduchou značku, kterou si budete úkoly značkovat pro lepší orientaci v nich, například pro rozdělení úkolů na frontend a backend. Nebo můžete založit projekt pro organizační složku a skupinu uživatelů.

Na projekt se dá v jakémkoliv textu snadno odkazovat hasthagem #NazevProjektu.

Subprojects a Milestones

Projekty lze dále členit na Subprojects a Milestones. Ty se od sebe liší důležitou vlastností. Ačkoliv úkol může být přiřazen k několika podprojektům zároveň, je možné jej přiřadit pouze k jednomu projektu typu Milestone, které jsou součástí hlavního projektu.

Zní to trochu komplikovaně, ale dává to logiku. Jednoduše mít úkol ve více Sprintech.

Nejlepší asi bude si vše ukázat na příkladu.

Založil jsem na ukázku projekt s názvem zdrojak.cz a tento jsem dále rozdělil na dva podprojekty (pro každý článek jeden) a dva milníky (zde například Sprint1 a 2).

phab_projects_milestones

Phabricator – projekty a milníky

Jakmile mám strukturu projektů vytvořenu, upravím jednotlivé úkoly a přiřadím je do projektů.

  • Úkol T576 – Založit účet na zdrojak.cz je označen tagem hlavního projektu „zdrojak.cz „
  • Úkoly, které se týkají psaní článku, jsou označeny tagem podprojektu „Článek Phabricator“.
  • A projekty typu Milestones, tedy Sprint 1 a Sprint 2, použiji pro časové plánování
phab_task_query_result_with_tags

Phabricator – úkoly s tagy

Workboards

Každý projekt má Workboard, což je další způsob, jakým je možné úkoly v projektu organizovat. Je to typická nástěnka s rozdělením úkolů do sloupců „ToDo“, „In Progress“, „Done“. Úkoly pak přesunujete jednoduše Drag and Drop.

Jak je ve Phabricatoru zvykem, můžete si sloupce libovolně pojmenovávat, přidávat a skrývat.  Můžete taky omezit počet maximální počet úkolů v daném sloupci.

Workboard ve výchozím nastavení zobrazí úkoly ve stavu úkolu „Open“. Můžete se ale jednoduše přepnout na zobrazení „All Tasks“, „Assigned To Me“ případně si vytvořit vlastní filtr a uložit jej jako výchozí.

Skvělou funkcí je možnost pro každý sloupec nadefinovat vlastní trigger, který spustí vybranou akci při přesunutí úkolu do sloupce. Například změnit stav nebo prioritu, přiřadit někomu úkol, přidat či odebrat Tag, nebo zahrát zvuk fanfáry. Každý trigger může spustit více než jen jednu akci.

Na obrázku můžete vidět Workboard projektu typu Milestone „Sprint 1“ upravený pro psaní článků.

phab_project_workboard

Phabricator – Workboard

Předpokládám, že teď už si snadno dokážete představit, jak si workboard přizpůsobit pro vlastní způsob organizace práce. Ať už použijete Scrum, nebo Kanban, nebo cokoliv jiného – Workboard vás v tom podpoří.

S Phabricatorem si za pár minut vytvoříte workboard pro jakoukoliv činnost.

Velkou výhodou je, že každý úkol může mít přiřazeno více projektů a vyskytuje se tedy na více workboardech. Tímto způsobem můžete nadefinovat několik, na sobě nezávislých, životních cyklů úkolu.

Uvedu příklad. Tým uživatelské podpory obdrží dotaz od zákazníka. Založí pro ni task s tagem „Podpora“ a ve svém vlastním workboardu se mu věnuje. V určitém okamžiku řešení zákaznického problému zjistí, že se jedná o chybu, a proto přiřadí tasku tag „Bug“. Ten se tedy okamžitě objeví ve workboardu vývojového týmu, který jej řeší nezávislým workflow. Po vydání opravy je Bug v rámci vývoje dokončen, ale na workboardu týmu podpory task pokračuje v životním cyklu dál. Například informací zákazníkovi o vydané opravě.

Co Projects neumí

Abych byl alespoň trochu objektivní, nezbývá mi než se zmínit i o jistých omezeních.

Co aplikace Projects neumí, je podpora plánování práce v čase. Milestones se k tomuto účelu dají použít velmi omezeně.

Pokud používáte Microsoft Project, který je založený na práci s časovou osou, pak budete hledat podobné funkce marně. Na Ganttovo zobrazení můžete taky klidně zapomenout.

Ony totiž úkoly v Maniphestu nemají atributy, které by to umožnily. Pravděpodobně by se dalo toto omezení částečně obejít definicí vlastních atributů Start Date, End Date, Depends On ap. Pak by bylo možné se na Phabricator připojit přes API a zobrazit si úkoly v Ganttově diagramu jiným nástrojem, který jej podporuje.

Takto jsem ale Phabricator nikdy nepoužil. Většinou si vystačím s exportem vyfiltrovaných úkolů do prostého CSV.  Nebo si v Pythonu napíšu skript, kterým si vyfiltrované úkoly dále zpracuji podle potřeby.

Na druhou stranu asi všichni z vás, kteří v Microsoft Project někdy plánovali a neustále aktualizovali trochu větší projekt vědí, jak časově náročný úkol to je. Já jsem rád, že mám Phabricator a nehodlám to v dohledné době měnit.

Repozitář zdrojových kódů – Diffusion

Dostáváme se k naprosto nezbytné aplikaci a tou je Diffusion, která se stará o integraci repozitářů zdrojových kódů.

Phabricator podporuje Git, Mercurial a Subversion. My používáme pro veškerou vývojovou dokumentaci pouze Git, takže následující informace se budou týkat primárně jej. Nemohu zaručit, že se stejně chová Mercurial a Subversion.

Konfigurace repozitáře

Založení nového Git repozitáře v Diffusion je otázkou minutky. Zadáte název repozitáře a aktivujete je. Každý repozitář má přiděleno pořadové číslo. Na repozitáře je možné se odkazovat pomocí prefixu R – stačí zapsat do jakéhokoliv textu Rxxx. Stejně snadno můžete odkazovat na konkrétní commit, stačí v textu zapsat jeho hash.

SSH Public Key

Posledním krokem je přidání vašeho veřejného SSH klíče, a můžete repozitář používat. K tomu použijte aplikace Settings/ Personal Account Settings a v menu zvolte SSH Public Key. Můžete nahrát existující klíč, nebo si nechat automaticky vygenerovat soukromý a veřejný klíč. Veřejný klíč je možné revokovat.

Já většinou používám Atlassian Sourcetree. Volba klienta je samozřejmě pouze na vás.

Webové rozhraní

Aplikace Diffusion nabízí i webové rozhraní pro prohlížení repozitáře.

Kromě snadného přístupu k zdrojovým kódům či jejich historii (pokud nemáte daný repozitář naklonovaný) je webové rozhraní dostupné i uživatelům – nevývojářům.  Můžete jim tak snadno poslat odkaz na požadovaný soubor (dokumentaci, release notes ap.), aniž byste je trápili s klonováním repozitáře. U manažerů a lidí z marketingu k nezaplacení.

phab_git_repo

Phabricator – webové rozhraní Git repozitáře

Integrace

Na úplném začátku článku jsem zmiňoval provázanost aplikací jako obrovskou přednost Phabricatoru.

Zde se to krásně ukáže. Stačí do commit message uvést číslo úkolu Txxx a jakmile úkol pushnete, Phabricator si jej automaticky prováže s daným úkolem. Zvláště ze začátku se vám bude stávat, že na číslo úkolu zapomenete. nevadí, zde je pomoc snadná. Stačí si najít daný úkol a v nabídce akcí zvolit „Edit Related Object/Edit Commit“. Nebo na to můžete jít obráceně přes commit a vybrat akci „Edit Related Object/Edit Task“

Phabricator jde ale ještě dále. Úkoly lze pomocí uvedení klíčových slov v commit message přímo uzavírat, respektive měnit jejich status. Klíčová slova jsou například „as fixed“, „fix“, „fixes“, „as duplicate“ atd.

Stavy úkolů a klíčová slova jsou v uvedena konfiguračním parametru maniphest.statuses

Taková integrace má mnoho výhod. Nejen, že zvyšuje informovanost a transparentnost, ale také otevírá nové možnosti. Jako pěkný příklad bych zde uvedl automatické generování release notes.

Phabricator nabízí API, takže můžete podle tagu v gitu vyhledat provedené změny, podle nich související úkoly a z jejich popisu vygenerovat release notes. My jsme k tomu ještě přidali automatickou úpravu wiki stránek v aplikaci Phriction a máme pro každý release perfektně zpracované release notes i s odkazy na řešené úkoly.

Observe a Mirror

Git repozitáře ve Phabricatoru mohou mít mimo běžné funkce „remote“ ještě funkci „observe“ či „mirror“.

Tyto využíváme pro automatické sdílení zdrojových kódů mezi více systémy – například Phabricator x GitLab, Phabricatot x Phabricator a podobně.

Představte si situaci, kdy máte externího vývojáře bez přístupu do interního systému, a tedy ani Phabricatoru. Pak nejspíš založíte repozitář na Githubu. Tím ale přijdete o integraci s úkoly a dalšími systémy. A to nechcete. Řešením je založení repozitáře ve Phabricatoru a jeho nakonfigurování tak, aby sledoval Github a všechny změny si automaticky pulloval. Případně můžete využít obrácený postup a zrcadlit na Github interní repozitář.

Soubory – Files

Aplikace Files se stará o všechny soubory, které do Phabricatoru nahrajete.

Pokud editujete popis nějakého úkolu a do popisu vložíte pomocí copy-paste nějaký soubor, v mém případě třeba fotku nebo prinstcreen, Phabricator jej automaticky uloží pod pořadovým číslem a vytvoří na něj odkaz na objekt s prefixem F.

Je to velmi pohodlné a user friendly. Jak vidíte na následujícím obrázku, v textu úkolu je pouze odkaz na soubor F749 a v náhledu pod editorem je již vidět vložený obrázek. Editor Phabricatoru rozlišuje, zda je odkaz na soubor, jiný úkol či projekt zapsán jako text, nebo je vložen do složených závorek. V mém případě jsem se odkázal na úkol T579 bez závorek a vytvořený odkaz je pouze zvýrazněn, ale u souboru F749 jsem složené závorky použil, a proto je obrázek rovnou zobrazen jako náhled.

phab_task_files

Phabricator – úkol s vloženým souborem. Samotná aplikace Files nenabízí adresářovou strukturu, takže není úplně vhodná k použití jako správce souborů.

Code Review – Differential

Jedním z nezbytných úkonů vývojáře je code review a k tomuto účelu slouží Differential.

Zde se dostane ke slovu příkazový řádek a aplikace Arcanist. Návod na zprovoznění této command-line utility je na webu https://secure.phabricator.com/book/phabricator/article/arcanist/. Zvládl jsem to já, takže to zvládnete i vy.

Postup code review je pak následující:

  1. Udělejte běžný git commit vašich změn
  2. Poté pomocí příkazu arc diff založte revizi a přidejte informace o tom kdo má review provést, testovací plán a nejlépe přidejte i komentář. Differential založí objekt s prefixem D a odešle email s požadavkem na review.
  3. Phabricator pomocí aplikace Harbormaster založí objekt typu Build (prefix B) a provede build změn
  4. Určený kolega ve webovém rozhraní Differential změnu buď akceptuje, nebo ji vrátí k přepracování a případně může požádat někoho jiného o review.
  5. Dále už záleží na nastavení vašeho workflow, zda následný git push provedete ručně, nebo to za vás udělá Differential automaticky.

Uživatelské rozhraní, které Differential vývojářům poskytuje, je dobře vidět na webu https://secure.phabricator.com/D20675 .

phab_differential

Phabricator – Code Review

Harbormaster

V předchozí kapitole jsem zmínil aplikaci Harbomaster, která se stará o Continuous Integration.

Ten my bohužel nepoužíváme, takže k němu nemám moc co napsat. Spíše jsem kapitolu zařadil, abyste si udělali představu o schopnostech a šíři záběru Phabricatoru.

Důvodem, proč jsme si nechali Jenkins, bylo množství dostupných doplňků a také to, že jsme s ním měli nejvíc zkušeností.

Wiki – Phriction

Nedílnou a velmi oblíbenou součástí Phabricatoru je aplikace Phriction pro wiki.

Aplikaci samotnou asi není třeba zdlouhavě představovat. Co je ovšem specifické, je provázanost s dalšími aplikacemi a možnost snadno se odkazovat na jiné objekty. Můžete použít již jednou použité obrázky či jiné soubory, odkázat se na provedený commit přes jeho hash, atd.

Prostory – Spaces

Aplikace Spaces umožňuje nastavit přístupová práva k jednotlivým objektům.

Obvykle se jednotlivé prostory nastavují podle organizační struktury – například All users, Marketing, Development a podobně.

Ale fantazii se meze nekladou. Založte si vlastní vesmír, kam nikoho nepustíte a ukryjte vše, co je určeno jen vašim očím.

Správce hesel – Passphrase

Aplikace Passphrase nabízí správu přístupových údajů.

Známe to asi všichni. Hesla jsou mor, ale bez nich to nejde. Takže se hodí správce hesel. Ten umožňuje definovat přístupová oprávnění k heslu samotnému. Přiznám se, že nevím, jakým způsobem si Phabricator hesla ukládá. Dokumentaci jsem nestudoval, takže tak nějak tiše doufám, že to Evan udělal dobře.

Výhody použití Passphrase jsou následující.

  • Relativně snadno můžete funkci nabídnout méně technicky vybaveným kolegům a kolegyním u kterých s Keepasem neuspějete. Webovka je prostě webovka.
  • V určitých situacích potřebuje Phabricator použít privátní klíč (třeba při zrcadlení repozitáře) a zde jej má k dispozici.
  • Pokud potřebujete pro vyřešení nějakého úkolu předat vývojářům přístupové kódy k nějakému systému, stačí je uložit zde a odkázat se na ně pomocí zápisu Kxxx
phab_credentials

Phabricator – Passphrace

Konfigurace – Config

Konfiguraci Phabricatoru zajišťuje aplikace Config. Ta nabízí přístup k většině parametrů pomocí webového rozhraní.

Konfigurační parametry lze editovat buď pomocí jednoduchého dialogu, nebo přímo v JSON formátu. Parametry jsou vždy vysvětleny a někdy je uveden i příklad alternativní konfigurace.

Zamčené a skryté parametry

Ne všechny parametry lze ve webovém rozhraní editovat a jsou pouze ke čtení. Také existují parametry, které nejsou z webového rozhraní dostupné ani pro čtení.

Takové parametry je možné číst a zapisovat pomocí CLI bin/config.

Na většinu běžných úprav si ale vystačíte s webovým rozhraním.

Autentizace – Auth

O konfiguraci autentizace se stará aplikace Auth. Ta nabízí velké množství poskytovatelů pro autentizaci uživatelů.

Osobně používám dva poskytovatele „Username/Password“ a „LDAP“.

Pokud potřebuji povolit přístup internímu uživateli, který má účet na Active Directory, pak jej připojím přes LDAP. Pokud se ale jedná o dočasného uživatele, například při školení, pak zvolím jednoduché Username/Password.

Konfigurace poskytovatelů je velmi dobře popsána přímo v konfigurační stránce. Možnosti konfigurace se samozřejmě liší dle vybrané varianty. Například pro Username/Password jsou k dispozici parametry, které povolují možnost registrace nových uživatelů, minimální délku hesla apod. Pro LDAP pak přibude konfigurace LDAP Host, Port, atd. Nic, s čím by si administrátor neporadil.

Pro firemní účely bude asi typické použití vlastního LDAP serveru. Zde bych upozornil na určitou zvláštnost implementace tohoto poskytovatele, která se ve Phabricatoru objevila až letos. Kdokoliv, kdo má LDAP účet a má přístup k přihlašovací stránce se může přihlásit svým LDAP účtem a automaticky se tím založí účet ve Phabricatoru.  Zde je silně doporučováno povolit v konfiguraci volbu auth.require-approval. V takovém případě je uživatelský účet zařazen na čekací listinu a administrátor musí nově vytvořený účet schválit.

Další OAuth poskytovatelé, které je možné ve Phabricatoru použít, jsou všichni velcí hráči (v abecedním pořadí): Amazon, Asana, Bitbucket, Disqus, Facebook, GitHub, Google, JIRA, Phabricator, Slack, Twitch, Twitter a WorldPress.

Z tohoto seznamu si nejspíš vybere úplně každý.

Závěrem

Popisem možností konfigurace jsem se vyčerpal. Doufám, že jsem vám trochu přiblížil svůj oblíbený Phabricator. Moc rád si přečtu vaše komentáře. Nejen od vás, pro které je Phabricator denním chlebem, ale taky od těch, kteří se nechali zlákal a Phabricator vyzkoušeli. Užijte si jej a dobrou chuť.

Komentáře

Subscribe
Upozornit na
guest
11 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
pschiffe

phabricator som davnejsie skusal pouzivat (2-3 roky dozadu), ale v tej dobe mi nejak nevyhovoval. mal som pocit ze toho vie velmi vela, ale nic poriadne. potom som presiel na gitlab a zostal u neho.

Petr B.

Phabricator používáme ve firmě cca 5let a jsme s ním spokojení, je to skvělý nástroj. Hodně věcí se za tu dobu změnilo, ale troufám si tvrdit že vždy k lepšímu.
Díky „space“ můžeme do něj pustit i externí lidi, pouze oddělíme co lze a nelze vidět, nastavíme komunikaci přes interní chat „conpherence“ a parádní..

Rád bych se zeptal autora, koho všeho do phabricatoru pouštíte (interní oddělení)? U nás to jsou zatím vždy vyvojáři/koděři. Předpokládám že to mohou být grafici, i někdo z marketingu, jak pak probíhá komunikace?

Díky za článek !

lenoch

Pěkný článek. U nás máme kombinaci gitlab / jira, která myslím většinu zmiňovaných věcí taky umí (ve skutečnosti ani naplno všechny možnosti nevyužijeme).
Ale phabricator rozhodně působí také jako pokročilá aplikace.

Radouch

Zajímalo by mne srovnání Phabricatoru s Redminem https://www.redmine.org/, případně s GitLabem (ale s tím určité zkušenosti mám). Omezení, výhody, nevýhody. Máte s tím někdo zkušenosti?

brablc

Aplikace Herald umí automatizovat některé atributy tásků při jeho změnách. Ale neumí je přesouvat mezi sloupci. To je hodně limitující.

Vaclav ze z plzne

:) je to skvělé, škoda že to nepoužíváme v té naší partě všichni

Josef Marianek

Dobre vedet ze to existuje, ale popravde ja uz jsem zajetej v jinych alternativach ktere to nahradi. Neni to sice vse v jednom, ale nevadi mne pouzivat zvlast vyvojove prostredi, zvlast ticketovaci nastroj, zvlast dokumentaci atd. Mozna kdyz je to zvlast muzou ty nastroje byt naopak vyspelejsi, i kdyz je potreba se pak prepinat do ruznych nastroju…

Karel

Zajímavé, nikdy jsem o tom neslysel. Právě integrace se mi líbí. mě by zajímalo srovnání s gitlabem(kam se migruju z atlssian + Jenkins právě jako all in one na vlastní server a open source) – co používám a/nebo chci/potrebuju v gitlabu – CI pipelines, docker registry, graf výsledků xml reportu z testu, git squash pro pull requesty, potřebný počet approvals na pull requestu.
Třeba Registry se dá řešit jinak, ale právě integrace s CI je skvělá .

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.