I recently worked with a client to create a fairly comprehensive solution for implementing Continuous Integration and Delivery for SQL Server Databases using Visual Studio 2010 Database Projects.  I had the opportunity to give a talk on the project at SQL Saturday in Omaha.  The presentation is here if you want the slides.  I think there is some context missing with the slides alone so I wanted to do this post to further explain the solution.

Before talking about the solution, let me describe three different continuous processes.  Continuous Integration (CI) is most familiar and is often used to describe all three of these processes.  I think the differences between these three processes is more clear by using these terms.

Figure 1 – Continuous Processes

Continuous Integration – Verifying code quality by compiling and running unit tests on the build server when a developer checks in changes.  Often abbreviated as CI.

Continuous Delivery – Adds the deployment of the application and database to an isolated test environment where additional integrated and UI automated tests can be run. 

Continuous Deployment – Includes automated deployment of the application through each environment through production.

In this post I will primary review our solution for CI and Continuous Delivery.  This works lays the foundation for the deployment into Staging and Production but I will discuss this in a future post.

Database Projects

Database tools in the past have been different than the tools used application code development.  These database tools have been difficult to implement change management practices and Application Lifecycle Management (ALM) practices.  Today there is an increasingly amount of application developers managing database changes.   These are some of the reasons that have led to need for a tool like Visual Studio Database Projects (DBPro for short).  This tool is part of Visual Studio 2010 (Premium and higher).  To create a Visual Studio Database Project, select SQL Server from the process template menu and then choose SQL Server 2008 Wizard or SQL Server 2008 Database Project.

Figure 2 – SQL Server Database Project Templates in Visual Studio 2010

The primary purpose of the Database Projects are to manage the the version control of database objects in SQL Server databases. The solution we established utilizes this and many of the features of DBPro including TFS Build Integration, Data Generation, Database Unit Testing, Static Code Analysis, and Database and Data Deployments.  In this post I’m not going to cover how to use all of these features but focus on how to implement the features for Continuous Integration, Delivery and Deployment processes.  For more information, please take a look at the Visual Studio ALM Rangers Visual Studio Database Guide.  This solution is complimentary to the guide and goes into more more specifics for CI.

Figure 3 – Visual Studio Database Guide

Challenges

Visual Studio Database Projects are a great tool and I highly recommend teams utilize these for managing version control for the SQL Server Databases.  However, successfully using Database Projects can be challenging.  I believe the benefits greatly out weigh the challenges but it is important for the team to be aware of these for a successful implementation.

Visual Studio – Visual Studio probably seems like an odd challenge considering this is the tool to use for the solution, however Visual Studio is a beast.  Visual Studio has become everything development.  Developers are used to Visual Studio and I have seen DBAs and other database professions get frustrated using it when they first start.  Stay with it.  It will get easier and is the future direction of Microsoft in SQL Server 2012.  From what I have seen SQL Server Management Studio 2012 is based on Visual Studio.

“Truth Center” Shift – Development teams have been used to using a shared database server and making changes directly on server since the stone age.  Managing source control of the database in DBPro essentially changes the “truth center” of the database project to DBPro.  Changes to the schema should be made in DBPro and then executed or deployed from DBPro to the shared server.  Development can also be done in local sandbox called offline schema development where the developer can make the changes locally and check them in.  Changes made directly to the shared SQL Server database risk being overwritten by the next deployment from DBPro.

Permissions – I have found DBPro does a great job managing almost all of the artifacts for databases.  The biggest challenge and frustration has been permissions.  The problem is that the database project holds the specific version of the database.  For permissions this doesn’t work in most real world examples because permissions change in each environment.  For examples, developers need different permissions in development versus what they need in production.  In addition, many enterprises use a separate domain for each environment.  As shown in Figure 4 below, Database Roles for the most part are consistent between environments and primarily the users and their role membership in those roles will vary.  The best method I found for handling these permission differences is to exclude them altogether.  Use the following steps to handle permissions when importing the schema and adding new objects to the project.  One advantage of removing the users is that that they are normally connected to a login and the login lives outside of the database in the Master database.  Including the users and logins in the project requires an additional project called SQL Server Server Project that contains the Master database.  This solution does not require a SQL Server Server Project.

Figure 4 – Managing Permissions Across Environments

Importing Databases

When using the importing the schema and objects into your project, make sure you perform the following steps to first import all of the permissions and the remove those that will change in different events.

• Enable Import permissions in the Import Wizard to import all of the permissions including Roles, Users, and Role Membership.
• After Import has completed:
  • Role permissions are to be kept in the .sqlpermissions file.
  • Schema Users (without login) are to be kept.
  • The other users must be removed
    • from sqlpermissions
    • From Security\Users
    • From RoleMemberships

Adding New Objects

When adding new objects in the Database Project

