From the previous post we have these custom targets we want to create; MSI package building, Database deploy, Service installation, and Web deploy. I will go through each of them and give you some hints on how the targets were created.

MSI package building

For this part we need to know the solution name, the project containing the setup and where VisualStudio is installed. Remember the registry thing from the last post? Here it really comes in handy.

<PropertyGroup>
  <VS>$(registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
    VisualStudio\9.0\@InstallDir)\devenv</VS>
</PropertyGroup>

<Target Name="BuildMsi">
  <Message Text="Building package $(Vdproj)" />
  <Exec Command='"$(VS)" "$(Sln)" /Build "Release|Any CPU"
    /project "$(Vdproj)" 
    /ProjectConfig "Release"'/>
</Target>

Never mind the extra line breaks, it’s for readability. But note the single quote that is used on the Command part, this makes it possible to use double quote in the command text for readability. The other option is to use &quote; but that really makes it very hard to read the scripts.

Database deploy

When we deploy a database you typically have five parameters involved; where, who and what. Oh, the who part is user and password and where includes both server and database, a total of five. Now, let us start with a simple target and a magic database task.

<Target Name="DeployDatabase">
  <Message Text="Deploying $(DBContent) to $(DB) on $(Server)" />
  <MagicTask DataPath="$(DBContent)"
    ConnectionString="Database=$(DB);Server=$(Server);
                      UID=$(User);PWD=$(Pass)"
    DropDatabase="true" />
  <Message Text="Database deployed on $(Server)" />
</Target>

The MagicTask is depending on how you deploy the database, we are using NHibernate and have written custom tasks to handle the deployment. There are a set of build tasks on CodePlex, created by a college of mine, that can help you with the specific tasks for database deployment.

Service installation

When it comes to service installation you have to get hold of a little bag of tricks to get all of it working. Locally there is not as big issue . Just call the MSI installer and execute it silently both for uninstall and install.

<Exec Command='msiexec /i "$(Msi)" /qn' />

$(Msi) holds the full path of the installer package. When it’s installed, it should be started and for that we use net start with the service name as parameter.

<Exec Command="net start $(Service)" />

But how do you do it remotely? Here’s where the bag of tricks come in handy. First you need a place on the remote system where you can transfer the files. Make sure the agent has access right to copy the files there. Then, use some magic from Sysinternals, named PsExec.exe. This little tool makes it possible to remotely execute net start and msiexec. his target we need the MSI, the Server, user and password and the name of the Service that is installed. You need to touch up the scripts with some of your own paths to make sure you have all the files in the right place to start with.

<PropertyGroup>
  <!-- The sysinternals tool -->
  <PsExec>$(MSBuildStartupDirectory)\Tools\psexec.exe</PsExec>
  <!-- Here is the new MSI package is placed -->
  <NewMsi>$(MSBuildStartupDirectory)\msi</NewMsi>
  <!-- Here is the currently installed MSI package placed -->
  <SharedMsi>$(server)\msi</SharedMsi>
</PropertyGroup>

<Target Name="InstallMsi">
  <Message Text="Installing and starting $(msi)/>

  <!-- First Uninstall the old service if the config is there -->
  <Exec Command='$(PsExec) -accepteula $(Server) 
        -u $(User) -p $(Pass) -w "$(OldMsi)" -n 60 
        msiexec /x "$(SharedMsi)\$(msi)" /quiet' />

  <!-- Copy and install the new service -->
  <Copy SourceFiles="$(NewMsi)\$(msi)" 
    DestinationFolder="$(OldMsi)" />
  <Exec Command='$(PsExec) -accepteula $(Server) 
        -u $(User) -p $(Pass) msiexec /i 
        "$(SharedMsi)\$(msi)" /qn' />

  <!-- and start the service -->
  <Exec Command='$(PsExec) $(Server) -u 
        $(User) -p $(Pass) -d net start $(Service)' />

  <Message Text="$(Service) installed and started" />
 </Target>

Hopefully this will give you the basic idea. For all the switches on PsExec, look into Sysinternals. But one that can be a real timeserver (often hangs the build) is the –accepteula switch, it auto accepts the EULA splash screen.

Web deploy

Maybe the simplest deployment is the web deployment. Most of the time there is nothing more to it than copy the files and you are up and running. However, you may need to set some configuration etc depending on how your environments are setup. But for now a simple target like this will do the trick for web deployment:

<ItemGroup>
  <WebContent Include="$(ContentPath)\**\*.*" />
</ItemGroup>
  
<Target Name="DeployWeb">
  <Message Text="Installing web on $(Server)" />
  <Copy SourceFiles="@(WebContent)" 
    DestinationFolder="$(Server)\$(WebFolder)\%(RecursiveDir)" />
</Target>

The ItemGroup here will produce a recursive list of files and folders from the ContentPath and it get placed in WebContent item group. The files will then be copied to the WebFolder on the Server. So here we have three properties to set for this target. Also make sure you have the correct access levels on the folders and you can do this remote as well.

Calling the targets

Now that we have the targets in place, how do we get all the properties into them? Well, custom targets can be accessed in a couple of different ways. You can import them and then call them as usual and all the properties you set in the calling script are set as if the target was in your current script.

