Using Spring Cloud Config Server

Problem definition

I have already described why do we need external configuration management.

In short, let's say we have several environments (production, simulation, test). As the development goes we run different versions of our application on these environments. Part of the configuration of the application is specific to an environment and may change out of sync with our releases. So it is bound to the application version and the environment but should not be stored in the same repository as the code.

We used to have a tool to handle such external configuration management but since it was in-house developed and I moved away from that company I would have to write it from the scratch. We also made some design mistakes (detailed in the aforementioned blog post). So I looked around and found Spring Cloud Config server which can be backed with Git repository to store configuration. The beauty of having Git repository for configuration is that every configuration change is tracked and hence audited. Also tools to edit the configuration are already out there - file managers, IDEs, text editors. Moreover it should be easy to set up since it is just a Spring Boot application.

Spring Cloud Config

I gave it a try. I created a project which has only the dependency to Spring Cloud Config. I set the URL to the Git repository with configuration, deployed it and was ready to go.

pom.xml

    4.0.0

    com.company
    config-server
    1.0-SNAPSHOT

    
        
            org.springframework.cloud
            spring-cloud-config-server
            1.1.2.RELEASE
        

        
            org.springframework
            spring-core
            4.2.6.RELEASE
        
    

    
        config-server
        
            
                org.springframework.boot
                spring-boot-maven-plugin
                1.4.0.RELEASE
                
                    true
                
                
                    
                        
                            repackage
                        
                    
                
            
        
    

application.properties

server.port: 8888
spring.cloud.config.server.git.uri: ssh://git@hostname:1111/our-app-config.git

The server supports API calls like

• /{application}/{profile}[/{label}]
• /{application}-{profile}.yml
• /{label}/{application}-{profile}.yml
• /{application}-{profile}.properties
• /{label}/{application}-{profile}.properties

One can also provide an Accept header to get for instance binary file:

-H "Accept: application/octet-stream"

.

Versioning

Since we strive to get continuous delivery working the version is assigned with every commit. Consequently, any commit can be deployed up to production. This version is derived from the last annotated tag (e.g. 1.0), number of commits since then, and the commit SHA. It may look like: 1.0.42-gda31562.

We have four environments:

• Test - for our testing
• Acceptance - for customer testing
• Simulation - production hotfixes
• Production

And two external configuration files:

env.properties - environment specific properties
logback.xml - Logback configuration

We use Ansible for automating the deployment. It places these two files to the lib folder of Tomcat.

The configuration Git repository that is used by Spring Cloud Config contains these files in the root folder:

env.properties - with defaults
app-acc-env.properties
app-simu-env.properties
app-prod-env.properties
app-logback.xml
app-prod-logback.xml

Ansible makes API calls like: http hostname:8888/app/acc/master/app-env.properties to retrieve app-acc-env.properties from master branch. So far so good.

Branching

Ansible can either ask for master branch and get the latest configuration (we use that to deploy local builds to 'test') or it can use the 'label' to get configuration for specific version (hence we use version as a 'label'). That forces us to create an annotated tag everytime we release to the Artifactory - so everytime we release to acceptance or higher.

If ever we need to change the configuration for a version we convert the tag for that version to a branch and make changes on the branch.

Changing Configuration

We expect there will be two scenarios:

• One needs to add/modify a property because of a new feature, new code. Then we can commit the changed configuration to master branch in the configuration repository. When the next version with the change is released the property is there. That is also one of the main benefits of having the external configuration management.
• One needs to change a property for running version on one or more of the systems. Then it gets a bit tricky. Let's say we have tags: 1.0.0, 1.0.10, 1.0.25, and 1.0.40 I have 1.0.10 running in production and want to set say new email server URL. Then I need to convert tags 1.0.10, 1.0.25 and 1.0.40 to branches and make my change in all the three branches. That may get rather annoying eventually especially if we do not release to prod often and there are many tags.

Problems

The main problems I see with this approach are:

• The need to tag every release.
• The need to change potentially many of these tags - convert them to branches and perform the same modification.

Our versioning scheme produces monotonously increasing versions (with slight caveat for branches but we deploy to customer facing environments only from dev branch which mitigates this issue). Hence in our case these problems can be solved with the notion of version ranges. If I have versions 1.0.0, 1.0.10, 1.0.25, and 1.0.40 and there was no configuration change since 1.0.0 I will have just the one configuration for version 1.0.0 and it will be used for all the versions. If I introduce configuration change in 1.0.42 I create next version of configuration but everything in between will still get the configuration for 1.0.0. When I need to modify some property from version 1.0.25 I can create branch from the version bellow - 1.0.0 - and change it there. Then even 1.0.40 would get this change. Out of luck for 1.0.42 but at least I would not need to change the setting in too many places.

I'm new to Spring Cloud Config so maybe I missed something obvious. Let me know your thoughts.

Benefits

• Configuration can be altered outside of the release cycle of the code.
• Configuration changes are audited and documented (with commit messages).
• It is possible to look up what the configuration was at the point of the deployment - the deployment script logs time of deployment and version so one can look up corresponding configuration.
• We don't need to think about all the configuration changes necessary for given release since they are performed in advance and then updated as the changes occur and not at the point of the release.

SonarQube Integration Test Coverage with Cargo plugin

I already described how to get integration test coverage into your Sonar when your application runs on Tomcat here. I came to a project that uses Cargo Maven plugin to deploy the app on a Tomcat for integration tests. I wanted to see how much these tests actually cover. The answer to that turned out to be 'not that much really' but I'd like to share with you how to adjust configuration of the Cargo Maven plugin to make it work with Sonar.

Let's go.

Sonar properties

So in our case we have a multimodule Maven project. In order to collect usage over the project just set following sonar properties:

The default configuration puts jacoco.exec in the target of a module. We want to collect code coverage over several modules (including cases when code from one module calls code from another module) so we have to put Jacoco output files up the folder hierarchy and configure Jacoco plugin to append to these files.

In order to collect integration test coverage from deployed app we configure the Jacoco offline instrumentation to get a WAR file with instrumented classes. Jacoco agent deployed along with the war can then collect coverage data to specified file.

Jacoco Offline Instrumentation

The Sonar profile which configures offline instrumentation in the main pom looks pretty much the same as in the previous blog post:

Cargo plugin

Cargo plugin needs to deploy jacoco agent jar along with the application WAR. It also needs to set system property for jacoco-agent.destfile so that the agent can write collected coverage data to it.

Then just run:

Enjoy!

Why do we need a configuration management tool?

I spent some years developing web applications in Java for the corporate world. The apps always used some webcontainer or application server and we used different staging environments to show our work to testers, managers and customers before we went to production. Unfortunately, there are always some differences between these environments, be it a feature turned off or a database password or a mail server URL. So one needs to provide, ideally external, configuration file for every environment.

The usual way to do that few years ago was to define whatever configuration necessary, place it on the server and be done with that. In our case we put a logback.xml and an app-env.properties to the lib folder of Tomcat. Whenever a property is introduced or needs a change one asks a fellow ops guy and he performs this change on the day of the deployment. It worked most of the time but there are couple obvious issues with this approach:

• Error-prone – typos, missed changes, missing properties.
• Unknown configuration – in corporate world it is the ops who have access to production so there is no way to know the actual content of a configuration file for a poor prod-issue-solving developer.
• Impossible full deployment automation – since a manual step is needed from time to time.

We lived with these downsides for a while, suffered some break downs of the app, or the RabbiMQ broker (our OPS never really embraced the 'infrastructure as a code' principle), or a broken database. Ultimately, the change came along and we started the internal DevOps pilot. One goal was to do automated deployments. Now you can write a script that stops a Tomcat, copies over the war and starts it, you can use Flyway or other database migration tool and run a command to do the database migration for you, but what about the external per environment configuration?

Surprisingly, lot of people I talked to thought that configuration is easy. You just check in the version control system the configuration changes along with the feature. I believe they miss couple interesting corner cases. Let's use an introduction of a mail server as an example. A developer implements first feature which sends emails. He tries it out locally with a postfix server and adds mailServer.url property and wants to check it in but:

• The value is not known for all environments as ops may be able to provide you the right mail server URL weeks (and I saw months:)) after you've finished the ticket.
• The value may change in the future.
• Additionally, the value should be there only since the very first version which includes the commit.