• Use Schema View
• Manually modify the Properties\Database.sqlpermissions and add the new permission
  • EX: Grant Execute to Role for Stored Procedures EXECUTE TestRole

  <PermissionStatement Action="GRANT">
    <Permission>EXECUTE</Permission>
    <Grantee>TestRole</Grantee>
    <Object Name="spTestFromSSMS2" Schema="dbo" Type="OBJECT" />
    <Grantor>dbo</Grantor>
  </PermissionStatement>

Permission Scripts

By removing the permissions from the project, there needs to be a place to account for these.  This solution accomplishes this by creating a script in the Scripts folder for environment that essentially creates the logins, users, and assigns the role membership for each user.  This allows the flexibility to store any variations between the environments and still store these in the database project and in source control.  Do not set the Build Action to PostDeploy because you can only have one for each project and it will be combined with the Deployment script.   Instead set the “Copy to Output Directory” property on the script to “Copy Always”.  This will create an Scripts folder and the permission files in the build output directory so it can be called by the deployment scripts.

Source Control

The primary benefit for using the Database Projects is that all of the database changes can be managed in source control.  There are a lot of ways to organize your source control and with branching and merging this can become complex to manage.  I like to take a pragmatic approach to source control and keep things simple but allow for complexity if needed in the future.  The Visual Studio TFS Branching Build 2010 is a great reference for adopting branching and merging strategy.  For this post I want to simply show the relationships between Production, Development, and Work Orders.  The main points is that the database projects should be branched and merged along side the application source control with some sort of release branch that has the current production version.  The Work Order branch is for production support changes that will be made into production.  Development teams should do downward merges often to always have any work order changes incorporated early.  When the application and database changes are deployed to production, the development branch should be merged up to the Production branch.  The diagrams below show how this is organized from a logic view and physical view.

Logical View

Figure 5 – Logical View of the Database Project Source Control Branches

Physical view

Figure 6 – Physical View of the Database Project Source Control Branches

Continuous Integration (CI)

To setup the most basic CI process for your Database projects, you can simply add the Solutions containing the database projects to your CI build that is building your application code.  The benefit of this is that it will build your database projects and validate that there are no schema errors and can validate any static code analysis rules.

Continuous Delivery

For Continuous Delivery, we want to expand the process to include deploying the database, insert any test data we need, and then run the database unit tests.  This adds validation that the schema in source control can correctly build the database and that stored procedures can pass any number of validations with the unit tests.  These steps would look like the following:

Figure 7 – Simple Continuous Delivery Process

Visual Studio Database projects make implementing this process very simple and only requires a couple simple settings.  The dialog below shows the out of the box settings.  To open this dialog, select Test > Test Configuration from the menu.   The sections are slightly out of order.  To start we want to set the Deployment database project to the project we want to deploy.  Next choose the configuration.  The configuration settings in the database project will specify the target connection string and other deployment properties.  Next, the Database state setting will generate the test data for the unit tests by running one of the data generation plans.

Figure 8 – Database Test Settings

Types of Continuous Delivery

The example above basically deploys the current version of the schema to the target but doesn’t is not a good practice run into production.   It basically deploys the changes from the last deployment.  My goal of the Continuous Delivery process should be a practice run into production and essentially deploy the application and database the way it will be done for the production deployment.   There are two types of delivery based on whether or not the application is already in production.  For new systems that haven’t been deployed to production, the deployment will be to deploy all of the schema.  This is referred to as Greenfield.  For existing systems, the schema will the difference of what is currently in production with what has been developed.  This is referred to as Brownfield deployments.

From a Visual Studio Database Project standpoint, Greenfield deployments are a simple using the deploy option.  This will drop the database and execute the full schema script to create the database.

Figure 9 – Greenfield Process

For Brownfield deployments in Visual Studio Database Projects, the process is accomplished in two steps using Production and Development versions of the database projects.  The first step is to use the Production version of the Database Project to create the full CREATE script.  Next, use the compare feature to compare the Production and Development versions to create the DELTA script.  Again, the key is not to compare the development against the live production database but to use the version of the Database Project that was created either from the production database or from the Release branch in source control.  Once you have these two database scripts, run the CREATE script to drop the database and create the database to the production level.  Then execute DELTA script to bring it to the current development level.  From there you can follow the similar steps to execute the data generation plan and automated tests to complete.  See below to see how this fits together

Figure 10 – Brownfield Process

Putting this all together, here are the steps in order for a good SQL Server database Continuous Delivery process.  There is some customization that has to be done for this.  The database testing options that were available for the simple process, won’t work out of the box for this solution.  This is because the Database Project doesn’t know about the production and delta scripts.  The build by default would create the database and run the data generation plan before unit tests including the database unit tests.  However, the unit tests are run immediately after the application is built and we need to specify the a step to build create the scripts and then execute them.  I customized the build definition by moving the unit test execution activities to later in the process so I could execute the SQL scripts before the Unit Tests are run.  Once this was moved, I could use the built in features to run the data generation plan.  Below are the steps for the full end to end Database Continuous Delivery process.

