Continuous delivery v jPower8

Náš produkt nasazujeme produkci každé dva týdny. Máme tak nastavený sprint cyklus.

 Celý proces je (skoro) plně automatický.


Zdrojáky verzujeme v svn (migraci na git plánujeme).

Stabilitu buildu udržuje TeamCity, které

• provádí unit testy,
• spouští seleniové (integrační) testy,
• nasazuje na testovací prostředí a
• provádí statickou analýzu kódu.

Doba od commitu do nasazení na test je cca 15 minut.

Pro upečení stabilního verze používáme maven-release-plugin, který se postará o to, že zvedne verzi ve všech pomech, otaguje verzi v svn a uloží upečený build do artifactory. To vše se děje jedním stiskem tlačítka na TeamCity.

Posledním krokem je samotné nasazení waru na produkční prostředí. To dělám kvůli svému pocitu důležitosti ještě stále ručně (a protože nechci, aby TeamCity mělo na produkci přístup).

Samostatnou kapitolou je aplikace migračního databázového skriptu. Ještě donedávna jsme ji prováděli ručně, což sebou neslo riziko lidské chyby a hlavně velkého opruzu.

Pokud je například potřeba přejmenovat sloupec do tabulky, přidat index, změnit constraint, vývojář commitnul migrační sql sript do svn. Dále musel změnu aplikovat u sebe lokálně minimálně na dvou databázích - jedna pro unit testy a druhá pro lokální vývoj. Dále musel změnu provést na testovacím prostředí na dalších třech databázích. Ostatní vývojáři si také museli tuto změnu aplikovat u sebe lokálně. No prostě opruz až na půdu.

Tuto příjemnou činnost jsme hodili na framework flyway. Má přesně takovou složitost, jakou jsme byli ochotni akceptovat. Do databáze přidal jednu tabulku, ze které je naprosto zřejmé, které migrační skripty už v databázi jsou aplikované. Vše je plně automatické a v režii spring beany. Jednoduché jako facka.

A jak jste se zaváděním continuous delivery vy?

Zákaz tisku tlustých knih

Přes víkend jsem zhltnul první díl výborné Přemyslovské epopeje od Vladislava Vondrušky.

Další díl jsem si chtěl koupit v iBook storu, ale pešek! Je vydaná jen papírově! Není to žádná anorektická slečinka, ale pořádná 600ti stránková šťabajzna. Když se podívám na svůj noční stolek, jak se pod náporem jí podobných prohýbá, uvítal bych možnost koupě v elektronické podobě. Přece jen můj iPad má v tomto ohledu větší nosnost než sektorový nábytek.

Nakladatelé, přestaňte knížky tisknout a začněte je vydávat! 

Kradu jako umělec

Na iTunes jsem narazil na další pecku nakladatelství Melvil.

Jde o brutálně zjednodušenný výtah rad k odblokování tvůrčího ducha.

Jednu radu jsem hned aplikoval, vytáhl blok, pastelky a design rezervačního formuláře pro náš produkt jdemenato jsem vysmrkl ručně.

Vykradl (nechal se inspirovat) jsem kalendář Googlu, iCalu a Outlooku. Konkurenční systémy jsem ani vykrást nemohl, neb opakující se rezervace vůbec nepodporují.

Pastelky, ořezávátko a papíry jsou už nedílnou součástí mého analogového stolu.

A co vy? Pamatujete si ještě ze školky co jsou to pastelky?

Upgrade maven libraries

Na klasickém maven projektu používáme stabilní verze pluginů – hlavně kvůli stabilitě buildu. Kvůli drobné chybce v pluginu wsimport jsme používali workaround, který upravuje vygenerované zdrojáky. Projížděním konkurenčních blogů jsem zjistil, že tato chyba je od nějaké verze už opravená. To jak jsem to ale zjistil, není vůbec systémové. Jak tedy zjistit, jaké nové verze pluginů nebo knihoven jsou k dispozici, aniž bych musel trávit hodiny na internetu?