If you want to get close to continuous delivery you may want to maintain that any commit that builds successfully can be delivered up to production. But then again, where and how should you store the configuration?

Given the example above we concluded that the configuration files have different lifecycle from the code. They are changed at different times. Moreover, they are shared between dev and ops teams since they both maintain certain parts of the configuration.

We decided we needed a configuration management tool with following properties:

• The deployment tool can get from it a zip file via an HTTP GET call. The tool provides project name, environment name and version.
• The zip contains all files in the correct structure that can be extracted to a designated folder.
  • e.g. /lib/certificates/server.jks
    /lib/logback.xml
    /lib/application-env.properties
    /conf/server.xml
• Only authenticated users can change files.
• Every action is audited – no more shrugging and not knowing who changed a value and when. No more what version of configuration was there when an issue happened a week ago.
• (Optional) Support for 'secrets' – e.g. production database password visible only for certain group of users (ops).

At the point of the decision there were no obvious solutions out there so we developed in-house a simple web application. Obviously it was a web app since when one has a hammer everything looks like a nail:). The app had a UI for listing files per project and environment. It had some neat syntax highlighting, it allowed you to add, copy, diff, edit, delete files, etc. It stored files in the database. The UI part needed a lot of maintenance and feature work yet it was clumsy to work with. It offered HTTP API to get the zip with configuration. It solved most of our problems. Since its roll-out we could finally see how are the customer facing environments configured. When a new property was introduced we could make the change, commit, take the version of that commit and create respective versions of the property files in all environments leaving TODOs where we did not know the right value. No more documentation about what all needs to be changed with the next deployment. No more figuring out what kind of configuration do I need locally to be able to run certain version of application.

I will elaborate a bit on how the versioning of files work by providing following example. Let's say the app is released in version 1.0. There are two files for each environment 'logback.xml' and 'app-env.properties'. We decide we want to change logging a bit in version 1.0.10 so we add updated logback.xml for version 1.0.10 and higher. Then a mail server needs to be added. The feature is implemented in version 1.0.42 so we add updated app-env.properties for version 1.0.42 and higher. So far our configuration management contains four files for each environment:

• app-env.properties/1.0.0
• logback.xml/1.0.0
• logback.xml/1.0.10
• app-env.properties/1.0.42

If one needs app configuration for given environment for version say 1.0.5 he will get the initial two. If one needs app configuration for 1.0.32 he will get app-env.properties/1.0.0 and logback/1.0/10. For version 2.0 he will get app-env.properties/1.0.42 and logback/1.0.10. So there is a requirement that versions can be lexically ordered.

The above described approach worked fairly well and we were autodeploying for more than a year with great success. Downtime of 40 seconds and the peace of mind were totally worth it. But on the hindsight, we spent one hell of a time developing features of the configuration management tool which could be covered by choosing another approach which came to our minds. Let me present it to you. Most of the work on the configuration management tool was spent on the UI and all the file management, syntax highlighting, and diffing. Despite all that work it is still not great! Yet there are so many tools around that can do parts of that work much better, namely our beloved IDEs. There are also good file storing solutions out there with auditing and we happen to call them version control systems:) So why not to pick Git with vim or Idea, create a predefined folder structure and let some daemon loose on top of it to serve the configuration zip file?

Our plan is to try just that at techdev, try it on shypp.it first and then open source it. We will keep you posted.

Also if you know about such a tool please let us know! We don't want to reinvent the wheel all that much.

Těžkosti a nesmyslnosti kolem rodičovského příspěvku

Zevrubně sepíši, co všechno bylo třeba udělat, aby manželka dostala rodičovský příspěvek.

Výchozí situace:

• já, zaměstnaný jako Java programátor, příjem vyšší než strop vyměřovacího základu pro mateřskou, půjdu na mateřskou od ukončení 6. týdne dítěte do ukončení 16tého týdne dítěte
• manželka, samostatná advokátka (www.dobra-advokatka.cz), neplatí si nemocenskou, nemá nárok na mateřskou
• předpokládané narození potomka koncem dubna 2015
• bydlíme a pracujeme v Praze, trvalé bydliště máme v Bruntále.

Prosinec 2014