Figure 11 – End to End Database Continuous Delivery Process

To combine this process into the application continuous delivery process, the same tasks above can executed along with the application steps.  This process is grouped into three groups: Build/Stage, Deploy, and Execute Automated Tests.  The process is outlined below.

Figure 12 – End to End Application and Database Continuous Delivery Process

VSDBCMD

One of the great features of Visual Studio Database Projects is that the deployment and compare functionality can be executed via a command line utility called VSDBCMD.exe.  This allows us to perform the necessary steps in our Continuous Delivery process.  I utilize a InvokeProcess Activity in the build definition to call a PowerShell script to execute the VSDBCMD commands.  Below are examples of how to create the Production CREATE script and the DELTA script.  The Production Script creates the full CREATE script from the compiled Production version of the Database Project.  The DELTA command shows how to compare two Database Projects to generate the DELTA SQL Script.

Create Production Script

& "C:\program files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Deploy\vsdbcmd.exe" 

/a:deploy /dsp:sql /model:Ecommerce.dbschema /DeploymentScriptFile:c:\temp\OutputFilename2.sql 

/p:TargetDatabase="NewEcommerce"

Create Production and Development Delta Script

& "C:\program files (x86)\Microsoft Visual Studio 10.0\VSTSDB\Deploy\vsdbcmd.exe" 

/a:deploy /dsp:sql /model:Ecommerce.dbschema /DeploymentScriptFile:c:\temp\OutputFilename2.sql 

/targetmodelfile:"C:\tfs\deliveron\Production\EcommerceSolution\Ecommerce\obj\Debug\ecommerce.dbschema" 

/p:TargetDatabase="NewEcommerce"

In Summary

This concludes the overview of the solution for Continuous Integration and Delivery for SQL Server Databases.  I hope it gives you a complete overview for creating your own Continuous Delivery process.  Feel free to contact me if you have any questions or comments.

Review of Key Concepts

• There are three types of Continuous processes: Integration, Delivery, and Deployment.
• Continuous Delivery should be set up to be a practice run for Production.
• Create compare scripts between development and production database projects and don’t compare against live databases.
• VSDBCMD is a command line utility that perform the deployment and compare functionality in Visual Studio Database Projects.

This was also cross posted at http://www.deliveron.com/blog/post/Implementing-Continuous-Integration-(CI)-and-Delivery-for-SQL-Server-Databases.aspx

PowerShell is an awesome technology.  It has become an essential tool for doing automated deployments with Team Foundation Server 2010.  Creating deployment scripts in PowerShell are very easy to manage and maintain by the entire development without having to know about the details of the build definitions.  In future posts, I will explain how I use the build definitions and PowerShell to perform the deployments.  With this post I wanted to share a small tip on being able to catch all errors with a Try, Catch.

In PowerShell, there are two types of errors. Terminating errors and non-terminating errors.  Terminating errors will automatically be caught in a Try, Catch block but non-terminating errors will not.  Look at this example below.

try
{
    copy-item "c:\notexists\file.txt" "c:\temp"
}
catch {

write-host "bad copy"

}

This command looks like it should write to the out the error message because the folder and file do not exists. However when you run this, it will only display the PowerShell error message. 

Copy-Item : Cannot find path 'C:\notexists\file.txt' because it does not exist.
At C:\temp\copyitem.ps1:3 char:14
+     copy-item <<<<  "c:\notexists\file.txt" "c:\temp"
    + CategoryInfo          : ObjectNotFound: (C:\notexists\file.txt:String) [Copy-Item], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand

This is an example of a non-terminating error.  There are two ways to fix this.  The –ErrorAction ”Stop” flag can be added to many of cmdlets. 

copy-item "c:\notexists\file.txt" "c:\temp" -ErrorAction "Stop"

Now, when the script is run, it will display the error message, “bad copy”.

This is great but if you are like me, you don’t want to have to add this to every command.   Luckily there is a way to do this for the entire script.  At the beginning of the script, you can set $ErrorActionPreference = “Stop”.  If you want to be able to toggle it, it default setting is “Continue”.

$ErrorActionPreference = "Stop"

Here is the final script.  Enjoy!

$ErrorActionPreference = "Stop"

try
{
    copy-item "c:\notexists\file.txt" "c:\temp"
}
catch {

write-host "bad copy"

}

The Visual Studio ALM Rangers just released two projects, the Build Customization Guide and the Lab Management Guide.  Both projects provide real world, in-depth guidance and hands-on-labs (HOL) for planning and creating solutions for utilizing the Team Build 2010 and Visual Studio 2010 Lab Management.  Every development team should utilize the features covered in these guides for creating a build strategy that includes Continuous Integration (CI), packaging and versioning of applications, and automated deployments to at least the development and test environments. By utilizing Visual Studio Lab Management, these environments can be quickly provisioned and managed by those development teams.  They will be able to do things restore to a baseline before building, deploying, and running tests in those environments, clone the environment to provide multiple test environments for QA, and attaching a snapshot of the virtual environment along with other rich information to bugs for the developers.

Visit the websites for all of the details and downloads for the guidance.

Build Customization Guide

I am especially excited about the Build Customization Guide being released because this was first Visual Studio Ranger project I have had worked on.  I had the opportunity to work with many talented and dedicated individuals.

The Epics included in this guidance are:

• Practical guidance and tooling to simplify the customization of Team Foundation Build
• Practical guidance to use Team Foundation Build process templates to automate build and non-build scenarios in Microsoft environments
• Practical guidance to enable simple and flexible deployment of applications and their data stores
• Practical guidance for Activities to empower developers and build engineers
• Quality hands-on labs that complement the guidance and effectively guide the user through the features
• Visualization of the guidance using quick reference posters

http://rabcg.codeplex.com/

Lab Management Guide

I didn’t contribute to the Lab Management Guide, but I have read through the guidance.  It includes a lot of great information that include planning Lab Management, setting up the Virtual Lab environment, and creating Virtual Machines using the VM Factory.

The Epics included in this guidance are:

• Visualization of the guidance using quick reference posters
• Advanced golden image management using the VM Factory for Lab Management
• Provide guidance on setting up Test environments with respect to pre-defined personas
• Provide Guidance to enable large and small teams to setup and configure both automated and manual tests
• Provide practical guidance for managing and maintaining a Lab Management environment
• Provide practical guidance to enable teams to quickly setup and configure their lab management environment

http://ralabman.codeplex.com/

Visual Studio ALM Rangers

So who are the the Visual Studio ALM Rangers?  They are a group of internal Microsoft employees and external communities leaders/MVPs who’s mission is to accelerate the adoption of Visual Studio with out-of-band solutions for missing features and guidance.  Willy-P. Schaub has posted some great information about who we are, the past accomplishments, and future plan in the Visual Studio ALM Rangers 5 year Report.

Please contact us at tfs@deliveron.com for information on these guides or implementing these solutions in your environment.

Mike

Team Deploy 2010 is a custom add-on for Team Foundation Server 2010 (TFS) to deploy MSIs to servers and PCs.  The deploy activity uses an XML file to manage the servers and steps for deployment including starting/stopping services and installing/uninstalling the MSIs.  This is very effective for automated deployments in environments where automated deployments are allowed.  This however does not provide a practice run into downstream environments where automated deployments are not allowed such as Staging/Integration and Production.

An alternative to this that does offer some deployment consistencies beyond the MSI is to have Team Deploy 2010 (or Team Deploy for TFS 2008 also supports this) execute a PowerShell script to perform the deployment steps.  The advantage of this is that the PowerShell scripts can also be used to perform the manual deployments to these other environments.  This won’t work in every scenario but should in a lot.  In this post, I am going to explain how to do this.

The first thing to do is to install Team Deploy 2010.  This is free and can be downloaded at http://TeamDeploy.CodePlex.com.  The installation instructions are detailed on the site.  For this, I will assume Team Deploy 2010 is already installed.

Next open Visual Studio 2010 and create a new build definition workflow.  Create 3 arguments called RemoteExecuteFilename, TargetMachine, and RemoteCommand.

Instead of using the Deploy activity, add the RemoteExecute activity in an AgentScope container.

Set the properties on the RemoteExecute activity to the arguments passed in.

Next, set the properties that were exposed as arguments of the build definition.  For the RemoteCommand, here is where you want to specify calling PowerShell.exe and the script file that will be executed on the target machine.  One thing I have learned after taking this snapshot is that if you have a space in the path for the script than use this syntax:

PowerShell.exe –File “\\buildserver\deploy scripts\Update.ps1”

Next specify the path where the PSTools were installed and finally specify the machine that you want to run the remote script.

The final step is to create the deployment script.  Thanks to the power of PowerShell, these deployment scripts can perform any action.  I have created steps for starting/stoping services, applying SQL Server schema changes, search and replace strings in configuration files, etc. Essentially anything you can do in a batch file and in .NET code, can be done in PowerShell.

Here is a small sample script that I created.  I have creates some much more complicated scripts and ran them on remote machines without any issues.

"Performing removal steps..."

$servicename = "PLA"
$service = Get-Service $servicename
if($service.Status -eq "Running")
{
    "Stopping " + $servicename
    Stop-Service $servicename
}
"status=" + $service.Status
Remove-Item "c:\miketest2"
msiexec /qn /x "{26260DBA-1519-4967-9118-D827793EF3B3}"

"Removal complete.  Starting the installation steps..."

msiexec /qb! /i "\\buildserver\deploy\simple.msi"
New-Item "c:\miketest2" -type directory

