I have deployed one sonarqube server with a postgresql database in an openshift 3 cluster.
The versions that i use are respectively 8.4.2-community and 9.5 for my database.
I am currently in the process of migrating my project in a new openshift 4 cluster.
I have deployed a new sonarqube server with a postgresql db with the exact same versions that i used before. Now is the step where i have to migrate the project history of the old sonar to the new one. i already tried to dump from the old database to the new one , but that did not work so well.
open to solutions for those who want to help
Take a look into Project Move feature of SonarQube Enterprise Edition.
It will allow to export and import of the projects in SonarQube.
Note: Administrative access is needed to perform Project Move.
Related
Is it possible to restrict the publishing of new analysis on a sonar instance. My use case is I created new instance of sonar with the latest version. There are couple of projects configured with the old version. I want to make sure that no project team use old instance of sonar. At server level, is it possible to stop publishing new report.
Also what customization options sonar server gives for its home page. I want to display a custom message with Sonar 5.6 version
Atul
You seem to have stood up two different instances of SonarQube side by side. In doing so, you impose on your teams the requirement to update their CI configuration to point to the new instance.
You should instead replace the old version with the new one. See the Upgrading docs for details.
I am trying two options.
One is not to store source code
If it is not possible how to delete project from sonar database?
I tried with "sonar.import Sources=false" but this is not working for sonar version 6.1(deprecated after 4.5 version).
If I delete the project,will source code remain in database?
Storage of source code in database can't be disabled because it's used to display data in webapp.
Source code is indeed dropped from db when deleting a project.
This is late, but might be helpful for someone:
Sonar usually cache the project for performance purpose via squid mechanism, then thru queue mechanism it stores the project data in internal h2 database which can be changed to few supported databases, then you will be having advanced options to manipulate data on database(things like fail-over cases can be achieved), not that I know of any way of not to store project data in database.
Unless you configure certain user, default user can be admin to sonar dashboard with password as admin, Login to console and navigate to Administration-> projects->Management, now delete n number of unnecessary projects. Once you do this Sonar dashboard will not be able to show the project again until you re-analyze same project. To make sure this worked,after re-analyzing project click on the project on dashboard and check the version under Activity.
Additional info: If you modify the maven project code, first build the project & then do sonar:sonar for latest modifications to be reflected.
I agree with other answer, elaborating in few lines..
I'm looking at implementing a blue/green deployment strategy. It will be for a database driven web application. We are using Teamcity and Octopus deploy currently.
To my knowledge, to achieve this strategy, the changes to the database need to be such that both versions of applications will continue to work, so in the case the of a rollback, the database changes don't need to be reverted.
I have read Octopus suggested implementation of this here.
My question:
Does anyone test the current active application in prod against the database changes prior to promoting to prod? E.g. In Test or UAT?
If so, how do you fit this requirement with the deployment strategy, especially when configuring it with Octopus?
Does anyone test the current active application in prod against database changes prior to promoting to prod.
Octopus lets you easily deploy the current live version to your pre-production environment, so you can test it against the upgraded database prior to deploying the upgraded database to your live server.
So if you have version 1 of your application live with database version a, and have version b of your database coming through, followed by version 2 of your application, you can test this in pre-production...
1 a - Same as live
1 b - First phase of testing (followed by release of `b`)
2 b - Second phase of testing (followed by release of `2`)
Is there a guide that can help me install PeopleSoft, PeopleTools, Tuxedo, Weblogic etc. and connect it to an existing Oracle DB configured for CS?
I'm fine with doing the setup from scratch, but how do I skip the DB creation and just configure the rest to connect to a DB called CSSND2.
Can anyone help with some steps?
The guide I followed is:
http://psst0101.digitaleagle.net/step-by-step/
Oracle has official installation guide for every PeopleTools version.
This is the one for the latest version, 8.55: http://docs.oracle.com/cd/E68526_01/psft/acrobat/PeopleTools_855_Installation_for_Oracle_122015.pdf
If your version is lower, google 'PeopleTools Installation guide ', replacing by your version.
Install all the software on your server, add the details of your schema/database to the tnsnames.ora file, then you can add the App server domain, Process Scheduler domain and web domain. See the guide for details on installation and configuration
I am in the process of setting up SQ for a large organization. I plan to have two separate systems one for update testing and rule development. The second would be the production system where real work occurs. I will be using SQL 2014 typically when I do that I use a SQL always On group to sync to a DR server in another datacenter. My question is with a SonarQube instance does it make sense to DR the application to that level. If my organization can wait for a period of time to stand up a new server in a DR event would that be possible with a proper backup of the DB? Further if there were no backups of the DB what would be lost with a fresh new SonarQube server besides setup/config time? Is there historical value of code scans that would be lost or would the next scan of the code base have us right back to where we were in terms of critical issues found etc.?
Thanks for your replies.
All the data is stored in the database so using DR on the database is a good idea. You should make backup of the database and restoring the database is also a good solution (note that you should do backup of installed plugins).
If you loose the database, you will also loose all the configuration (quality profiles, credentials, etc.) and the history of the analyzed projects.
So to restore a SonarQube instance, you have to :
Restore the database
Restore SonarQube or install the same version
Restore the plugins (${SONAR_HOME}/extensions/plugins)
During the first start, the ES files (${SONAR_HOME}/data/es) will be regenerated and you're instance will then be up and running.
If you have commercial plugins or if you are working with large SonarQube instance you may contact the sales team to have support on this setup.
Disclaimer : I'm working at SonarSource