I'm new of database versioning, I'm developing a java web application (vaadin,spring,spring-data-jpa) where I'm using maven like tool of project managment. Through manen I'm managing releases and sorce code versioning. Now my trouble is the database versioning. I try to explain my problem through an example:
When my application is at version 0.0.1-SNAPSHOT I made a database that contains some tables, at a certain point I decide to release this version (1.0.0), and install it on my production environment, while inside my trunk (on SCM) I have the version 1.0.1-SNAPSHOT. Now I have to add some new functionality and these new functionality require to add some others tables and attributes, when I finish to develop these new functionality i update my database and release the (1.1.0). Now if for some problem I want to reinstall the 1.0.0 I'm not able to reset the database state. I saw that there are some plug-in to database versioning How to: database versioning with maven2?, but i would want some suggestion what are the guidelines in these cases, and what plug-in would allow me to manage them.
Related
I'm working with a Grails application version 2.2.4 and I need a procedure for upgrade to latest version (I hope it can be possible). I have thought as a first step to follow the indications of the official site, but that let me to upgrade to version 3.
I'd like to know if anyone already did it or have experience about that. How long take it?, the process and the main problems.
Many thanks in advance.
I think you need to follow both upgrade instructions. the one for 3.x and the 4.x.
start with the 3.x and them move to the 4.x changes.
Another approach I think may be better is to start an empty 4.x application and then start moving you code there. also check first that all the plugins that you are you sing have 3+ version.
The effort required to upgrade can change massively depending on multiple factors, including the size of the project, the quality of the original code, were plugins used and if so have they been updated or will the functionality need replacing, were deprecated taglibs used, e.g remoteFunction etc. etc.
There is not a great deal of difference between 3.x and 4.x so it makes sense to upgrade to 4.x.
Tackle it in stages from the basis of a new project, attempting to rebuild the project between stages.
Reestablish configuration, you don't have to use application.yaml (the default in 4.x) so can create an application.groovy with the same parameters as per your old project.
Move over domain objects but use a new database URL, compare the schema's between the old db and new db to ensure the database is the same. Unless you don't rely on GORM to recreate/update the schema.
Move over any other source and command objects ensuring the project will build. You may need to modify buildconfig at this stage to bring in dependencies and plugins.
Move over services, ensure all compiles and make sure transactions are behaving as intending.
Move over controllers ensuring any tests run successfully.
Move over the views.
Hopefully if the project is still building at this stage, you can run it!
We are using VSTS for build and release management, and using CI/CD. Typically, our solutions consist of a web application project, and a database project.
Our current release tasks take the application offline (using app_offline.htm), publish the database, then publish the web application. Publishing the database project often results in no changes, as due to CI/CD we are much more frequently updating code on the web app than changing the db schema.
Is there a way to only run the database publish task (using WinRM) when it detects a change in the database project code, in our git repository?
EDIT: This in itself isn't a problem, as typically when the DACPAC gets published, there will be no activity. HOWEVER, I've been requesting that the database is backed up using the /p:BackupDatabaseBeforeChanges=true flag - which seems to back up the database even if there are no changes. This is an issue for large databases.
The simple way is that you can separate web project and database project to two build definitions.
Create a new build definition
Enable Continuous Integration in Triggers tab
Specify Path filter to include database project
Modify Visual Studio Build task, specify /t:[database project name] argument in MSBuild Arguments box to just build database project
The same steps for web project
Create a new related definition
Add artifacts for previous two build definitions and enable Continuous deployment trigger
Add two environments (e.g. database, web)
Open Pre-deployment conditions of an environment (e.g. database)
Enable Artifact filters and select corresponding artifact (e.g. database build artifact), specify build branch (can specify *, it means all branches)
Add tasks to just deploy database in this environment
The same steps for web environment
The answer is - exactly what I want isn't possible.
Ours a complex enterprise app and we use one third party library which we would like upgrade.But we do want to maintain two versions atleast for couple of releases till we are good with the newer version and switch which version to use by a configuration property.
We are trying maven shading for the same.
However the problem we are facing is like this. The changes between the two releases are very drastic. For example A is a class in version 1.0 and is now an interface in version 2.0
So let us say for example in the existing client code we say
A a = new A();
This would have to be changed to some other call in the new version.
Are there any ideas on how to make the client code compatible with both the versions?
I don't believe there is a way to write code compatible with both the versions.
Keeping multiple versions of same jar may create maintenance nightmares.
I suggest to create/maintain separate SVN branches for each version of this jar.
You can decide which SVN branch should go into production based on maturity of that branch.
You can simply replace the war from other branch, if any issue during deployment/in production.
I have create a small plug in and I have released it with version 1.0.0. Now I want to add some advance functionality in it and release again with Version 1.1.0. I am beginner of Microsoft Dynamic CRM. I don't know how to keep existing data.
I have tried by following.
1- I have created Managed Plugin and released 1.0.0.
2- Now I have added few new functionalities and released new version 1.1.0.
3- I have removed older version 1.0.0 from CRM Account and added new version 1.1.0.
But when user import new version 1.1.0, the old data of version 1.0.0 lost. I want to keep all existing data when user add newer version.
Can anybody suggest me steps or link about how to manage?
If you've published your customizations as a Managed solution (which, from your comments you have), and you deleted the managed solution from your CRM environment, then any entities included in that solution have been deleted from your CRM environment, including all the data included.
This is by design for managed solutions.
The only way you will get that data back is via backup-recovery if you have backups in place.
Update
Some additional links from Microsoft about solution versioning:
https://msdn.microsoft.com/en-us/library/gg328109.aspx
https://msdn.microsoft.com/en-us/library/gg309325.aspx
we would like to upgrade from Sonar 3.0 to 3.5. we have many project profiles/matrix in the current sonar and if possible to import existing project matrix, build data and time machine data into the new sonar. How do i export current data and make them visible in Sonar 3.5?
Tried to upgrade in my testing machine and turned out Sonar page is empty. I followed all the Sonar upgrade guide including backup. It is important for us to keep existing project build and trending matrix(time machien).
btw, i'm using mysql.
When using Sonar with DBs like Oracle, MySql, Postgres or MSSQL, the migration process keeps everything already in place and you should end up with the same state as it was before the migration. If this is not the case, this means that the migration went wrong and you should be able to see it in the logs.