"Applying SQL Server Schema changes..."
sqlcmd -S W2K8R2BOOT -E -i \\buildserver\deploy\dropaddcooltable.sql

if($service.Status -eq "Stopped")
{
    "Starting " + $servicename
    Start-Service $servicename
}

This is it. Here are also a couple things to consider. Copy MSIs, SQL Scripts, and the deployment script to a versioned folder.  The folder is the snapshot in time including the deployment file.  Keep the deployment scripts in source control.  Lastly there is a new feature in PowerShell 2.0 called PowerShell Remoting.  I have tried it, but it looks like this could also work.  It is on my list to research and I will be sure to report back when I find out more information.

Enjoy!

Mike

This was cross posted at http://www.deliveron.com/blog/post/Executing-PowerShell-Scripts-on-Remote-Machines-with-TFS-2010-and-Team-Deploy-2010.aspx on the Deliveron’s blog at http://www.deliveron.com/blog.

Development teams utilizing Coded UI Tests have several options where to run Coded UI Tests.  When a developer creates an automated test either from an existing action recording or using the Coded UI Test Builder, the test can be run within Visual Studio 2010 just like a unit test.  Once the Coded UI test is passing, it can be associated with a Test Case and/or run as part of the build along with the unit tests.  I will cover associating a Coded UI Test to a Test Case and running the automated test within Microsoft Test Manager in a future post.  In this post I will cover configuring the build server to run Coded UI Tests.  While this post describes configuring the build server to run the Coded UI Tests, any machine configured as a test agent can be utilized by the build server and build to run the Coded UI Tests.

The primary difference between running the Coded UI Test on the build server than a unit test is that the test requires full access to the UI.  Having the build server require full access to the UI introduces a couple challenges including a couple additional requirements.  First, the build server requires the application to be installed on the build server the same way it was installed when the test was recorded.  The build server also requires a Visual Studio 2010 Test Agent running on it.  It also needs to be configured to record video if required.  Finally the build has to be configured to run the Coded UI Tests.  The following steps walk through configuring these items.

Configuring the Test Agent to Run Coded UI Tests

1. Run the Microsoft Visual Studio 2010 Test Agent Configuration Tool (Start > Program Files > Visual Studio 2010 > Visual Studio 2010 Test Agent Configuration Tool)

2. Configure the Test Agent to Run Interactive

3. Ensure that Log on automatically and Ensure screen saver is disabled are checked.  This will enable the server to be ready to run the tests even if the server is rebooted.   Also, the screen saver has to be disabled so the machine doesn’t get locked.  The Coded UI Tests can not run if the screen is locked. If you use Remote Desktop (RDP) to connect to the server, when you log out the machine it will automatically lock it.  To prevent this from happening, you must log into it from the machine or VM console.  If this is not an option, an alternative is to log on to another server such as the TFS server, then RDP into the build server from the TFS server and close the RDP session to the TFS server to lock this server but the build server remains unlocked and the Coded UI Tests will be able to run.

4. Register the Test Agent to a Test Controller that is not configured for Test Manager.  Unfortunately, the Coded UI tests run from the Build Server can not share the same test controller. 

Enabling Video Recording for the Automated Tests

One of the options in the test settings is to enabling video recording as part of the data collection.  By default the server doesn’t have the required components and configuration to enable this.  Follow these steps to enable the video recording.

1. Install the RTM Update for Lab Management on the Build Server
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=8406ef19-35a3-4c03-a145-08ba982f3cef&displaylang=en

2. Install Microsoft Expression Encoder
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=75402be0-c603-4998-a79c-becdd197aa79

3. If the Build Server is Windows Server then enable the Desktop Experience Feature.

Configuring the Build to run the Coded UI Tests

The final part to configure is to configure the build to run the Coded UI Tests.

1. Open the Test Settings file in Visual Studio by clicking Test > Edit Test Settings > Local.

2. Create a copy by clicking “Save As” and call it something like “BuildServer”. 

3. Change the name to “BuildServer”.

4. Choose the Roles item.  Change the local execution to “Remote Execution”.

5.  Enter the name of the Test Controller that the Test Agent on the build server is using.

If you get the error “The following test controller is not available : YourServer.  You must remove the association using the Lab Center within Microsoft Test Manager”, then you must remove this association.

a. To remove the association, remove the registration in the Visual Studio 2010 Test Controller Configuration Tool.  Uncheck the “Register with Team Project Collection” option.
 

6. The Roles item in the BuildServer Test Settings should look like the following

7. Close the Test Settings and Check in the new build definition file.

8. Open the Build Definition.  Click on the Process tab.  Expand the Automated Tests > Test Assembly.  Click on the TestSettings File ellipse.  Chose the BuildServer  test settings file.

9. Save the build definition and queue the new build.  The Coded UI Test should run on the build and your test should pass. If the test fails, open the test results and view the details the same way you would do for a broken unit test.

