December 9, 2008 at 11:05 am
In our instance, We do not keep Physical DB. It is kind of difficult to maintain since ours is Inhouse development and every week some Changes are made. Either new Stored Proc or Modifying.
-Roy
December 9, 2008 at 12:24 pm
kanejeeves (12/9/2008)
Matt Miller (12/9/2008)
We have 4 code branches in TFS (DEV/QA/MO/MAIN), which match up to 4 physical environments.What do you do with different releases then? For ex, TFS/DEV/Release1, TFS/DEV/Release2 etc. Do you have corresponding physical environments (or sql dbs within a server) for each release, for ex. SQLSvr1/DB_Release1/TableA, SQLSvr1/DB_Release2/TableA and so on?
You might need to.
This is where your branching strategy is adapted to how your SDLC is set up. In our case - we're building internal products, so we're not maintaining multiple production versions of code. Once it gets promoted through QA and MO - production code gets deployed to all instances in one cycle.
We then keep *read-only* snapshot branches of "Main" immediately prior to deploying the new code to it.
As to how to develop your branching strategy - it's important to work on finding one that works FOR YOU. There are actually some very good articles on Branching and Merging strategies on MSDN.Microsoft.com that can help you come up with what you need to do.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 9, 2008 at 8:32 pm
That was a half thought not fully finished. There are a LOT of times when you can have a full environment wiothout having to have a full copy of the data. As a matter of fact - if you use the data generation wizard (in DBPro) - you should be able to design a fairly small data set that covers all of your scenarios, leaving you only to need a "full set" when you need to perf tune/perf check your code. So - a LOT of the environments can be virtual, with maybe one or two "test" physical environments.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 9, 2008 at 9:38 pm
I've always been wary of automatic merging, worried that changes in logic might not trickle down well. However the manual review probably negates most of my concerns.
My guess is that things have really improved in VCS over the last decade.
December 10, 2008 at 5:22 am
We use Surround. it has its own issues, But still it is usable. Serves our needs.
-Roy
December 10, 2008 at 9:16 am
kanejeeves (12/9/2008)
Matt Miller (12/9/2008)
We have 4 code branches in TFS (DEV/QA/MO/MAIN), which match up to 4 physical environments.What do you do with different releases then? For ex, TFS/DEV/Release1, TFS/DEV/Release2 etc. Do you have corresponding physical environments (or sql dbs within a server) for each release, for ex. SQLSvr1/DB_Release1/TableA, SQLSvr1/DB_Release2/TableA and so on?
A database is essentially a compilation of all of the scripts that built it plus the data. That said, is it the schema that you want in Source Control or do you want to include the data? My point is simply that if the scripts that make up the database are in Source Control under different folders (branches?), then the database version is retained by the compilation of the scripts that make up the database. If you are making changes to a production database with scripts that have been thoroughly tested in your development environment, then that script is now a static record of the current schema and you have effectively retained your database (sans data) in Source Control.
It is true that this method creates some manual updating between your maintenance of production and your development efforts, but I know of no other way. I suppose that is more a testament of my ignorance, but perhaps you can glean some ideas from my ramblings. 🙂
Keep us posted.
----------------------------------------------------------------------------
"No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw
December 10, 2008 at 9:21 am
I think the nomenclature here is confusing people.
The database is the schema+data+physical files. You wouldn't put this into VCS. You would put in the scripts to recreate the schema and objects. You might include some scripts to recreate some data (initial population), but you wouldn't VCS the data.
That's a backup.
December 10, 2008 at 9:34 am
Steve Jones - Editor (12/10/2008)
I think the nomenclature here is confusing people.The database is the schema+data+physical files. You wouldn't put this into VCS. You would put in the scripts to recreate the schema and objects. You might include some scripts to recreate some data (initial population), but you wouldn't VCS the data.
That's a backup.
Exactly my point, Steve. Unless I have missed the mark, I believe the original question is asking specifically if you VCS the database (which would include data). The schema and the physical files are a result of running the scripts to create the database originally.
Sorry if I have created confusion.:cool:
----------------------------------------------------------------------------
"No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw
December 10, 2008 at 11:10 am
Dcarlson (12/10/2008)
Steve Jones - Editor (12/10/2008)
I think the nomenclature here is confusing people.The database is the schema+data+physical files. You wouldn't put this into VCS. You would put in the scripts to recreate the schema and objects. You might include some scripts to recreate some data (initial population), but you wouldn't VCS the data.
That's a backup.
Exactly my point, Steve. Unless I have missed the mark, I believe the original question is asking specifically if you VCS the database (which would include data). The schema and the physical files are a result of running the scripts to create the database originally.
Sorry if I have created confusion.:cool:
Good discussion btw. My original question wasn't about putting sql scripts into a VCS, and not about putting the physical db into VCS (which would be a backup really). It was about how folks go about establishing the physical dbs in a test environment to match the versions of scripts in VCS, specifically when you have to support multiple versions of the application that uses the dbs. Sounds like most people maintain versions of scripts, but only a single physical db for testing. And that seems like an accident waiting to happen.
December 10, 2008 at 11:52 am
kanejeeves (12/10/2008)
Good discussion btw. My original question wasn't about putting sql scripts into a VCS, and not about putting the physical db into VCS (which would be a backup really). It was about how folks go about establishing the physical dbs in a test environment to match the versions of scripts in VCS, specifically when you have to support multiple versions of the application that uses the dbs. Sounds like most people maintain versions of scripts, but only a single physical db for testing. And that seems like an accident waiting to happen.
We use a three stage system. We will have a development database, a staging database, and a production database. The development database is where all, shall we say, uh, development (:Whistling: hoo boy) occurs. Staging is where testing occurs (user testing) and current modifications to production are implemented and tested. Lastly, production... well, you get the idea.
----------------------------------------------------------------------------
"No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw
December 10, 2008 at 12:01 pm
In our env as well it is usually three stage but if I am lucky, the scripts go through 4 stages. Development, Pre-deployment (Where deployment is tested with Merging of Code base), QA and then the production.
-Roy
December 10, 2008 at 12:06 pm
kanejeeves (12/10/2008)
Dcarlson (12/10/2008)
Steve Jones - Editor (12/10/2008)
I think the nomenclature here is confusing people.The database is the schema+data+physical files. You wouldn't put this into VCS. You would put in the scripts to recreate the schema and objects. You might include some scripts to recreate some data (initial population), but you wouldn't VCS the data.
That's a backup.
Exactly my point, Steve. Unless I have missed the mark, I believe the original question is asking specifically if you VCS the database (which would include data). The schema and the physical files are a result of running the scripts to create the database originally.
Sorry if I have created confusion.:cool:
Good discussion btw. My original question wasn't about putting sql scripts into a VCS, and not about putting the physical db into VCS (which would be a backup really). It was about how folks go about establishing the physical dbs in a test environment to match the versions of scripts in VCS, specifically when you have to support multiple versions of the application that uses the dbs. Sounds like most people maintain versions of scripts, but only a single physical db for testing. And that seems like an accident waiting to happen.
The majority of our last tier testing happens against something we call "nightly", which is a restored copy of yesterday's production environment. The last tier is when we try to run all tests one last time and some perfc testing as well. Literally - after the restore puts all of the data from yesterday into play, we apply all of the code pending deployment to it and start firing away with our tests. a lot of the deployment is automated, but a fair amount of the testing is semi-manual (test scripts built, but fired by hand).
We use one single instance for all of the changes, since they all have to be able to work together, correctly, once deployed.
Most of the other testing (QA) is run against limited sets of the data (on a different physical instance), which get refreshed less often.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
December 10, 2008 at 1:37 pm
Dcarlson (12/10/2008)
We use a three stage system. We will have a development database, a staging database, and a production database. The development database is where all, shall we say, uh, development (:Whistling: hoo boy) occurs. Staging is where testing occurs (user testing) and current modifications to production are implemented and tested. Lastly, production... well, you get the idea.
I must not be explaining myself correctly. I'm talking about within a single server, what do you do to support multiple releases? We too have 3 servers, Dev/Stage/Prod. But we have multiple versions of our web app. So we might have users testing V2 of the app on our Stage server, say in a db named ABC. At the very same time, we get a bug fix for a SPROC for V1 that needs testing on that same Stage server before releasing to Prod. Do I create another db on Stage called, say, ABC_FIX, so another group of users can user test the V1 Fix while others continue to test V2? I can't apply the script that fixes the SPROC in the V1 db because that would overwrite the SPROC being used in the user testing going on for V2. (Of course eventually I'll have to update SPROC in V2, but not until it's fully tested, etc. And SPROC is just for example. In reality the fix might include several SPROCs, a table change, etc.)
December 10, 2008 at 2:59 pm
kanejeeves (12/10/2008)
I must not be explaining myself correctly. I'm talking about within a single server, what do you do to support multiple releases? We too have 3 servers, Dev/Stage/Prod. But we have multiple versions of our web app. So we might have users testing V2 of the app on our Stage server, say in a db named ABC. At the very same time, we get a bug fix for a SPROC for V1 that needs testing on that same Stage server before releasing to Prod. Do I create another db on Stage called, say, ABC_FIX, so another group of users can user test the V1 Fix while others continue to test V2? I can't apply the script that fixes the SPROC in the V1 db because that would overwrite the SPROC being used in the user testing going on for V2. (Of course eventually I'll have to update SPROC in V2, but not until it's fully tested, etc. And SPROC is just for example. In reality the fix might include several SPROCs, a table change, etc.)
You are explaining yourself just fine, I'm just doing a poor job of answering you.:blush:
I do think your process is a little more involved than what I am dealing with, but that aside, if this is a constant issue, could you implement a separate instance on your staging (and/or development) server(s) to handle version separation? If that is not feasible, then I suppose that your idea of creating another db (i.e. ABC_FIX or ABC_v1_Fix) would realistically accomplish the same thing.
I must confess that this is a little beyond my limited expertise. I'm just trying to help with generating some ideas. Sorry I don't have better answers. 🙂
----------------------------------------------------------------------------
"No question is so difficult to answer as that to which the answer is obvious." - George Bernard Shaw
December 10, 2008 at 10:56 pm
[font="Verdana"]
kanejeeves (12/10/2008)
I must not be explaining myself correctly. I'm talking about within a single server, what do you do to support multiple releases? We too have 3 servers, Dev/Stage/Prod. But we have multiple versions of our web app. So we might have users testing V2 of the app on our Stage server, say in a db named ABC. At the very same time, we get a bug fix for a SPROC for V1 that needs testing on that same Stage server before releasing to Prod. Do I create another db on Stage called, say, ABC_FIX, so another group of users can user test the V1 Fix while others continue to test V2? I can't apply the script that fixes the SPROC in the V1 db because that would overwrite the SPROC being used in the user testing going on for V2. (Of course eventually I'll have to update SPROC in V2, but not until it's fully tested, etc. And SPROC is just for example. In reality the fix might include several SPROCs, a table change, etc.)
Let's say you have on production version1 of your app running (PRD_VER1). You have testing going on in your Staging box for version2 (STG_VER2). Now, someone found a bug in a SPROC or an object in the database in production. Your question is, how do I test and release a fix for this bug without disturbing the testing going on for version2?
Production Server
PRD_VER1
Staging Server
STG_VER2
Now, to test the fix for the bug found on the production version1 you have to create a new database in staging called STG_VER1. Reason being, you don't know what else it is going to affect in Version2 test database.
While testing for bugfix(es), you have the following scenario:
Production Server
PRD_VER1
Staging Server
STG_VER2
STG_VER1_BugFix1
STG_VER1_BugFix2
Notes:
----All bugfixes for the same version need to be merged and tested pre-release.
----Once all the bugs for version 'x' have been fixed. These changes have to be merged and tested for version 'x+1' pre-release.
Now, at all times you should have only one version running in production. That is the whole point of having a version number.
Version1, has passed UserAcceptanceTesting and is ready for production. Now, once you fix the bugs found in Ver1 you release a subversion. So, now your production becomes Ver1.0.1 or Ver1.1 depending on wether the bug fixed was a minor one or a major one.
You can have multiple tests being conducted in staging but, only one production.
I hope, I answered the question. HTH 🙂
[/font]
Viewing 15 posts - 16 through 30 (of 30 total)
You must be logged in to reply to this topic. Login to reply