Jak už to tak na světě bývá, nejsem první, kdo něco podobného potřebuje. K tomuto účelu dobře poslouží versions plugin. Používal jsem ho dříve jen na zvedání verzí, dnes mi je zvedá teamcity spolu s release pluginem.

Versions plugin toho ale umí mnohem víc.

Např.
mvn versions:display-dependency-updates
vám řekne, jak jste na tom se závislostmi, jestli nevyšel nový spring, hibernate, joda-time apod.

mvn versions:display-plugin-updates
vám zase prozradí, jak jste na tom s aktuálností pluginů.

Pak už záleží jen na vás, jestli upgrade provedete nebo ne.

Upgradu zdar.

Method parameters validation in IntelliJ IDEA as live template

Validace vstupních parametrů metod.

Všechny vstupní parametry metod je vhodné validovat na jejich korektnost dříve než se s nimi začne pracovat.
V 90% případů mi stačí zkontrolovat, že vstupní parametr není null.
Joshua Bloch radí vyhodit NullPointerException, ale já, a troufám si tvrdit že i velká část java komunity, preferuje IllegalArgumentException.
Kód by mohl vypadat třeba takto

    public void foo(final String request) {
        if (request == null) {
            throw new IllegalArgumentException("Parameter 'request' can't be null.");
        }
    }

Protože nejsem na světě sám, co potřebuje validovat vstupní parametry, existuje spousta knihoven, které lze pro tyto účely využít (psát vlastní validační knihovnu považuji jen za zvyšování chaosu ve vesmíru).
První možností je třída org.apache.commons.lang.Validate z knihovny Apache Commons Lang.

    public void foo(final String request) {
        Validate.notNull(request, "Parameter 'request' can't be null.");     
    }

Místo původních třech řádků jen jeden. Na skoro všech projektech ale používám i Spring, tak proč nepoužít třídu org.springframework.util.Assert, která je hodně podobná org.apache.commons.lang.Validate?

    public void foo(final String request) {
        Assert.notNull(request, "Parameter 'request' can't be null.");
    }

Samotní autoři nedoporučují použít tuto třídu! Citace z javadocu:

Mainly for internal use within the framework; consider Jakarta's Commons Lang >= 2.0 for a more comprehensive suite of assertion utilities.

Další možnou variantou je knihovna Guava.

    public void foo(final String request) {
        Preconditions.checkNotNull(request, "Parameter 'request' can't be null.");
    }

Na té se mi ale nelíbí, že vyhazuje NullPointerException a varianta checkArgument, která vyhazuje IllegalArgumentException má vytaženou podmínku ven z metody, čímž se kontrola lehce komplikuje.

    public void foo(final String request) {
        Preconditions.checkArgument(request != null, "Parameter 'request' can't be null.");
    }

Já osobně zůstanu u třídy Validate. Jak validujete parametry metod vy?

YouTrack v jPower8

Při spouštění firmy jsme potřebovali vyřešit problém issue trackingu. Přestože je v open source komunitě spousta řešení, šáhli jsme nakonec po komerčním řešení.

Co nás přesvědčilo?

• Webové rozhraní - dostupnost i z domova i z práce.
  
• Extrémně jednoduché ovládání – ostatně jako u všech produktů jetbrains.
  
• Integrace na IntelliJ IDEA – umí dokonce i Jíru nebo PivotalTracker.
  
• Integrace do TeamCity – u každého issue vidíme, v jakých buildech se na úkolu pracovalo.
  
• Integrace na firemní LDAP.
  
• Neomezený počet projektů i uživatelů.
  
• Detailní možnosti nastavení přístupových práv.
  
• Restové rozhraní pro import i export dat.
  
• Přidávání custom políček a tagů.
  
• Rychlost vyhledávání.
  

Interně používáme youtrack na řízení všech úkolů, které ve firmě řešíme. Dokonce naši zákazníci zapisují své připomínky a návrhy také do youtracku, kde průběžně vidí, jak se na nich pracuje. Šetříme tak čas svůj i zákazníka – prostě win-win strategie.

Používáme youtrack i jako vykazovací systém, ale o tom až příště.