This is a cross post from the Deliveron blog. http://www.deliveron.com/blog/post/Configuring-a-TFS-2010-Team-Build-Server-to-Run-Coded-UI-Tests.aspx

Today I have released Team Deploy 2010 for Team Foundation Server 2010.  In this post, I am going to give a quick overview of Team Deploy if you haven’t used it before, explain this release and upcoming releases, compare it to Lab Management 2010, and give a walkthrough for setting it up and uninstalling it.

What is Team Deploy?

Team Deploy is a set of custom build activities used to deploy MSIs to multiple client PCs and/or deploy services to servers.  This activities include the ability to kill processes, start/stop services, pass in arguments to the MSIs, provide the service username/password, and uninstall previous versions.  Team Deploy uses SysInternal’s PSTools to remotely execute MSIEXEC to install the MSIs and PSKill to kill processes.  By using Team Deploy, development teams can create automated build and deploy processes for better configuration management.  Deployments can be done on demand or scheduled just like any other build in Team Build.  If you are using Team Foundation Server 2008, Team Deploy 2.1 is the current release to download.  Team Deploy is open source and free to use.  It can be downloaded from http://teamdeploy.codeplex.com

This Release and Future Plans

I am calling this version of Team Deploy 2010, Release 1.  This release is a 1 for 1 port of the MSBuild tasks to Workflow custom activities.  I wanted to release this version without any additional enhancements so development teams can upgrade their build definitions to workflow.  I have a lot ideas for future versions.  Lab Management 2010 has given me some ideas (see comparison below) and there are several other things I want to do.  Here is a list of some:

• MSI Package for Team Deploy 2010 – For custom build tasks, deployments are easy.  Basically just copy the Dll to the MSBuilds folder and use that path in the build definitions.  For Team Build custom activities, it is a little more complicated.  As you will see in the Setup Walkthrough below, there are several steps that are fairly easy to do manually but are going to be more difficult to do with a custom task.  I have begun working on this but it wasn’t ready for this release.
• Breakout Deploy activity into Workflow – Currently the Deploy activity does all the work and calls the other activities within code.  I want to create an additional workflow with all of these steps in a workflow.
• PowerShell capabilities – PowerShell 2.0 has the ability to be run on remote machines.  I want to research this functionality and see if it makes sense to create an addition set of activities that use PowerShell instead of PSTools.
• Custom Build Definition Screen – Display screen to create the deployment options through the UI instead of creating it in XML today.
• Change the Threadpool to .Net 4 Tasks for deploying to multiple machines at the same time.
• Team Deploy build definition to call another definition to  do the build and deploy (Similar to Lab Management)

Team Deploy and Lab Management

Visual Studio 2010 introduces an additional product for Team Foundation Server 2010 called Lab Management 2010.  This product allows virtual environments be created, quickly provisioned, used for manual and automated testing.  Lab Management also includes a new build definition type and activities.  With the build definition type, it allows you to revert the virtual environment to a baseline snapshot, build the application, deploy the application, run the automated tests, and capture the results.  So Lab Management can do what Team Deploy can do and a lot more.   The one area that I have seen Team Deploy used where Lab Management would not be used is for deploying applications to QA and Production.  I have worked with several companies that use Team Deploy to deploy to all of their environments for a consistent deployment process.

Team Deploy Setup

Here are the steps to install Team Deploy and create a simple build.

1. The TeamDeploy2010_R1.zip file contains the following 4 files that are used to install the application.

2. Copy TeamDeploy.Activities.* to a location in source control and check in.

3. Add TeamDeploy.Activities.dll to the GAC using Gacutil.

4. Add source control location of custom assemblies to build controller.  ($/TestBuilds/CustomActivities in this example)

5. Copy DeployTemplate.xaml to source control in the BuildProcessTemplates folder.

6. Create a new build definition.  In the Process Step click on “New” Template and add the existing DeployTemplate.xaml template that was added to source control.  Click OK.

7. Set the build properties to where the PSTools is installed and where the deployment XML is located. Click Save.

8. Rename and edit SampleDeployScript.xml to specify applications to install and machines to deploy to.  See http://teamdeploy.codeplex.com website for full list of options available. If you open the DeployTemplate.xaml.  It should look like this. 

If there is an error for the deploy activity.  Delete the AgentScope activity.

1.  Add Team Deploy 2010 Activities by right clicking in the toolbox and select “Choose Items…”. Make sure System.Activities Components tab is selected and select “Browse…” to find the location of the TeamDeploy.Activities.dll and choose it.

  2. Once you have added the TeamDeploy.Activities.dll, you will see the activities selected.  Click Ok.

