Our current series of posts focuses on the migration of SonarQube and Jenkins from Tomcat to Windows services.
We have seen how to realize this migration for SonarQube, while still working with Jenkins on Tomcat. I mean, without losing our SonarQube repository, our dashboard, the results of our analysis, the profiles, etc. but also with the ability to launch projects already configured in Jenkins, and without losing any installed plugins, including the one used for the SonarQube Runner.
Today we will see how to migrate Jenkins to a Windows service. And finally get rid of that good old Tomcat. Continue reading
We have seen in our previous post how to migrate SonarQube to a Windows service.
We actually made a new installation, without loosing our repository previously built with our version of SonarQube under Tomcat. We have checked that our projects, the results of previous analyzes, but also all existing configurations (plugins, Quality Profiles, etc..) were not lost.
Good. But what about Jenkins? Our Jenkins under Tomcat was working with the Tomcat version of SonarQube. And now it is working with SonarQube as a Windows service.
How to proceed? Here are the steps I followed.
As I have already mentioned, SonarQube will soon be no longer available for Tomcat, but only as a Windows service. That means that I will have to migrate my platform SonarQube / Jenkins.
This brings some questions: will I loose my settings? Will I loose my analysis? SonarQube uses a database to store the results of the analysis, so we can expect to keep them and their history.
But what about my SonarQube configuration? Will I have to reinstall plugins? Damn, where did I put the license keys for these plugins? And my Quality Profiles? Are they stored in the database or in a file?
Two important news on the SonarSource website.
The Sonar platform, dedicated to continuous inspection of the quality of code, has changed its name for SonarQube, since June 20, 2013. The announcement on the SonarSource website can be found here.
It’s been already some time then, but in fact, it took a couple of months to adjust and get used to talking about SonarQube and not Sonar.
I was wondering if I should change the existing posts on my blog and was hesitating, especially as it represents a certain amount of work, and proves to be a source of errors (especially when it comes to change and check out the many links between all posts). Until I see someone seeking information on SonarQube and saying he only had documentation about Sonar, and asking if it was the same software.