Database App Deployment - (Newbie) [modified]
-
If I am writing a DB app, I am going to have several parts to keep track of. Some are: SQL setup files C# code other misc files Now if I change my c# files so that it requires new SQL setup files, I have to manage the change in 2 places. What is the best way to implement deployment while at the same time keeping DB/app versions in sync when revising code? I don't even know what to call this concept to google it. I guess this leads to the question "What are people who are using c# using for a CVS?" The next situation would be if the end user was going from a previously installed v1 to v2 with different table structure. Are there design patterns for an updater? Any info is appreciated. Cheers, WT
modified on Friday, January 11, 2008 11:32:17 AM
-
If I am writing a DB app, I am going to have several parts to keep track of. Some are: SQL setup files C# code other misc files Now if I change my c# files so that it requires new SQL setup files, I have to manage the change in 2 places. What is the best way to implement deployment while at the same time keeping DB/app versions in sync when revising code? I don't even know what to call this concept to google it. I guess this leads to the question "What are people who are using c# using for a CVS?" The next situation would be if the end user was going from a previously installed v1 to v2 with different table structure. Are there design patterns for an updater? Any info is appreciated. Cheers, WT
modified on Friday, January 11, 2008 11:32:17 AM
Hello WT, The situation you are describing is a very common situation in development. We all go through managing the changes to code and consolidation of these changes. Here is a suggestion if you are referring to source control for developers: For application code (C#), use a source control system. In my organization, I set up to use Microsoft Team Foundation Server. Basically, its pretty cool in that when developers make changes in the C# code, then the changes are automatically checked out and then they can check things in. Other source control systems you can use can be Visual SourceSafe. Or you can go with a open source solution such as: SubVersion. Now for SQL scripts(I assume that is what you mean). There are a few solutions out there which are add-ons to SQL 2005 to handle source control. As far as deploying new SQL changes (which seems to be the core problem) to futher environments. You can use a SQL examiner tool which would do a compare between DB1 and DB2 and then allow you to create a "change script". I use SQL Examiner: <a href="http://www.sqlaccessories.com/SQL\_Examiner/"> </a>[<a href="http://www.sqlaccessories.com/SQL\_Examiner/" target="_blank" title="New Window">^</a>] I hope above is helpful for you.
Arsen
-
Hello WT, The situation you are describing is a very common situation in development. We all go through managing the changes to code and consolidation of these changes. Here is a suggestion if you are referring to source control for developers: For application code (C#), use a source control system. In my organization, I set up to use Microsoft Team Foundation Server. Basically, its pretty cool in that when developers make changes in the C# code, then the changes are automatically checked out and then they can check things in. Other source control systems you can use can be Visual SourceSafe. Or you can go with a open source solution such as: SubVersion. Now for SQL scripts(I assume that is what you mean). There are a few solutions out there which are add-ons to SQL 2005 to handle source control. As far as deploying new SQL changes (which seems to be the core problem) to futher environments. You can use a SQL examiner tool which would do a compare between DB1 and DB2 and then allow you to create a "change script". I use SQL Examiner: <a href="http://www.sqlaccessories.com/SQL\_Examiner/"> </a>[<a href="http://www.sqlaccessories.com/SQL\_Examiner/" target="_blank" title="New Window">^</a>] I hope above is helpful for you.
Arsen
-
If I am writing a DB app, I am going to have several parts to keep track of. Some are: SQL setup files C# code other misc files Now if I change my c# files so that it requires new SQL setup files, I have to manage the change in 2 places. What is the best way to implement deployment while at the same time keeping DB/app versions in sync when revising code? I don't even know what to call this concept to google it. I guess this leads to the question "What are people who are using c# using for a CVS?" The next situation would be if the end user was going from a previously installed v1 to v2 with different table structure. Are there design patterns for an updater? Any info is appreciated. Cheers, WT
modified on Friday, January 11, 2008 11:32:17 AM
wjtaylor wrote:
from a previously installed v1 to v2 with different table structure. Are there design patterns for an updater?
Have you ever been to any Patterns sits like Portland Pattern Repository or the Hillside Group[^] Note: Hillside has a link to Portland Pattern Repository. Data migration issues might prove to be the most difficult aspect of all your problems depending on the types of schema changes and data dependencies you are introducing.