Improve deployment process of Asp.net applications by generating database change scripts using Visual Studio 2010
Introduction
Database
deployment is perhaps the most important part of any Asp.net
application deployment, and, if the database deployment is smoothly
done, there is a chance that the overall application deployment is done
smoothly.
Most Asp.net application deployment is usually carried out in following process
 |
| Figure : Deployment process of Asp.net applications |
Development Site
This is where the developers deploy their individual tasks for QA testing and fixing bugs.
Staging Site
This
is where the overall application is deployed and the QA team performs
production testing, once all individual tasks are passed on Development
site.
Production Site
This is where the overall application is deployed once all testing on Staging site is passed.
The deployment process
Usually,
source codes are maintained using a version control system (Say, SVN),
and, when a deployment is required, the overall codes (From the
corresponding branch) are checked out and built using a build management
script (Say, NANT). Once build is successful, the binaries and other
files are deployed on target server.
The
corresponding database changes are also usually maintained as
individual database script files within the version control system, and
the build management system executes those scripts to make necessary
database changes on the target database, to make sure that the database
conforms to the current version of the codebase. The database change
scripts include the all database related changes such as
Creation/Modification of Tables/Stored
Procedures/Views/Functions/Triggers and other necessary database
objects.
If
everything goes right, the deployment proceeds very smoothly. However,
experience shows that, even if all tasks are passed on Development site,
once staging deployment is done, BUGs are found and reported from the
staging site (Even if the same BUG doesn't exist in Development site).
Most of the cases the reason is found to be a database deployment issue.
For this reason, the staging deployment is often found to be time
consuming and problematic.
Why this happens?
Usually,
in Development site, developers deploy their database and code related
changes incrementally. That is, each developer deploys codes and the
corresponding database change scripts individually. They also commit
their corresponding database scripts within the source control. Now,
when staging deployment is to be done, a copy of the production database
is taken and copied at the Staging database server, and, the overall
database change script is run there at once to conform it to the latest
version of the codebase. That's where the main problem occurs.
Ideally,
the database change scripts should be perfectly maintained within the
source control so that whenever the scripts are run, the current version
of the database at production is immediately be upgraded to the latest
version, to conform it to the current source codes. But, unlike the
application's source codes, the database scripts cannot be built and
hence, it is hard to identify whether there is any missing database
script or there is any script maintained wrongly in the source control,
before the script is to be run at a target database.
So,
often there are situations where it takes hours or even days for a
developer to fix all the database script issues and ensure a complete
staging deployment.
How to improve the situation?
There could be two possible ways to improve this situation
Option1:
Ensure
a process to make sure that, no individual database change script is
run on Development database. Like the staging deployment, the overall
database scripts have to be run even if a single task has to be deployed
there.
Pros :
This will make sure that, before staging deployment, all corresponding
database scripts are correctly maintained in the source control, and
hence, staging deployment will likely be much quicker and smoother.
Cons :
Individual task deployment at staging site would take more time than
before (Because in order to deploy each little task, the overall build
process has to be run).
Option2
Use
some intelligent tool to generate the overall database change scripts
between the database at the development site and the production site,
and, run the database change script into staging database to conform it
to the current codebase. Also, maintain the change script in source
control.
Pros :
This
will not require running the overall build process to deploy a single
task on development site. Developers will just need to run their
individual database change scripts.
The database change scripts doesn't have to be maintained in source control, so, this will save some time at each task level.
The staging deployment will likely to be much more smooth.
Cons : No real cons :)
The next post is all about utilizing such an intelligent tool which is available right within your favorite Visual Studio 2010!
No comments :
Post a Comment