3. Clicking Ok will add the activities to the toolbox. Drag the Deploy activity to the AgentScope container.  The required properties will cause a red error icon to display.  Fill out the properties to where you have the deployment script and PSTools installed. (Sometimes the designer won’t let you drag the Deploy activity to the canvas.  Save the workflow, exit Visual Studio 2010, and reopen the workflow.  It should then.

Uninstalling or Updating Team Deploy 2010

1. Close Visual Studio 2010

2. Stop the Visual Studio Team Foundation Build Service Host service.

3. To remove Team Deploy from the GAC, browse to c:\windows\microsoft.net\assembly\gac_msil and delete the TeamDeploy.Activities folder.

Build Log of Deploy activity in Team Build 2010

Here is an example of the build log for the Deploy activity.

I hope you enjoy!  Let me know if you have any ideas or run into problems.

Mike

Thanks everyone for coming on Tuesday to the Omaha Team System User Group meeting to see my presentation on What’s New for Testing in Visual Studio 2010 and TFS 2010.  It was a great turnout and there were a lot of great dialog and questions asked. 

Here’s the slides from the presentation.
http://www.codesmartnothard.com/content/binary/Whats_New_for_Testing_in_Visual_Studio_2010.zip

If you missed it or know anyone else that wants to see it, I’m doing this presentation again on a Webcast on April 14th at 11:00 (central time).  Here’s the link:
https://www.clicktoattend.com/invitation.aspx?code=146828

Contact us below if you would like more information about implementing Team Foundation Server and/or Visual Studio Lab Management 2010.

Thanks,
Mike

I’m excited to be speaking 3 times in the next month on the new testing capabilities in Visual Studio 2010 and TFS 2010.  Two events are listed below.  The third event is full.  I hope you can make one of them.

Sign up for the Deliveron Newsletter to be notified about future presentations.

Presentation Overview

Visual Studio 2010 introduces Lab Management 2010 and Test Professional 2010 to remove the silos between QA professionals and developers to establish a more cohesive development and testing process.  Together these products include tools and features for creating test plans, creating and running manual tests, automated UI testing, creating test virtual environments, recording manual tests, and collecting diagnostic and error data to easily include with bugs.  See how everyone on your development and testing teams can take advantage of these improvements

Omaha Team System User Group Meeting

March 23, 2010 at 6:00pm
Farm Credit Services of America
5015 S 118th St
Omaha, NE 68137
Register here

Deliveron April Webcast

April 14th, 2010 at 11:00am Central Time
Register here

To me there has always been a feeling a of excitement to be able to build an application and then deliver it to someone that wants it.  When I first started programming over 20 years ago with GW-BASIC on my Tandy 1000 EX, it was limiting that what I built could only be run within GW-BASIC since it was an interpreted language environment and not compiled.  When I bought Quick Basic 4.5, I could finally compile my applications into an EXE and run them outside of the interpreter.  Then I felt like I hit the big time when I was able to build my first setup package in Visual Basic 4.  I remember I built a Hello World caliber application and created a setup package that took 3 or 4 floppy disks.  I didn’t think it could get any better than this :)  Over the years the the excitement about delivering applications became more from the what was built and not how it would be delivered.  Visual Studio has always included functional, no frills setup projects.  3rd Party vendors have created easier to use and more power tools for creating deployment projects such as InstallShield.   Developers who didn’t purchase a 3rd Party tool were limited to using the OOB (out of the box) setup projects within Visual Studio.  While this is functional, the developer has to know where and how to do things and the usability is not very intuitive.  It requires many steps to creating a MSI that I have blogged about in Deployments with TFS Part 2: How to create an automated deployment MSI.   In Visual Studio 2010 there is finally an easy to solution without purchasing an additional production.

Last week I saw this post from Somasegar on Building setup and deployment packages in VS 2010.   Microsoft has partnered with Flexera, makers of InstallShield to create InstallShield Limited Edition for Visual Studio 2010.  This brings the InstallShield graphical interface to Visual Studio.  In addition to providing a highly intuitive interface for building setup packages, this product allows setup packages to be built from with TFS Team Builds.  This has been a major pain point for automated deployments and SCM (Software Configuration Management) processes.  I downloaded and installed InstallShield 2010 LE and here is a walkthrough of the tool.

Download and Installation

Read Somasegar’s blog post on how to download and install it.  (see link above)

InstallShield 2010 LE Setup project

Once it is installed and you create a InstallShield Setup project, the Project Assignment view is the default view.  As you can see, the graphic is a guide that explains the parts of the MSI and the steps to create the package.  At the bottom of the screen are the steps to the installation project.  In addition to the steps at the bottom of the guide, there are also intuitive steps to the right that keep all of the package settings cleanly organized.  

This first step is to fill out the basic information about the application that is going to be deployed.

In the second step, required operating systems and prerequisite applications can be specified and enforced when installing the application.  Custom prerequisites can be defined by choosing “Create a custom software condition” under “More Options”.

The installation Architecture section step is disabled in the Limited Edition.  In the other editions different features can be defined for users to choose what sections they want installed.

