CODEWITHSUNDEEP
asp.netsql-serverdatabasedeployment
This is it
This is it

Reputation: 789

Good way to make changes to production database / source code

I'm interested to find out what would be the good way to make changes to production database and source code in web application (ASP.NET, SQL Server 2008).

A little bit more details, we develop on local machines, and then we need to transfer the code and database changes to production (pretty much standard story).

At the moment we do it in the evening, change the database directly from management studio on production server, and then just overwrite the existing asp.net code (copy/past).

Upvotes: 0

Views: 1975

Answers (2)

Lord Tydus
Lord Tydus

Reputation: 544

Depends on whether it's the first deployment of a new app, or an update to the app.

For small updates, record all your database changes as sql scripts. You must strictly enforce that all changes to development are applied as sql scripts. Put the scripts in source control. Deploy the update by running the scripts on production.

For new apps you may have thousands of scripts. You can't run them individually. Consolidating them into a master script takes too much time. (although you still want to check EVERY script into source control). In this case you reach a milestone in development then FREEZE the development database, and declare it a baseline. Use the database tools to generate a master script(s). Deploy production by running this script(s). Manually create data scripts for your lookup tables to keep it separate from junk dev data.

Avoid a database copy. Avoid changing by hand through the GUI. Scripts are the way. How you go about collecting the scripts, consolidating to master scripts, generating the scripts, etc is another story.

Upvotes: 1

David
David

Reputation: 73554

You're talking about Release management. What you're asking about is a big subject with a LOT of different answers. The best solution for you is not something we can tell you. There are trade offs to consider.

For example, what you're describing is a very basic release management process that would be considered an "immature" process.... It does not take into account rollback plans, versioning, separation of concerns, proper testing, or any of a hundred other factors that a "mature" release management process involves.

A mature process is very good, but if you don't have the resources, it's not feasible.

To get to the point, I don't think you question can be answered fully here. I'd suggest starting to research "change management", "release management", "Application Lifecycle management", and "Applicaiton Development Lifecycle". I'll have a few good starter links for you in a minute.

Just a forewarning, though, you are asking a question that's going to open your eyes and your world in ways you probably haven't considered. There are things like automated builds to consider, tools to do it for you (high priced, free, and everything in between)

http://en.wikipedia.org/wiki/Release_management

http://en.wikipedia.org/wiki/Application_lifecycle_management

A few simple options for JUST what you're asking about can be found here: http://msdn.microsoft.com/en-us/library/7hd4c0x3(VS.80).aspx

Also, since you talked about source code without mentioning which source control you're using, I need to say... if you're not already using source control, you need to. You'll wonder how you ever lived without it once you start using it.

Upvotes: 1

Related Questions