Our first steps with SonarQube could be done without much thought on security, reliability and how we can protect it. If you want to use SonarQube beyond your pet projects, you should start making some changes to your installation.
This post is part of the SonarQube series. You can find the other parts here:
- Part 1: SonarQube: Installation Walkthrough for Windows and SQL Server Express
- Part 2: Collecting Data on your Projects with SonarQube Scanner
- Part 3: Start Analysing Code with SonarQube
- Part 4: Fine-tune the Collection of your SonarQube Projects
- Part 5: How LOC is computed in SonarQube, NDepend and Visual Studio
- Part 6: Customise the Rules in SonarQube
- Part 7: Get SonarQube Ready for Production
- Part 8: Integrate SonarQube with Visual Studio Team Services
- Part 9: Integrate SonarQube with Visual Studio using SonarLint
- Part 10: Leverage SonarQube to Fix Technical Debt in Multiple Projects
Windows Service
Starting the SonarQube executable by hand was ok while exploring it. Now we need a more reliable solution that starts SonarQube after a reboot without any manual intervention. Right next to the executable for the server is an installer that will create a Windows Service running SonarQube. All you need to do is to execute this tool:
When the installation is done you find SonarQube in the list of services running on your computer:
User Management and Tokens
Keeping the default password for the admin user isn’t a good idea. Everyone else knows that password and can therefore modify your installation. Log in as user admin, click on “My Account” and then change the password:
Don’t use the admin account for your daily work. Create application specific users and give every developer that should work with SonarQube their own account (don’t forget to create one for yourself).
Click on the Administration menu (1), select Security (2) and choose Users (3) to open the user management page:
In the top right corner is a button to create a new user. You only need to fill in a login name, the name of the user and a password:
Your newly created user is now in your users list. If this account is for a service like your build server, then you should create an access token:
Every token should get a name that makes clear what the intended usage is. That comes in handy later on when you need to revoke a specific token:
Now is a critical moment: Copy the newly created token (with the copy button) and put it somewhere safe. You will not be able to view the value of the token again. If you don’t do that you will need to create another token – that’s no big deal, but it gets annoying when you created a whole list of tokens.
Don’t forget your Backup
SonarQube, like every other system, needs a backup. The database needs to be backed up and I suggest you also make a backup of the installation folder. Your plugins are there, and they may get lost when you make an update.
Update your Plugins
You may not have noticed, but even the basic installation of SonarQube uses plugins. The functionality you used to analyse your C# code is a plugin. There are many plugins and they may change frequently – including the rules those plugins work with. You should check at least once a month if there is an update and decide if you want to use the new rules or not. You find the plugins under Administration (1), System (2), Update Center (3):
Update SonarQube
SonarQube gets updates as well. You can follow @SonarQube or subscribe to the blog to get the news on new releases right from the source.
The official documentation has a very useful update guide. Don’t forget to make a backup before you start. And remember that you definitely have plugins that need to be updated and then copied over. (Being unaware of this fact will result in errors that SonarQube doesn’t know how to analyse your C# code).
Next
Now is all in place to work with SonarQube in a serious manner. In the next post we include the code analysis in the builds on Visual Studio Team Services. Automating the analysis part is a must-have when you want to use SonarQube seriously.