February 20, 2018 at 9:14 am
Hello, yes, I know...,
A Prod and Dev, Dev and Prod box on the same one server and same instances setup, not optimal, not my design. However it is my world, and has been for 1.5 years, and an existing system for 3 years. We have lived with this server being company classified as a QA/Test box to have different policies for ease of use, like using it as a production machine, while developing on it hot.
I need a better way to manage a distinction from Dev database engine tables/views, Dev SSIS packages, and SSAS Tab model cubes, from all the Production ones.
Should I have another Database Instance created and call it the same name but with a _DEV, same with the SSIS instance and SSISDB Catalog, and SSAS instance, by way of copying the existing ones?
Then my next question would be, I guess I would keep the Tables/Views, SSIS Pkg's and SSAS cube model names all the same on the Dev instances?
Then lastly, once Dev is completed, and ready to get cut over, stepping over the top of the current prod, how is that done? A migration? And afterward, I would need to open every SSIS package to alter the Connection Manager settings for the proper instances, or is this something that can be done via a PS script on migration?
Thank you for all feedback,
JQ
February 20, 2018 at 12:00 pm
To add another question to this, how does one migrate, deploy or push the completed dev changes from one environment to the other without having to go through manually changing all the internal connections, etc...
February 20, 2018 at 1:34 pm
quinn.jay - Tuesday, February 20, 2018 12:00 PMTo add another question to this, how does one migrate, deploy or push the completed dev changes from one environment to the other without having to go through manually changing all the internal connections, etc...
Synonyms in each database and using ONLY the 2 part naming convention.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 20, 2018 at 3:04 pm
Synonyms are a very good idea, thanks for that. I think what I've learned to make the cleanest single server, single SQL Server app dev prod combo, I'm going to create parallel _Dev instances for the DB, SSIS And SSAS, and with that, I'll manage the packages with project level connection managers, and then deploy the model to the target SSAS instance accordingly and roll this way. I think that can be the easier and cleaner way to deal with my singularity. So I say at this point before actually implementing. Thank you
February 21, 2018 at 9:28 am
In this one box setup I have, if I added one more DB for Dev instance, and one more Tab SSAS instance, and used project level connection manager and the existing SSIS instance with a new added folder for the dev packages, then I would not need to create another SSIS instance, i would only need to use the one, correct?
February 21, 2018 at 10:55 am
quinn.jay - Wednesday, February 21, 2018 9:28 AMIn this one box setup I have, if I added one more DB for Dev instance, and one more Tab SSAS instance, and used project level connection manager and the existing SSIS instance with a new added folder for the dev packages, then I would not need to create another SSIS instance, i would only need to use the one, correct?
Sounds dangerous. People tend to "forget where they're at" and I'd recommend a different SSIS instance so that Dev and Prod DON'T share the same instance to help deter the eventuality of "Damn! I didn't know I was pointed to Prod".
--Jeff Moden
Change is inevitable... Change for the better is not.
February 21, 2018 at 11:16 am
Jeff Moden - Wednesday, February 21, 2018 10:55 AMquinn.jay - Wednesday, February 21, 2018 9:28 AMIn this one box setup I have, if I added one more DB for Dev instance, and one more Tab SSAS instance, and used project level connection manager and the existing SSIS instance with a new added folder for the dev packages, then I would not need to create another SSIS instance, i would only need to use the one, correct?Sounds dangerous. People tend to "forget where they're at" and I'd recommend a different SSIS instance so that Dev and Prod DON'T share the same instance to help deter the eventuality of "Damn! I didn't know I was pointed to Prod".
Thank you, good point, it's going to be complicated enough, may as well not add to change of error, though we use TFS, backout a incorrect push is not fun
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply