I have installed SonarQube on one server and using it after each build from GitLab for all the environments. Please suggest if we have to maintain SonarQube for each environment or just one install is enough?
What is the process to separately maintain Sonarqube for each environment?
Please provide your suggestions.
Hi,
Welcome to the community!
It’s not clear to me what you mean by environments. At a guess, this is Dev, Test, QA, & Prod?
Assuming that’s right, I would think you only needed one instance of SonarQube. Since code changes aren’t expected in any environment but Dev, analyzing there should be sufficient.
But if I’ve guessed wrong, please correct me & I’ll try again.
Ann
Hi!
Thank you for your response.
Yes, I meant it for QA, DEV, PROD. Do we need to have to maintain sonarqube at QA,DEV,PROD, so that it runs at each point in the pipeline.
From your answer, I assume that this is not required. Please confirm
Hi @lavanya ,
That depends on how your build pipeline is set up. Typically, you scan the code in Dev with SonarQube, and if everything looks OK then you create a build artifact that is then deployed to Dev, Test, QA, Prod, etc. without ever being changed. Only configuration parameters should change between environments.
I’ve also seen setups where there is no artifact storage though, and the code is built and immediately deployed into each environment independently. In this case, or if there are other opportunities where code might change between environments, then you should scan it separately. That doesn’t mean that you need separate SonarQube environments though - you could separate the different code environments via separate projects in SonarQube.
We have set up a Test and a Production environment for SonarQube, so that we can test updates to SonarQube itself. If we e.g. update from 9.3 to 9.4 in Test, and a few representative builds run fine afterwards, then we can be reasonably sure that the Production update will go well. If we run into issues here, we can fix them before touching our Production instance of SonarQube. This is entirely separate from the build and release environments we have set up for our applications though, it is really only intended to test updates to SonarQube itself.
Thank you for the clear explanation. This is helpful.
Can you please elaborate on this? How do we separate different code environments via separate projects in SonarQube?
Thank you!
Hi @lavanya ,
Just give those projects separate names and keys, e.g. ApplicationA_Dev, ApplicationA_Test, ApplicationA_QA, etc.
Cheers,
Christian
Hi,
you didn’t mention your Sonarqube edition (Community, Developer, Enterprise …) and version,
but i guess you’re looking how to map your development strategy to Sonarqube, right ?
Assuming you’re using Git =
Normally you use some git flow, or one master branch with feature and bugfix branches or a pull request workflow.
You should use one Sonarqube instance and have all branches of a development project / artifact
in one Sonarqube project, if you use a pull request workflow it’s a must (pull request decoration).
So you get a bird eyes view on the whole development project with all its branches and see how it evolves over time.
Sonarqube editions >= Developer edition have the branch feature builtin, see
https://docs.sonarqube.org/latest/branches/overview/
With community edition you may use the free
Gilbert