For some time now I have been using MSBuild exclusively for deploying data warehouse applications. Because the deployment process is often time-consuming and can touch many components and elements of a data warehouse, using MSBuild is a smart choice.
Consider an integration project that contains a dozen SSIS (dts) packages, some reports (rdl files), a few C# assemblies, an ASP.NET interface, schema changes, new database functions, new user roles, expanded constraints, and updated stored procedures. Now expand this deployment across development, quality, and production environments. Introduce deltas (incremental updates of varying components) and you can begin to understand why some companies pay two or more people just to deploy applications.
But not here. MSBuild (and other similar build/deploy projects like Apache ANT or GNU MAKE) is an excellent solution to the problem. With some planning up front, and a little… ehem… trial and error, you can simplify the entire deployment process so much it will make your head spin.
MSBuild not only builds .NET projects (like C#.NET and VB.NET), but it can also run any number of additional “tasks”, such as:
- Create directories and log files
- Do a VSS Get by Label
- Compile a FoxPro project (see Rick Borup’s article in Advisor: “Automate Microsoft Visual FoxPro“)
- Compare directory contents
- Upload SSIS packages
- Run test scripts
- Execute stored procedures
- Etc…
I think you get the idea. There is not a single task MSBuild cannot wrap (at least nothing that I’ve come across). And with its ability to handle dependencies, talk with source control, and run homegrown assemblies, the limit is only limited to your needs and imagination.
I am starting to sound like a commercial, I know.
But the point is simple: The deployment of a large or ‘heavy’ project needs special attention, planning, and resource allocation. Using MSBuild (or ANT, or MAKE, etc.) can alleviate the burden on developers and DBAs and provide consistent and predictable build and deployment scenarios.
I will share some additional insights and lessons learned on using MSBuild over the next few weeks, especially details on how to deploy multi-pronged projects for different environments. I will also try to share some tips on how to handle delta deployment scenarios. In the meantime, if you are new to MSBuild, take a look at the MSBuild Team Blog and the MSBuild Wiki.
As a side note, I have never used MSBuild for deploying VFP applications in the past. This is all about to change…
#1 by Alan Stevens at October 25th, 2007
| Quote
Hi Tod,
Have you looked at the VFPX MSBUILD code I posted? It is not a working implementation, yet, but it should point the way. I’d love to hear your input. Please take a look here:
http://www.codeplex.com/VFPX/SourceControl/DirectoryView.aspx?SourcePath=%24%2fVFPX%2fVfpMsBuildTarget&changeSetId=27384
Cheers,
++Alan
#2 by Tod McKenna at October 26th, 2007
| Quote
Hi Alan!
I had a look at this a while back, and made a mental note (dangerous, I know) to revisit it when I was ready to build VFP projects.
I am going to take this and include it (”as is” for the moment) in my environment and see what happens. The code looks great, though so I’m optimistic. I will be sure to report back my findings.
In addition, I have a need to write an assembly that packs or zaps a table. When complete, perhaps it can be added on CodePlex as well.
#3 by apaustria at October 30th, 2007
| Quote
sweet! can’t wait for the vfp stuff!