A while back a friend of mine posted a comment here asking me to describe what it's like developing with Commerce Server 2007. Initially I wanted to reply to him in comments but thinking more on it I really want to provide a different and real perspective on how Commerce Server is to work with as a product, a perspective in which I want to dig a deeper than the usual how-to and tutorials you see on the various Commerce Server blogs; mine included.
Check out part 1 Secure By Default where I discuss the security aspects of Commerce Server, part 2 Three-way Data Access in which I write about the various ways of getting data into your applications, part 3 Testability which not surprisingly is all about how CS lends itself to unit testing, part 4 Magic Strings Galore where I take on low level aspects of the APIs, and part 5 Pipelines where COM makes a guest appearance in our mini series.
When time comes to deploy your application we've got a number of options when it comes to custom apps crated purely on top of the .NET framework: Installers, xcopy deployment, automatic build processes, etc.. When it comes to Commerce Server the deployment procedure is a bit more involved but aspects of the deployment are supported by some interesting tools as we'll see in a minute.
Commerce Server comes with a handy tool for publishing your application in a single file called a PUP file. This works great the first time around and greatly simplifies first-time deployment unfortunately it only works for the initial deployment subsequent deployments are more involved because manual deployment is required unless you're fortunate enough to be working with the enterprise version.
Let's first deal with the manual deployment because that's frankly the most fun to write about :) Commerce Server is split across a number of different subsystems each running on top of a separate database. Each subsystem has different deployment requirements and steps that you'll need to follow. I won't bore you with the actual steps here just know that deploying a Commerce Server application requires a lot of steps and I do mean a lot involving a number of disparate tools.
Security requirements of authorization manager further complicates deployment because the business data is protected by an additional layer of security different from what's found at the system level. All this has to be created either manually or via a command line tool provided with the product.
One alleviating factor to the long list of manual deployment steps is the fact that Commerce Server is split across a number of different databases, one for each subsystem. You can isolate changes to each subsystem thus easing deployment by the fact that you can deal a subset of your Commerce Server application at a time.
It becomes really interesting when we start talking about the enterprise version which brings another tool to the table which will automate deployment of most of your application: Commerce Server Staging (CSS). The staging tool allows you to move business data and files from one server to the next. this means that you can enforce pretty much and hands off policy on your production server and only have your business users work in a staging environment for creating and testing purposes.
The only caveat to staging is that it doesn't support profiles, you can however use a more crude approach to deploying your profiles automatically. Notice that I wrote business data and files. You can basically have CSS move binary files to production and have it execute a command pre and post transfer which could be a bat file, a custom executable which essentially makes CSS a very unique and useful tool not just in conjunction with Commerce Server.
Just think about what can be done with a tool like CSS with a regular old ASP.NET app. You could basically have CSS move your compiled ASP.NET app and SQL script to production, have it move the assemblies in place, and finally execute your SQL scripts. Voila automatic deployment, only downside is that you need an enterprise version of Commerce Server around :) I really think that Cactus should look into making this a standalone tool.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.