Set verbosity of logging during Tfs 2010 build

To test a little bit how you can log information during a TFS 2010 build you can create a simple activity , this activity simply has a Message property and log three messages, at different BuildMessageImportance level

image

The utility function is the following one

image

Really simple isn’t it? :). Now you need to insert this custom action inside a standard tfs build definition file, to make this happens I need to remind you that you need to include the xaml build definition file in a project included in a solution where your custom action is defined, if not you cannot use the designer and you need to manually edit xaml file.

To easy this process I branched directly the build definition file, with this simple trick, I edit the definition file in my test project, do a check-in and when I want to update the real build definition I do a simple merge. Then I insert my action in the build process. So I created a new build definition from the default template, configure it, then branched into my test project.

image

I highlighted the two important facts: 1) the file is included in the project DotNetMarche.Activities.Workflow.Test, 2) The project with the action is included in the solution, now I can drop the LogSample action into the build definition file using the graphical editor, check-in, merge and launch the build with the new definition (I remember you that you need to deploy also the custom activity as described here), here is the result.

image

As you can verify, only the message with BuildMessageImportance.High is showed, this because the entire build process has an argument that determines the level of log verbosity. Now try to change this value to Detailed. You should click the “Arguments” and locate the Verbosity argument.

image

Now change it to Detailed, check-in, merge 😉 and launch the build again to verify the result.

image

Now you can see that in “Detailed” level of verbosity, the workflow logs even the Normal level. The morale is that in your custom activity you should use BuildMessageImportance with great care. Really important messages must be showed with High importance, detailed with Normal, and you should use Low for really verbose messages. But remember, always do a verbose log, because if something gets wrong in the build, you can always change the BuildVerbosity level and verify in detail what is really gone wrong in your custom action.

Alk.

Tags:

Deploy a database project with tfs build 2010

If you want to deploy a database project into a target sql server instance during a tfs 2010 build, you can use with success the basic MsBuildTask, similar to tfs2008.

I decided to deploy the database, only if the tests are ok and the build is ok, so I place a condition activity under the test phase and I set the condition to pass only if the test and build status are different from Failed

image

Now I need to know where the dbproj will be located in the disk during the build, and since I know the repository path, I can use a specific TFS build action to convert the source control path into physical path. The source control path is “$/Experiments/NorthwindTest/NorthwindTest.Database/NorthwindTest.Database.dbproj” so I can drop a “ConvertWorkspaceItem” activity to convert this path to the physical one. First of all I need to declare a variable where to put the result.

image

I called this variable “dbProject” (String type). Now I can configure my ConvertWorkspaceItem activity I dropped in the “then” part of my condition activity.

image

This activity needs three variables, the first is the source control path you want to translate, the second is the name of the variable that will contain the result and the third is the Workspace to use (is stored into the global variable Workspace).

Following this activity I dropped a WriteBuildMessage activity, used to write something into the build log (I wrote the exact path of the database project that is to be deployed)

image

This is only informational, but it is useful to check during the build process.

The most important activity is the MsBuildActivity that will do the real work. This activity invokes Msbuild.exe that in turns will target the database project to deploy. The most important property is the CommandLineArgument where you must specify all details of the deploy

"/p:TargetDatabase=NorthwindTest" +
" /p:""DefaultDataPath=C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA""" +
" /p:""TargetConnectionString=Data Source=10.0.0.99\SQL2008,49400%3Buser=sa%3Bpwd=Pa$$w0rd""" +
" /p:DeployToDatabase=true"

These properties are used to specify the name of the database, the datapath, the connectionstring where to deploy the database, and they override the standard one defined on the project. As you can see in connection string I used the sa password, that is strongly discouraged for security reasons in production environment. You can use integrated security if the user used to run the team agent has the right to create a database in the target instance.

Finally these are all the properties of the msbuild activity.

image

LogFile is really important, because you want a msbuild log file of what is happened during the deploy. You can check this file in the logs\ subfolder of the drop location

image

If you open deploydatabase.log, you can find all the information you need on what is happened, here is a little extract.

Build started 1/4/2010 7:08:38 AM.
Project "C:\Builds\1\Experiments\DeployDatabase\Sources\NorthwindTest\NorthwindTest.Database\NorthwindTest.Database.dbproj" on node 1 (Deploy target(s)).
DspDeploy:
  Deployment script generated to:
  C:\Builds\1\Experiments\DeployDatabase\Binaries\NorthwindTest.Database.sql
  Creating NorthwindTest…
  Creating [dbo].[Categories]…
  Creating PK_Categories…
  Creating [dbo].[Categories].[CategoryName]…
  Creating [dbo].[CustomerCustomerDemo]…
  Creating PK_CustomerCustomerDemo…
  Creating [dbo].[CustomerDemographics]…
  Creating PK_CustomerDemographics…
  Creating [dbo].[Customers]…
  Creating PK_Customers…

A really important property is the Target, that is set to New String() {“Deploy”}. A database project supports some different targets, as an example the build, deploy, dataGeneration and StaticCodeAnalysis, each of them will perform a different task.

The project to deploy is specified in the Project property, and as you can see I use the variable dbProject that was populated with the ConvertWorkspaceItem.

If you check build details you can find all the information you need about the build process

image

From here you can verify project directory, and all the options that are passed to the msbuild.exe. You can now schedule the build and verify that the database is deployed on target server.

alk.

Tags:

Using graphical editor with custom action in tfs2010 buils

In last post I showed how to build a custom code activity to customize tfsbuild for beta2 of tfs2010. In that post I inserted custom action manually in the xaml file of the build definition, and I know that this can be a pain, if you want to insert a custom action in a specific part of the workflow.

A simple trick is the following, copy the build definition into a test project that belong to the solution where your custom action belong, then add to the project, and you will see that your custom action magically appears into the toolbox. You can verify this in the picture above.

image

To make this happens, you really need to include the build definition into a project of the solution.

image

Ok, now you can delete the tweet action from the very beginning of the build, and simply change the workflow, to tweet an alert if a build is broken. First of all you need to scroll down the build definition to find the part where the compilation takes place.image

Now if the build fails, exception gets executed, so you need to customize the exception part of the compilation sequence. Then simply drop your tweet action in the build process, then configure it specifying username, password and message. For the message is useful to access build information from the BuildDetail variable to specify in the tweet the build number related to the failing build.

image

Now you can save the modified build definition, and copy back to the BuildProcessTemplates folder of source control, to replace old build definition, then simply broke the code inserting some not compiling stuff in the build, commit everything and fire a build.

image

Everything is ok. In this way you can edit the workflow in a really better way, instead of editing the xaml manually, you can fully use the designer with no problem.

alk.

Tags:

Custom Activities in TFS2010

There is a good post on Jim Lamb’s blog on how to customize tfs2010 build, but I decided to blog my experience because I need some more time to make it work.

The steps to create a custom activities in tfs2010 are the following ones. First of all create an activity, like this simple TweetActivity one. Respect the example of Jim, I need to add also the BuildExtensionAttribute to make it run.

[BuildActivity(HostEnvironmentOption.All)]
[BuildExtension(HostEnvironmentOption.Agent)]
public sealed class TweetActivity : CodeActivity
{
   [RequiredArgument]
   public InArgument<string> Username { get; set; }

   [RequiredArgument]
   public InArgument<string> Password { get; set; }

   [RequiredArgument]
   public InArgument<string> Tweet { get; set; }

   protected override void Execute(CodeActivityContext context)
   {

       TwitterService service = new TwitterService();
       String tweet = Tweet.Get(context);
       tweet = tweet.Substring(0, Math.Min(tweet.Length, 140));
       String result = service.SendMessage(Username.Get(context), Password.Get(context), tweet);
   }
}

This is a very simple activity that simply tweet a message. Then after you compile it, you need to save the assembly in a specific file of your source code, to be available from build agent.

image

You must configure the Build Controller to point at a specific folder to have it understand where to find assemblies that contains custom activities. These steps are really well described in Jim’s post, so I do not give further details.

Then you face the first problem, if you copy the default workflow of the build (to avoid changing the basic one) and open it into Visual Studio, you don’t see your custom action in toolbox so you are not able to add it to your build process. To solve this I decided to add my custom activity by hand, editing the xaml file. First of all you need to add the namespace

image

Now you need to add your custom activity in the workflow flow, I decided, for simplicity, to add it before the get latest activity, so it is the very first activity that gets executed. After all I only wants to test if my action gets executed during the build.

image

Xaml files are simple enough to edit by hand, as you can see to add the custom activity, just add a da:TweetActivity (da is the alias I used for my namespace) and configure the properties. Then I commit everything and started a build.

image

Ok it works :).

alk.

Tags: