Multiple projects connecting to one db.
robertchiha
Posts: 6 Bronze 1
Hi,
We currently use ReadyRoll for our web application that deploys to all environments using bamboo.
It includes a few websites and an api.
We do blue-green deployments to deploy the application at any time of the day, sometimes multiple times in a day with no down time.
I have to build a new application that will have its own tables and stored procedures.
It will be a TCP service that can only be restarted/deployed during certain outage windows. But will need to have as minimal downtime as possible. It will not need to be modified and deployed very frequently.
So it will need to be on its own deployment plan.
I would prefer to not have either applications deployment plan to be dependent on the other.
I am now trying to work out the best way to structure the projects and the deployment plans.
I have considered using a separate db and an api call for any data needed from the current system. but there are some requirements for reports that read from both database sets and would also like to have some referential integrity across the applications.
I am now thinking it would be best to have it in a new schema under the same db.
The new application will read some existing tables from the old schema.
My options are :
Have two separate db projects and only import each schema into its own database project
I would have preferred this option but I don't think it is possible as the db will not be able to build on its own due to procedures that call data from existing tables and foreign keys that reference existing tables. This won't be able to build in the shadow db?
Leave the DB as part of the web application deployment plan and ensure it runs before I run the TCP Service deployment.
This means that breaking changes could become an issue forcing me to deploy the applications together. AS long as I keep the sproc signatures for the new schema the same I can continue to deploy the db along with the current solution and leave the TCP service as is.
But if there are modifications to the tcp service procedure signatures I will need to have an outage while it waits for the application deployment to complete before deploying the service.
Have all tables (old and new) deploy with the web application and have a seperate ready roll project with just the stored procedures for the TCP service
Not sure if this will work? If the Shadow db will allow it to build with stored procedures that have tables that don't exist? Or will both projects use the same shadow db?
I guess my question is am I going about this the right way. Is there something else I am not considering?
We currently use ReadyRoll for our web application that deploys to all environments using bamboo.
It includes a few websites and an api.
We do blue-green deployments to deploy the application at any time of the day, sometimes multiple times in a day with no down time.
I have to build a new application that will have its own tables and stored procedures.
It will be a TCP service that can only be restarted/deployed during certain outage windows. But will need to have as minimal downtime as possible. It will not need to be modified and deployed very frequently.
So it will need to be on its own deployment plan.
I would prefer to not have either applications deployment plan to be dependent on the other.
I am now trying to work out the best way to structure the projects and the deployment plans.
I have considered using a separate db and an api call for any data needed from the current system. but there are some requirements for reports that read from both database sets and would also like to have some referential integrity across the applications.
I am now thinking it would be best to have it in a new schema under the same db.
The new application will read some existing tables from the old schema.
My options are :
Have two separate db projects and only import each schema into its own database project
I would have preferred this option but I don't think it is possible as the db will not be able to build on its own due to procedures that call data from existing tables and foreign keys that reference existing tables. This won't be able to build in the shadow db?
Leave the DB as part of the web application deployment plan and ensure it runs before I run the TCP Service deployment.
This means that breaking changes could become an issue forcing me to deploy the applications together. AS long as I keep the sproc signatures for the new schema the same I can continue to deploy the db along with the current solution and leave the TCP service as is.
But if there are modifications to the tcp service procedure signatures I will need to have an outage while it waits for the application deployment to complete before deploying the service.
Have all tables (old and new) deploy with the web application and have a seperate ready roll project with just the stored procedures for the TCP service
Not sure if this will work? If the Shadow db will allow it to build with stored procedures that have tables that don't exist? Or will both projects use the same shadow db?
I guess my question is am I going about this the right way. Is there something else I am not considering?
Tagged:
Answers
Thanks for your post.
This looks like a question that one of Support engineers will need to investigate for you.
If you've a got support contract, please send us a ticket. Provide as much information as you can - screenshots of any errors, log files etc – so we can help you as fast as possible.
If you're not covered by a Support contract at the moment, email our Sales team at sales@red-gate.com, and they'll be able to help.
Redgate Software