Vědomi si trochu neobvyklé situace, kdy jdu na mateřskou já a manželka nemá nárok na mateřskou (peněžitá pomoc v mateřství, dále PPM), jsme se vydali na správu sociálního zabezpečení zjistit, jaké máme možnosti a co všechno musíme dodat. První překvapení, paní na sociálce nás poslala na pracovní úřad, neb ten má na starosti rodičovský příspěvek. Na pracovním úřadě nám paní dala stoh dokumentů pro manželku a podivila se, jak to máme složité. Konkrétních informací jako šafránu. Úředníci v podstatě nevěděli, co s námi.

Únor 2015

Pracovní úřad trvá na tom, že musí mít rozhodnutí od sociálky, že manželka nemá nárok na mateřskou. To lze získat jen tak, že se o mateřskou oficiálně zažádá. Takže manželce dali na sociálce formulář pro gynekologa, následně jí jej na gynekologii pan doktor podepsal, aby s ním mohla jít zažádat na sociálce o mateřskou, aby dostala rozhodnutí, že na ni nemá nárok (velké překvapení, když si neplatí nemocenskou, což paní na úřadě ví). Takže máme přílohu k žádosti, aby mohl pracák vyplácet rodičovský příspěvek ode dne narození dítěte. Do dubna vyřízeno.

21. duben 2015

Narodil se nám v Neratovicích syn Jáchym :) Po porodu jsme byli čtyři dny v nemocnici, pak ještě několik dní doma.

Květen 2015

Řešil jsem v práci na personálním, co všechno bude třeba vyplnit kvůli mé mateřské, holky mi daly několik formulářů, ty jsem vyplnil. K tomu jsme s manželkou museli podepsat dohodu o svěření dítěte do péče po dobu mé mateřské. Bohužel mužům se v našem státě nevěří, neb na tuto dohodu bylo třeba připojit manželky úředně ověřený podpis – tedy výlet na poštu v šestinedělí. Jinak to bylo od holek na personálním vše. Za mě vyřízeno.

A teď k rodičovskému příspěvku. Vyplnil jsem na internetu na stránkách MPSV pro manželku formulář s žádostí. Práce se šablonou dobrá. Super, že to jde vyplnit na internetu. Nicméně s některými položkami jsem si nevěděl rady (výše příspěvku, přílohy), nápověda nebyla moc nápomocná.

První trochu teorie. Rodičovský příspěvek má maximální celkovou výši 220.000,- Kč. Lze jej pobírat libovolnou dobu mezi druhým a čtvrtým rokem dítěte. Nelze jej pobírat po dobu mateřské, lze jej pobírat nejdříve ode dne narození dítěte. Míra volnosti volby výše příspěvku závisí na výši odvodů. V případě, že člověk nesplní ani stanovenou minimální míru odvodů na nemocenskou, nemůže si vybírat vůbec a musí “volit” čtyřletou variantu, kdy se vyplácí cca 3.500,- měsíčně. Ovšem v případě partnera (nevím, zda musí být nutně manžel), který odvody má, si lze vybírat dle jeho vyměřovacího základu.

A teď zpět k online formuláři. Je tam položka výše rodičáku, což si myslím, že nikdo krom paní na úřadě vůbec nemá šanci spočítat, nejsou k tomu postupy, jak to udělat. Nechal jsem to nevyplněné a museli jsme na úřad stejně osobně. Spočítání výše rodičáku je složité. Například v měsících, kdy je část měsíce na mateřské muž a část žena na rodičáku, ovlivňuje PPM muže výši rodičáku ženy. Tedy v případě vyššího platu (a PPM) manželka v těchto měsících nedostane žádný rodičák, přestože je to jiná osoba, ale zas po tu dobu nebude muset platit zdravotní. Komplikované jak cukrovar.

Dále je tam bod, že pro volbu na základě příjmu partnera je nutné doložit jeho Potvrzení o denním vyměřovacím základu ovlivňujícím výši rodičovského příspěvku nebo Potvrzení o nároku na dávky (náhrady) ovlivňující nárok na výši rodičovského příspěvku. Bohužel jsem si v tu chvíli nepřečetl pozorně jiný bod v sekci v “K žádosti prosím doložte”, psáno malým na konci, a to, že je třeba doložit ten druhý formulář v případě, že jeden z rodičů pobírá PPM – pojmenování formulářů nepomáhá. Takže jsem vytisknul ten první (o denním vyměřovacím základu) a jel s tím na sociálku na Prahu 8. Na formuláři je jen kolonka na denní vyměřovací základ. S přílohou s ročním výpisem příjmů jsem se s důvěrou obrátil na úřednici a čekal, že doplní číslo, razítko, datum, podpis a půjdu. Paní mi řekla, že ať doplním adresu někam na papír (na formuláři na to ani nejsou kolonky!), a že mi to do 30ti dnů pošlou! Při představě rodiny, co nemá rezervy a třeba nižší příjmy velká paráda. Manželka “překvapivě“ moc poslední dva měsíce před porodem nepracovala a na první výplatu rodičáku si ještě počkáme. Jestli vůbec požádáme do konce šestinedělí, bude to zázrak.

4. 6. 2015

Nastoupil jsem na mateřskou.

15. 6. 2015

Byli jsme na sociálce kvůli snížení manželčiných záloh. Bohužel na snížení je třeba mít rozhodnutí o rodičáku. Tak jsme jeli na pracák. Tam manželka čekala spolu s dalšími lidmi před kancelářemi. Já jsem čekal s Jášou v autě. Po nějaké době prostě šla dovnitř, aby našla tři úřednice a žádného klienta. Jedna úřednice brouzdala na internetu, druhá brala třetí míry na kalhoty. Pak úřednice přesvědčovaly manželku, že jdu na rodičák já, než pochopily, že jsem opravdu na mateřské a ona chce rodičák za prvních šest týdnů a na dobu po skončení mé mateřské.

Dále manželka dostala při předchozí návštěvě seznam papírů, co má přinést. Ale chtěly po ní ještě rodný list syna, OK, a oddací list! Oddací list prý potřebují, protože od svatby nebyla žádat o žádné dávky!? K čemu je občanka, ve které má nové příjmení, je mi záhadou. Po mailech jsme naštěstí našli obojí naskenované a vytiskli to, originály byly v Praze. Nato nám paní sdělila, že nám chybí příloha – Potvrzení o nároku na dávky (náhrady) ovlivňující nárok na výši rodičovského příspěvku. To jsme se dozvěděli, že rodičák je ovlivněn mateřskou vyplacenou v tom měsíci. Pořád řešíme výplatu fixních 220 tisíc, ale pravidla jsou dle všeho velmi složitá. V onom chybějícím potvrzení se vyplňuje mé jméno a rodné číslo a jméno a rodné číslo syna. Tedy všechno údaje, které jsou v žádosti o rodičák. Žádný podpis, nic. Přesto musím já tento papír poslat na sociálku, a pak jej odnést na pracák. K tomu ta 30ti denní lhůta. A úřady mají všechny informace, protože jsem už o mateřskou zažádal začátkem května. Plus vše jsme absolvovali se synem, protože kojíme a sám bych ho tři hodiny doma hlídat nemohl.

Taky se nám blíží promlčecí lhůta, neb o dávky lze žádat maximálně tři měsíce zpětně. Díky “rychlosti a ochotě” na sociálce na Praze 8 (v Bruntále tyto věci opravdu dělají na počkání) to možná ani do tří měsíců od narození dítěte nestihneme. Uvidíme.

Plus by se to dalo udělat ještě složitější. Mám jako muž nárok na 16 týdnů mateřské (22 po narození bez šestinedělí). Nevím, jak bychom žádali o rodičák na šestinedělí v případě, že bych nastoupil na mateřskou na 10 týdnů a v půlce se rozmyslel, že chci ještě další měsíc. Řekl bych, že správný postup nakonec je opravdu ten papír s vyměřovacím základem, požádat o rodičák v nějaké výši. Pak nastoupit na mateřskou a dodat další papír? Nevím.

16. 6. 2015

Ježto se formulář s denním vyměřovacím základem dlouho nevracel, poslal jsem 8. 6. email na pražskou sociálku, aby mi obratem vypracovali fikci – použil jsem formulaci a adresu, které mi poradila úřednice při podání toho formuláře 12. 5. Dnes! mi došel email, že můj email dostali a budou se jím zabývat. Takže 30 dní na vyřízení formuláře s jednou kolonkou, 8 dní na přijetí emailu. Je něco shnilého na ČSSZ Praha 8. Formulář mi mezitím přišel do Prahy 12. 6. tedy přesně v oné 30ti denní lhůtě.