The next step is the Application Files.  Here the application’s files can be added to the installation.   The “Add Project Outputs” is the primary button for adding the application files.  I found this dialog window to be a lot easier to use than the Visual Studio setup project.

The Application Shortcuts step is where desktop and start menu shortcuts can be defined.

If the application requires any registry entries, they can be defined in the Application Registry step.

The last step is the Installation Interview.  This step asks a series of questions that drive what dialogs the user running the installation will see.  Custom dialogs are not supported in the InstallShield Limited Edition.   Custom dialogs are supported in the Visual Studio setup projects.  For the automated deployment MSIs, I create a dialog that allows the user to specify the environment.

Custom Actions are non-standard activities that can be performed at different points of the installation process.  The Limited Edition supports VBScript, JScript, and Exe custom actions.  However, as shown in the following image, there are only a couple points in the process where custom actions can be defined.  The Premier and Professional editions also support InstallScript, a powerful scripting tool to create more advanced customizations to the installation process.

After I built the MSI, I ran package to install it.  Users will see this message box that the installation was created with a beta version of InstallShield. 

InstallShield 2010 LE for Visual Studio 2008

The InstallShield 2010 LE Installation also installs a version that works within Visual Studio 2008.  This interface looks the same in Visual Studio 2008 as it does in Visual Studio 2010.

Building MSIs with Team Build 2010

This is the feature I am most looking forward to in InstallShield 2010 LE.  Standard Visual Studio 2008 setup projects can not be built within Team Build without some tricks.  Unfortunately TFS Source Control and Team Build integration is not available in this beta version.  I verified this with Flexera.  They are currently working on it.  As soon as an updated version is available with this enabled I will do a follow up post detailing the TFS Source Control and Team Build experience.  I’m interested to see the following in action:

• Triggering a build and having the MSI compile with the updated assemblies.
• Curious to see if the InstallShield Setup project build can detect new dependencies added.  My tests will include adding a reference to the primary output application.  Then do a new build to see if the MSI will automatically include it.  It might be expecting too much but this would be very beneficial.

Overall

• The Project Assistant is a very simple to use series of steps to create a complete setup project.  As users feel more comfortable with the too, they will probably jump to the specific screens they are looking for in the navigation pane on the right.  Both are highly intuitive and significant improvements over the the standard Visual Studio setup projects.
• Most things that are supported in the standard Visual Studio setup project can be accomplished with InstallShield 2010 Limited Edition.  For most installation packages, these limitations will not be problem.  However, I will not be able to create automated deployment MSIs because of the limitations of no custom dialogs and not being able to create custom properties.
• Being able to rebuild the MSIs during each Team Build is a huge benefit.  Once this feature is available, I think it will become my favorite feature.
• I believe Microsoft and Flexera will both win with this product.  Microsoft’s Visual Studio 2010 will include an improved tool for creating installation packages without having to reinvent the wheel.  Flexera has built an amazing and easy to use product that will work for the majority of scenarios, but many will want to upgrade to the Express, Professional, or Premier editions to get the full power of InstallShield.
• The final product should be great, but this beta version is not ready to be used for more than evaluation purposes.  Between the beta message box that is displayed when the user installs it and the fact that the TFS Source Control and Team Build integration features are not available yet, I recommend waiting until the final version is released.

Mike

There is a lot of information about the major updates of TFS 2010 and Team Build 2010 including changing from MSBuild to Workflow and Gated Check-Ins to name a couple.  In using TFS and Team Build 2010 beta 2, there are a lot little features and improvements that help make these two products complete and polished.  Here are a few of the features and I keep discovering new ones each time I use it.

New Build Definition will default name and solution to build

if you have a solution open in Visual Studio 2010 when you create a new build definition, the build name will default to the solution name.

An open solution will also automatically be populated as the Project to Build

The build retention policy is not set to “Keep All” by default.

Finally, the default retention policy for the builds is not set to “Keep All” anymore.  Primarily all results will default to keep the last 10 builds.  In Visual Studio 2008, I always recommended that this should be changed.

TFS Build notifies you about successful and failed builds

The Team Foundation Build Notification tool used to be part of the power tools.  Now it is included with the standard installation and alerts you to the success or failure of the build.   This supports continuous integration and gated check-in builds.  The notification dialog window also has an option for unshelving failed gated check-ins.

This dialog displays for a successful Gated Check-in build

This dialog is display when a Gated Check-In fails.  Notice the Unshelve Changes option to retrieve the changeset that was be attempted to be checked-in.

Build Parameters are now strongly typed and visible

In Team Build 2008, parameters could be passed in to a build when it was being queued.   However the format was command line argument style passed into a textbox similar to this:

/p:IsThisCool=”false”

In Team Build 2010, the build parameters are displayed as strongly typed properties.   This will allow for type checking and eliminate the misspelling of parameters.

Enjoy all of the great new features in Team Build 2010 including these smaller but helpful features!

Mike