<Import Project="CustomTargets.proj" />

<PropertyGroup>
  <Server>Srv01</Server>
  <User>Kalle</User>
  <Pass>Kula</Pass>
  <Msi>setup.msi</Msi>
</PropertyGroup>

<Target Name="default">
  <CallTarget Targets="InstallMsi" />
</Target>

But in this case I want to pass in more than one set of properties to the target to make it more flexible. And in that case it’s easier to use the MSBuild task. This will execute the target as if you were calling it from command line.

<MSBuild Projects="CustomTargets.proj" 
  Targets="DeployDatabase"
  Properties="Server=DbSrv01;User=sa;Pass=sa;DB=Base;DBContent=Data" />

All together now

All this is, in our case, trigged from TeamCity, but could of course be triggered from other build systems as well. Adding some initial parameters, like where to deploy things, makes it very easy for me to add more servers later on. For now I just execute MSBuild with the needed properties.

MSBuild deploy.msbuild /property:DB=DbSrv01;DeployOn=Srv01;Web=WwwRoot

You have to make a lot of choices where to trigger and store the properties to maximize flexibility and readability. Additionally, some smart naming of files and projects will help in minimizing the number of properties. All this is of course depending on the project you are deploying.

And one more thing, make sure the build agents are executing with the right access rights, or you will not be able to execute some of the commands. This is especially important when it comes to accessing the other systems through PsExec. It took me a while to fix that problem :)

// Håkan Reis

Version 4 of TeamCity has been out for a few weeks now and there are a lot of improvements in this release. A few of them are:

• Improved build runners now with of FxCop an new versions of NUnit
• Test reordering (problematic and failed tests are executed first to give even faster feedback)
• Build agent improvements
• Artifact dependencies

There are a lot more and not all are .Net features of course. I’m going to focus on the last one here that are a big improvement in my current project.

We have a setup of development builds and a few nightly test and analysis builds. To top it of we have deployment builds to testing environments. The development builds are easy to maintain. But the analysis and deployment scripts were giving us a lot of problems. In the scripts we were copying files from the development builds to deployment and analysis but this was not a stable solution. If the development builds were running the deploy and analysis builds would fail. Artifact dependencies to the rescue.

Artifacts

Whenever a build is completed I can direct files to a special TeamCity repository. Here it gets saved in a structure I define. So for example when a development build of our web project is done I store the files for deploying to the web, unit and function testing, and a few shared assemblies. the shared files are stored as build artifacts using the following artifact paths (Build Configuration Step 1 – General settings):

So for each successful build we get a copy of the produced shared assemblies (and all other supporting files in the two release folders). So the artifact structure for each web build will look like the following image:

Here we have the Web files, the shared Common and Core assemblies and unit test projects.

Artifact dependencies

Moving on to the deployment builds, we want to start out with Common and Core assemblies already in place but from the last successful development build. This is really easy with the new artifact dependencies. Going into the deployment build configuration we set up this artifact dependency (Build Configuration Step 5 - Dependencies) like this:

Now the assemblies in Shared/Common/ and Shared/Core/ folders in TeamCity will be placed in my deployment build checkout folder before the subversion checkout is done. This dependency can be modified to only work on pinned builds and even specific build numbers. And you can add more artifact paths and of course artifacts from multiple build configurations. So if you haven’t upgraded to TeamCity 4.0.1 go ahead now.

// Håkan Reis

I have been writing about agile interaction before in Agile Usability No 1 and after that in Agile Usability No 2 - AID. Also a post I did November 2006, Refactoring the agile manifesto, tries to induce some interaction design thinking in the agile manifesto.

Still there are a number of things to do in this area. For some of us agile development is old news, but actually it has just begun and interaction designers should take this opportunity to get more involved in the process. As I attended from business to buttons earlier on I was alarmed by the lack of understanding in agile software development. I really think there are actions that need to be taken now.

More and more I have found that interaction design needs to be split into two parts; backlog creation and software interaction design. And it seems that Alan cooper backs my view on this even if I don’t agree with all he says.

Backlog creation

The interaction designers really are the ones that can translate user needs to user stories. They have the ability to explain end boil down real user needs and goals to user stories that developers can understand. The interaction designers have the tools to create vivid scenarios. And from them extract all the user stories needed to create a compelling and rich user experience.

Software interaction design

This part is done in tight co-operation with the developers. Churn out sketches and prototypes together with them, make sure they get the designs and purpose and at the same time learn about the boundaries of system. What is possible to create and what shortcuts can I use. No more documents or Photoshop mockups that just get’s handed over to the developers. The result is quick feedback with with bits and pieces of working code and interaction that can be used in user testing.

Wireframe tools may be useful for early testing of concepts and ideas but I actually think that Microsoft is right on track with their, still rough, set of tools. In the Expression suite they try to make a solid split of design and development, enabling parallel cooperative designer/developer work.

Get rid of big up front design

Still there are interaction designers out there that think they can come up with a bunch of user studies, wireframes and flash prototypes and just hand them over. I’d say they have to adapt or start looking for a new career. We really have to work together on this.

The interaction designer in a scrum team

Interaction designers are full grown team members. Obey the rules of the scrum team and get the flexibility and trust as a team member. Always strive to improve and streamline the process at every sprint retrospective. It’s time for the interaction design community to create their set of tools for the agile process. It may be tweaked versions of current research tool box or something completely new. But this is our chance to get as involved and the users need us to be.

// Håkan Reis

I was at a interaction design specific conference at June 12-13, from business to buttons. I haven't gotten around to jot down my thoughts about it until now. A short description on some of the seminars follows:

Day one

Keynote by the man, Don Norman. And a little plug for his new book The Design of Future Things - I probably will get this book as all the others. Don't get me wrong this was not just a book review, there was a lot good insights and it was good listening.

Next up was a session with Kim Lenox a really good session. A good look on how they are changing their way of work, they are clearly moving towards a more agile and involved process. I mean; whiteboards, post-its, direct communication and collaboration over the borders. This is getting good and fun. This was a new session, as Ryan Freitas had to cancel  his, and a very pleasant surprise.

Next up was a mix containing three shorter session on New interaction techniques.

Most interesting of these was a session on multi touch and gestures. Quite interesting stuff, this also sprung a small fear that Apple et al are doing their patent stuff here. Multi touch and gestures should be open, not locked down by patents. 

There was a quite fun session on clothes and electronics from cutecircuit.

Last session of the day was by Kars Alfrink from Leapfrog on playful design, how the knowledge from gaming can be implemented on business. There are lots of interesting stuff that can come out of that mix, I'm sure.

Day two

For me the day started out with a keynote by Dr Patrick W Jordan around the four pleasures; Physio, Psycho, Socio and Ideo. This was a excellent session with lots of real world data and anecdotes. Like the clunk of BMW doors and the Heineken psst.

Last out was a workshop on agile methods and interaction design. I think that a few answers came out of that session. Most important though is that developer in agile projects need to get the interaction designers on the right track. Share your knowledge. I think Interaction designers need to learn a lot more on this issue. Many are still stuck in big up front design, and this has got to change.

Sessions, pdfs and stuff can be found at the from business to buttons site.

On a side note, I think that many interaction designers are afraid that they will loose out on the design if not all methods and tools are applied. And some methods and techniques cannot be applied directly in an agile projects. However, the gain in communication and development speed [in agile projects] are  so great that there is no return. They have to learn that you don't need all the answers at the table at the start. And an interaction designers work is not done when the project starts. It has to be done continually during the development.

For a while know I have been using CruiseControl.NET for my Continuous Integration setup. It works OK on most occasions, but it seems to get old, no new version for since June last year. I want and expect better interaction and setup experience from a modern tool today.

So along comes TeamCity from JetBrains as a promising new tool, free for three build agents, 20 users and 20 different builds. And for a couple of weeks I have been test driving it. The system itself is built as two parts, the Continuous Integration server and the Build Agents. These need not to be on the same system and you can mix and match Windows and Linux with .NET and Java. It all depends on the build agents. For the test setup I used a server with TeamCity and a build agent on the same machine. The setup is really straightforward, just run the installer and answer a few simple questions. Next up is setting up your project and builds.

There are a few different scenarios I have been working with and to start with the most simple:

Scenario one - build and test:

• Subversion
• Visual studio 2008 solution
• NUnit 2.4.6 unit testing

Well, it couldn't get much easier than this when installing. There are seven steps for each build setup, but not all has to be used. For the basic setup you just point to your subversion repository and select a project folder to checkout into.

Then you select the solution files, set the unit test to the correct version and specify the test assemblies for example **/*.test.dll. Don't forget to unselect the tests in the */obj/ folders, there is a special setting for this as well **/obj/*.test.dll would do the trick.

Last thing was to set the build triggers, I just went along with 60s delayed check in build, then you can also trigger time scheduled builds (good for integration testing and deployment).

Actually it is that simple, no bloated config files to go through. Just make sure the correct version of .NET framework is in place. I had an early beta of 3.5 in place and it took me a while to figure that out.

So for the client then? Is there a tray icon and stuff? Sure is, on the server, set up the users that should access TeamCity, and the access level. When you login you have your settings, and there you will find plugins for Eclipse and Visual Studio (will link to the code from the site and show the tests and your modifications) as well as a tray icon.

What's next?

The second scenario, build, test, and coverage was trickier, when adding the coverage part. Being on .NET there aren't that many free coverage tools. The only viable one is the old NCover 1.5.8 version. This is sad, $149 is a bit steep but it's ok in the right project. But I certainly don't want to pony up $299.00 just to get 64bit support. Supposedly the pro version don't support 64bit. There is a coverage tool called PartCover but it seems to be dead since August 2007, and there is too little information about it.

The third scenario was one that I didn't quite get around to. This was to use the build in Visual Studio Team System Developer support with Microsoft test and coverage. These are good when you run it in your environment and it would be great to have it running in TeamCity.

I will get to the second and third scenarios in upcoming blog posts.

How do you work iteratively with UI?How do you incorporate new and changed user demands into the upfront UI work?How do you give developers enough UI vision to work on?