Dále

Přesná data v následném vývoji nemám, tak jen shrnu. Na pracáku nám nakonec dali rodičák na šestinedělí na 9.000,- využívajíc papír o vyměřovacím základu. Potvrzení o mateřské mi přišlo dvakrát. Docela to trvalo. Jedno z toho přišlo z ČSSZ Nymburk 16. 9.! Nechápu. Po dodání potvrzení o mateřské jsme na pracáku nastavili maximální výši rodičáku na dobu, dokud bude zbývat něco z těch 220 tisíc a 0,- na zbytek času do dvou let. Pořád nechápu, že jsme kvůli tomu museli tolikrát na dva různé úřady, ke gynekologovi, donést tolik papírů a tolik na všechno čekat. Manželka dostala první rodičák 18. 6., tedy téměř dva měsíce po narození syna. Hlavní prodleva byla způsobena liknavostí ČSSZ na Praze 8.

Shrnutí postupu

• Žádost o rodičák lze podat až po narození dítěte.
• Žena bez odvodů musí i tak na sociálku pro papíry pro gynekologa, pak ke gynekologovi, pak na sociálku a počkat na rozhodnutí, že nemá nárok na mateřskou, aby měla papír pro pracák.
• Při absenci dostatečných odvodů pro určení výše rodičáku lze použít denní vyměřovací základ partnera. Získání takového papíru může trvat i 30 dní. Pro volbu je možné použít i formulář s potvrzením o nároku na PPM, tento je třeba doložit vždy, pokud jde jeden z rodičů na PPM.
• Po porodu by muž měl upalovat na sociálku, aby získal příslušné potvrzení.
• V případě že si to můžete dovolit, lze jednoduše počkat, až muži doběhne mateřská, a pak teprve požádat o rodičák. Peníze na rodičák se jen rozdělí do kratšího období, takže o nic nepřijdete a je to administrativně i časově jednodušší, protože systém je nastaven tak, aby tyto podklady byly dostupné až po mateřské.

Návrhy na zlepšení

• Nenutit ženy, aby chodily ke gynekologům a zas zpátky na sociálku, a pak na pracák, když je zjevné, že na PPM nemají nárok. Sociálka jim může rovnou vydat rozhodnutí, že nemají nárok, aby s tím mohly jít na pracák. Nebo ještě lépe na pracáku podepsat čestné prohlášení, že o mateřskou nežádám a pokračovat rovnou s žádostí o rodičák. Ušetří se práce sociálce, gynekologovi a dvě cesty žadatelce.
  
• Nechtít úředně ověřený podpis matky pro svěření dítěte do péče pro účely mateřské otce. To mi přijde genderově nevyvážené. Plus by nebylo nutné nutit matku v šestinedělí do cest na poštu.
  
• Pojmenovat lépe formuláře - "Potvrzení o nároku na dávky (náhrady) ovlivňující nárok na výši rodičovského příspěvku" zní pro běžného člověka naprosto neuchopitelně.
  

• Vydávat "Potvrzení o vyměřovacím základu" na počkání. V Bruntále to tak prý dělají. V Praze to trvalo celých 30 dní, tedy maximální zákonná lhůta. Plus v mém případě bylo zřejmé, že to bude maximální výše. Stačilo doplnit maximální vyměřovací základ, podepsat, razítko, hotovo. Práce na dvě minuty.
• Nechtít oddací list na pracáku, když už má člověk novou občanku.
• Napsat dítě do občanky, nebo rodiče do občanky dítěte. Máme občanku pro malého a stejně s sebou musíme všude nosit jeho rodný list, protože úřednice jinak nevěří, že jsme jeho zákonní zástupci. To je pěkně na hlavu. S rodným listem s sebou můžu vzít jakékoliv dítě a taky mi budou muset věřit, že je moje a je to právě to, co je napsané na rodném listu. Dle úřednice na Praze 8 nemají přístup k údajům lidí mimo Prahu 8. Chápu, ale stačilo by zařídit, aby do systému mohla úřednice zadat čísla občanek, nebo rodná čísla a systém by jí řekl že "Jáchym Burkert je syn Evy Burkertové". Nemusí mít přístup ke všemu, jen k vazbě mezi lidmi. Pak odpadne nutnost nosit s sebou všude ověřenou kopii rodného listu.
  

