Migration Script is not working in Branches
joseph.tg
Posts: 14
Hi Team,
I have Dev,Test and Stage branches created in TFS. Dev I have linked 'Dev Branch' to the Red gate Source control and developers are able to commit their changes properly.
For the 'Test Server' deployment, we are merging the selected changes directly from 'Dev Branch' to 'Test Branch' from 'Dev Branch'. while check-in a command line script will execute and it will update the changes to the 'Test database'.
For the 'Stage Server' deployment, we are merging the selected changes from 'Test Branch' to ' Stage Branch'. while check-in a command line script will execute and it will update the changes from 'Stage Branch' to the 'Stage database'.
Now I am facing an issue with migration script. Migration script only considering in 'Dev Branch'. While doing the Test/Staging deployment these migration scripts are not considering.
How to resolve this issue?
How the branch structure will support in red gate source control?
Regards,
Joseph
I have Dev,Test and Stage branches created in TFS. Dev I have linked 'Dev Branch' to the Red gate Source control and developers are able to commit their changes properly.
For the 'Test Server' deployment, we are merging the selected changes directly from 'Dev Branch' to 'Test Branch' from 'Dev Branch'. while check-in a command line script will execute and it will update the changes to the 'Test database'.
For the 'Stage Server' deployment, we are merging the selected changes from 'Test Branch' to ' Stage Branch'. while check-in a command line script will execute and it will update the changes from 'Stage Branch' to the 'Stage database'.
Now I am facing an issue with migration script. Migration script only considering in 'Dev Branch'. While doing the Test/Staging deployment these migration scripts are not considering.
How to resolve this issue?
How the branch structure will support in red gate source control?
Regards,
Joseph
Comments
The current way that the Migration Scripts operate, they do not support or work across branches.
The good news is that these is a project in development, known as Migrations V2, which is planned to address the branching issues. Sadly I do not have an ETA as to when this new version of the Migrations process will become available.
When I receive further information, I will update this forum post.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
You can join our Google group where we're discussing the development of migrations v2 here: https://groups.google.com/group/red-gate-migrations
We've just released an early access build of SoC to demonstrate the approach we're considering.
David
We are in the middle of Red Gate source control implementation. Can you please update me the ETA of this functionality.
Also we are using SQL compare and SQL Data Compare for automated (Command-line) deployment. Are we going to integrate the migration scripts functionality soon? What will be the ETA of this?
My requirements are:
1) Migration scripts should work across the branches. Means, I need to deploy the database changes from Branch to database including migration scripts.
2) I need to include custom scripts for the deployment, this also should work in branch architecture.
3) Both Migration scripts and Custom scripts need to deploy from one Branch to databases through the command line scripts
Can any one update me, whether above 3 points are going to cover with new release or not.
Regards,
Joseph
The early access release of SQL Source Control with Migrations v2 is now available. You can read more about this and download it from http://documentation.red-gate.com/displ ... ss+release.
We do not have a command line yet, but should have that shortly (within a week or 2). I will update this forum as soon as it's available. This will help with automated deployments and pick up Migration scripts. It will then go into SQL Compare and SQL Data Compare (GUI and command lines), but I don't have an estimate for this yet.
Regarding your requirements:
1) Migration scripts should work across the branches. Means, I need to deploy the database changes from Branch to database including migration scripts.
This should work. We no longer rely on repository location or revision number so that Migrations will work across branches.
2) I need to include custom scripts for the deployment, this also should work in branch architecture.
I don't understand how a custom script is different from a migration script that is used during deployment. Could you explain this more?
3) Both Migration scripts and Custom scripts need to deploy from one Branch to databases through the command line scripts
As mentioned above, we should have a command line shortly that will pick up Migration scripts to be used in automated deployments. I'm not sure about what you mean by Custom scripts. Migration scripts are custom scripts that are re-used by SQL Compare during deployment.
Cheers!
Stephanie M. Herr :-)
Product Manager Database DevOps
Custom script means, suppose I have to update some data in a table as part of a deployment. This is not a part of DDL changes. In this case I want to create a script and execute the same at the time of deployment.
How we can achieve this with Migration Script V2 ?
Regards,
Joseph
Thanks for clarifying. In Migrations v2, a migration script doesn't have to be tied to DDL changes. So, you can just write your UPDATE script as a migration script and this will be picked up like all the other migrations. To do this, use the "Add migration script..." button on the Migrations tab.
Stephanie M. Herr :-)
Product Manager Database DevOps
Thanks for your quick response!
I am using command-line SQL Compare for automation. What will be the ETA of this Migration V2 integrated command-line SQL Compare
Can I expect this in next 3 months?
If it is more than that, is there any alternate method for this?
I want to communicate the ETA with my team. Can you help me on this.
Regards,
Joseph
We should have a command line that will do what you need within the next week or 2. This will pick up migration scripts and also do a SQL Compare of the source and target to either generate a deployment script or synch the target directly. Just like SQL Compare will do.
It's separate for now while we integrate Migrations v2 into the SQL Compare GUI. Once this integration is done, then we'll have a release of SQL Compare with the updated command line to pick up the new migrations.
So, you can use this alternative command line to do automated deployments (esp. in CI environments) until SQL Compare is ready. It will have the same licensing requirements as SQL Compare.
I hope this helps! We'd love to hear how you get on with the SQL Source Control Early Access Release and this migration command line tool.
Stephanie M. Herr :-)
Product Manager Database DevOps
As Stephanie mentioned, you can now download the command line tool to use in your automated deployments from here: http://documentation.red-gate.com/display/MV2/
The above link also contains documentation to help you get started with migrations V2. If you want to be more involved in our development decisions, please join us at https://groups.google.com/group/red-gate-migrations
Let me know if you need any help with the command line tool.
Thanks,
Ruchika Raj
SQL Source Control Development Team
Red Gate Software Ltd.
T: 01223 438855
Can you explain how to generate migration script using command line? Is there any worked example for this?
Regards,
Joseph
I've written a quick guide to help you with the command line tool:
ftp://support.red-gate.com/patches/SQL_ ... e_tool.pdf
Let me know if you still need any help.
Cheers,
Ruchika
Now I am using SQL compare command line for automated deployment
(SqlCompare.exe).
What is the ETA of Migration V2 integrated SQL compare command line?
Thanks,
Joseph
We're expecting to do a beta release of SQL Compare with Migrations V2 sometime during the 2nd week of October. Meanwhile, were you able to use the migs.exe command line to generate your deployment scripts?
Cheers,
Ruchika
Is Migration V2 integrated SQL compare command line released? If not, what is the ETA for this?
Regards,
Joseph
Can anyone update me the status of Migration V2 integrated SQL compare command line?
Is Migration V2 integrated SQL compare command line released? If not, what is the ETA for this?
Regards,
Joseph
You can download the new here: http://www.red-gate.com/migrations
I have evaluated the migration v2 SqlCompare. This is working as per my requirements. Please clarify below points.
1) Is there any way to rollback the migration script changes.
2) I am already using the rollback mechanism for schema changes, if I use the new sql compare (mv2 integrated) how this will work? I mean will this break the existing rollback mechanism or not?
3) While evaluating MV2, I didn't set up the temp database, still it is working as expected. Is this temp database setup mandatory or not?
4) lastly, what is the ETA of the actual(not beta version) Mv2 integrated Sql Compare.
Regards,
Joseph
Yes, there is a provision to add rollback scripts which will be applied whenever you're doing a rollback. Basically, every migration script in V2 consists of two parts - an upgrade script and a downgrade script. As of now the user interface only allows you to add an upgrade script, but the engine code handles downgrade scripts as well. Let's say you wanted to rollback your database from v3.0 to v2.0 (the previous version), the migration engine would then look for the migrations scripts that had been applied as part of the upgrade from v2.0 to v3.0. It would then pick the corresponding rollback scripts and apply them in order before the SQL Compare Engine rolls back the rest of the schema change. As an example, if you're doing a table rename in your migration script, you could include a rollback script that would do the reverse of the rename. Let me know if you need any help with adding the rollback scripts.
Could you help clarify what you meant by whether this will break the existing rollback mechanism? The mechanism for SQL Compare rollback is still the same. The only difference here would be that the migration script rollbacks would be applied first.
The TempDb setup is not mandatory. MigrationsV2 by default tries to connect to LocalDb if you have one installed. I think that would explain why this still worked for you. :-)
Regarding your last point, we don't have an ETA yet, but we're working actively towards it. I'll keep you up-to-date on this.
In one of your previous comments you mentioned that "A check-in a command line script will execute and update the changes to the 'Test database'" from the TestBranch. Is it fair to assume that you're using the SQL Compare command line to achieve this? Also, I'm very keen to know how your environment was setup when you evaluated the beta. Let us know if you have any other feedback from your evaluation experience.
Thanks,
Ruchika