I saw an interesting event DevOps Tooling Day at Pasila Helsinki somewhere around two years ago. The keynote was about how to boost your Software Development with DevOps. Having our current situation in mind with 40 years of expertise and 5–6 million lines of code, I decided to give it a shot and popped up at the venue. With our in-house CI-environment up and running full steam and some personal expertise about Atlassian CI/CD Tools (Jira, Bamboo and Bitbucket) I was eager to find out ideas how to boost Vertex Systems development process.
During the day, I was privileged to hear stories about Volvo and Accenture how they emerged from traditional software process towards Agile and DevOps. At lunch break some networking discussions really hit the break. A small detail at subordinate clause took my attention: Continuous Code Quality and Coverage after each commit as a part of automatic regression tests with SonarQube. An excellent day.
Long ride back to Tampere with a lot of thoughts in mind I decided to try it on my hobbyist CI/CD environment. After couple of long nights, I was able get it running on my personal server with Bamboo and Bitbucket checking the Code Quality of a Java EE / JSF based application. After a first glance, I was not so convinced. A lot of bugs and security vulnerabilities. What? Doesn’t this system really know how to write good code? There must be a lot of false positive errors. I decided to leave it alone, for a while.
At Vertex, I started thinking how to spend my three "out of the box" days helping myself and my company? That’s a good question. Should we give the SonarQube a chance in our development process? After selling the idea to our Build Manager Panu Outinen, we decided to try it together. And raised the bar to include the Code Coverage after unit, integration and ui tests are ran after each commit.
To go back to heading, water leaks and creating bad code have much in common. When you see a water leak, do you fix the problem immediately or let it leak for days before mopping the puddle?
Similarly, should we let bad code escalate and wait for periodic reviews or should we notice and fix the problems earlier? Fixing the leak means putting the effort to “new” code and running quality checks every day or even on every commit if possible time-wise.
Code Quality with SonarQube is now part of our Vertex Flow development process checking the quality and coverage on every commit. We are also using SonarLint with IntelliJIdea of trying to check quality problems as typing new code on IDE. The Code Coverage reports are created after running automated regression to see the parts of the code fully covered of the tests. The report helps to design and implement new unit and ui tests to increase the code coverage systematically.
I want to thank Panu Outinen about the times we spent over night knitting together existing ant-based building scripts with maven. And helping to get the system up and running with me. Special thanks to Henri Helevä, Anssi Männistö, Jari Avikainen, Petri Molkkari and Juho Kärnä for taking the code quality seriously and for putting an effort to a “new” bug free quality code.
CTO, Vertex Systems Oy
Leader and Passionate Developer at Night