Přestěhovali jsme se do Berlína, takže bude následovat pokračování, aneb co v situaci, kdy se přestěhujete do zahraničí. Totiž výplata rodičáku je vázána na pobyt na území ČR. Moc nechápame, že když jsme na území EU, manželka dál pracuje pro klienty v ČR, v ČR odvádí daně, je tam zdravotně i sociálně pojištěna, tak musíme žádat o rodičák v Německu, a pak řešit doplatek do výše v Čechách s českým úřadem práce. Ale o tom až příště.

Envers: it's slower but at least it doesn't work in some cases

Why not Envers?

Envers is an auditing extension of Hibernate, following the mantra that Java developers should code in Java and not think in terms of the database. Java developers are shielded from the relational features of the database; SQL is evil as it leads to vendor lock-in (when was the last time you switched the database of an existing system?), and the ORM pretends that what you load from the database is objects. The performance often suffers, the framework at times does not support features databases have had from late 80ties and you have to fight its leaky abstraction and bugs. But back to Envers.

Envers comes with limitations that emerge from its very nature. It tracks the Java entities changed within the transaction and then issues inserts into the auditing tables and the revinfo table. For us the main problems of this approach are with its performance:

• The number of resulting SQL statements is too high. Every insert/update/delete triggers another statement run against the database. These statements need to passed to the database over the wire, increasing the duration of the transaction.
• Bulk updates, deletes are not supported. Operations such as 'DELETE FROM foo' are not auditable because Envers has no way to know which entities were affected. If you want auditing you have to update every entity separately, leading to potentially many updates and auditing inserts instead of one simple statement.

It should be said that when Envers knows about the entities it works correctly, so for most applications it can be good enough. We used Envers in the prototyping phase of our project but it made it hard for us to handle high loads. Hence, we investigated those relational features we are told to avoid. We put the database to work and replaced Envers with database triggers. There were some turns back and forth and in the end it took us four days to get to a state we are happy with. In this article I want to share our solution for PostgreSQL.

Auditing with database triggers

Auditing

First, let's define what we mean by auditing. We need to audit for regulatory reasons, so we need to know who (which customer, not database user) and when performed what operation. For those tables we need to audit we defined auditing tables which have the same columns as original tables.

Generic Trigger

First, we created a generic database trigger that inserts the row being modified into the auditing table:
There are few things to note here:

• Auditing table for foo is foo_aud.
• We used the PostgreSQL trigger variables: TG_TABLE_NAME, OLD, NEW, TG_OP.
• The query is by design dynamic and must be run with 'EXECUTE ... USING ...'.
• The construct '$1.column_name' references a column in a record. The record is the first parameter to the dynamic query and is either the NEW or the OLD trigger variable. You don't want to know how long it took me to figure this one out :).
• The PostgreSQL transaction ID is used to find corresponding row in the revinfo table - see section Who and When bellow.
• Along with the columns of the original table, the audited table has a varchar 'op' and a integer 'rev' column, containing the operation (insert, update, delete) and the rev from revinfo respectively.

The following script assigns the trigger:

Element collections

Auditing of updates to element collections works out of the box. The respective auditing tables need to have the two columns (op, rev) and the trigger must be assigned.

Who and when

The original goal was to know which user made the change and when. We ripped off Envers and introduced a table like the revinfo table. It contains one row for every transaction that modifies an audited table, together with the who and the when:
The table contains information about the application user, the time and the transaction ID. The transaction ID allows us to link auditing entries to a revinfo row. We cannot use transaction ID directly. It is unique only within one PostgreSQL installation. If we migrate the database to a different server old txid entries might clash with its txid sequence. With our solution, we only need to set txid to null and then migrate the database.

The problem that remains is inserting a row into this table for every write transaction. Ideally, we would insert it only when a transaction modifies an audited entity. So, we added an interface, @AuditedEntity, to mark the audited entities and we registered a listener on the very same events Envers does. The listener then inserts a row into the revinfo table when a transaction performs the first write operation to an audited entity.
A few points to note:

• The insert must happen before the entity change due to the referential integrity from auditing table to the revinfo table.
• We need to perform the revinfo insert with session.doWork(). A simple session.createSQLQuery() and then query.executeUpdate() would cause Hibernate to flush the dirty entities.
• HQL/SQL bulk updates do not trigger Hibernate events, hence we must register the transaction manually using the register(SessionImpl session) method.
• It is plain evil to use internal Hibernate classes like SessionImpl but we need methods from both SessionImplementor and Session interfaces. Those are combined in the EventSource but that is not available at the point of registering a transaction manually, there we only have the Session. It all boils down to the SessionImpl anyway so we bit the bullet and made the cast. We know we will suffer when we upgrade to Hibernate 5.

We register the events in a ServiceContributingIntegrator:

Conclusion

Our approach performs auditing on the database level. The application only needs to call one insert per write transaction to store user and time information under the transaction ID. The approach supports auditing of SQL/HQL bulk updates.

We haven't done any rigid performance test yet. But we do generate data for the application performance test; it results in inserting approximately 100k rows. The data generation took 50 seconds with Envers auditing, it takes only 35 seconds with database triggers so we look at the improvement of 30%.

Have we overlooked anything? Any suggestions are welcome.

Selenium in Sonar code coverage metrics

Goal

• Run Selenium GUI tests as part of the build on Jenkins.
• Collect code usage data to be able to report code coverage on Sonar.

Project Layout

• Cloudex-parent
• • Core module - services, daos
  • GUI module - for instance Wicket web GUI
  • Test module - Selenium integration tests

Configuration

There are two relevant parts of Maven config - parent POM which defines JaCoCo offline instrumentation and the test POM which covers deployment to embedded Tomcat and running.

parent pom

Test POM

Just few more points:

• The config module contains build folder with /lib folder with the configuration which needs to be in Tomcat.
• We need to include jacoco-agent.properties file in the /lib folder from the previous point. It should contain at least a single line: destfile=${sonar.jacoco.itReportPath} (see offline instrumentation).
• Selenium tests which should run are defined in the testng.xml.
• We have a dedicated database on external server which is migrated and against which runs the deployed application.
• The tests run in Firefox on a headless system (Jenkins master) thanks to Xvfb (X virtual frame buffer), so the Jenkins server must have Firefox and Xvfb installed.

Non-transactional tests with Spring and H2

The general paradigm for testing Spring based application back-end is to use a sort of unit testing which loads the whole application (the application context) and performs certain tests on it. Spring provides all sort of helper classes among others AbstractTestNGSpringContextTests and AbstractTransactionalTestNGSpringContextTests. I don't know when that decision happened but we always used the transactional one hence every test method run in a separate transaction which was rolled back after each method. It seems to me that such an approach is prevalent in current development yet it is as well flawed.

I bet you encountered cases when the test cannot be transactional, you want to test that your fix for a concurrent race condition works, the locking on the DB does really prevents another user to access something, etc. So you write a non-transactional test class, annotate it with the Spring annotation @DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD) and you're done. The context is reloaded several times for the start so it's not a big deal. But then you write tens of non-transactional tests and all of a sudden build with tests takes time.

That happened to us and made us thinking, do we need to recreate application context so often? The only reason we do it is that the DB is polluted by the non-transactional tests data. I started the investigation. We use in-memory H2 for our tests. I found that H2 has a wonderful feature which let's you drop its content easily: All you need is the following method in your test parent class:

So no more context recreation. It sped our test build from 1:30 to 55 seconds, boohoo. But than a heretic thought began to creep in our brains. What if we don't need to wrap each test method in a transaction? What if we don't gain much speed there? What if we actually oversee a bug here and there as our tests don't work the same as when client works with the application?

We gave it a try and made all tests non-transactional. The build takes the same time as before as populating and dropping in-memory DB is apparently not an issue, we would do the same in separate transactions anyway. The tests now mimic exactly use cases we want to test as often many transactions happen before the app is in certain state.

We found three bugs straight away. I hope you find some too.