Simon says... architecture!

TFS 2010 and multiple projects output

Szymon Pobiega — Thu, 12 Apr 2012 20:17:10 +0000

This post is a part of automated deployment story

Some time ago we were forced to switch from TFS 2008 to TFS 2010. I must emphasise here that choosing TFS as source code repository and CI software was not my choice in the first place. We were forced to use it. Anyway, we wanted to move because the new system was in the same physical network as the whole environment so it would make transporting binary packages much easier and safer.

Apart from obvious changes, like replacing MSBuild with workflow, there is one thing that is more subtle but has so tremendous impact that nearly blocked our adoption of 2010.

It turns out that 2010 overrides the bin directory when building projects so that output of all compilations goes to one folder. By doing so it saves a lot of effort of copying copy local binaries here and there. There is a downside however. Having out output directory makes it really hard to build more than one application in the solution. The result is, all the binaries are mixed together and you can’t figure out (by the results alone) which one belongs to which application (and which are shared).

The problem is less dramatic with web applications because they have publish feature out of the box. What publish does is especially it gathers all the files related to the app and puts them into a zip file. It also gathers all the directly and indirectly referenced binaries, which is cool.

What about console applications then? In the obj directory you can find only the result of compiling the application. There are libraries it depends on. How can we find them?

We can use the very same file that you use to publish web applications. It is called Microsoft.WebApplication.targets and it is located in MSBuild folder in Program Files. All you need to do is strip it from all stuff that does not apply to console apps. Here’s what remains of it:


  

  
    
      $(BuildDependsOn);
      PackageBinaries;

It automatically hooks to a compile process, calculates the list of transitive dependencies of your project and fetches their binary forms from the common output location.

Now all you need to do is include the file in your .csproj files just under this line

Then, after the build is finished, the obj folders of your projects are populated with all necessary files.

Prezentacja Continuous Delivery

Szymon Pobiega — Fri, 30 Mar 2012 07:38:08 +0000

Wszystkich zainteresowanych tematyką Continous Delivery zapraszam na moją prezentację podczas 73. spotkania KGD.NET. Osoby, które nie mogą dotrzeć do Krakowa mogą, dzięki uprzejmości portalu VirtualStudy.pl oglądać sesję na żywo on-line. Strona spotkania na VS znajduje się tutaj.

Sesja jest wprowadzeniem w tematykę Continuous Delivery. W kilku słowach można powiedzieć iż CD jest to podejście do tworzenia oprogramowania kładące nacisk na traktowanie każdego commita jako potencjalnie wdrażalnego na środowisko produkcyjne. Każdy commit jest budowany, poddawany wielorakim testom (jednostkowym, integracyjnym, akceptacyjnym etc.), a ostatecznie wdrażany produkcyjnie.

Continuous delivery kładzie ogromny nacisk na automatyzację wszelkich czynności związanych nie tylko z budowaniem i instalacją aplikacji, ale także z przygotowaniem odpowiedniego środowiska.

Podczas sesji zaprezentuję konkretną implementację idei continuous delivery, którą zbudowałem wraz z moim zespołem w ramach ostatniego projektu. Jest to implementacja niskokosztowa (zero płatnych narzędzi) stworzona głównie w oparciu o PowerShell.

Zapraszam także na drugą (a właściwie w kolejności chronologicznej — pierwszą) sesję 73-go spotkania: Pogromcy mitów: Czy specjaliści od użyteczności i programiści mogą ze sobą zgodnie współpracować? Marcina Czyżowskiego.

QCon day two

Szymon Pobiega — Mon, 12 Mar 2012 05:26:45 +0000

Simple is not easy

Day number two started with a keynote by Rich Hickey (@richhickey) the author of Closure programming language. Honestly, I was technology marketing stuff like if Uncle Bob is speaking about Closure. Surprisingly to me, it was not the case. Rich didn’t even mention Closure. Instead, he was taking about what does it mean to be easy versus what does it mean to be simple.

Easy is something that is nearby (based on ancient origins of the word). It means that you don’t have to spend time to do what’s considered easy. For example writing stateful code is easy. Simple on the other hand is something that contains just one element. That property makes simple things understandable. You can reason about them. Each time you introduce another element into the concept, you make it more complex and thus harder to understand.

What surprised me was, Rich had courage to (just like Dan North and Greg Young did yesterday) say that automated tests alone are not enough to make your software easy to change. What makes it easy to change is ability to reason about the code.

Last but not least, Rich went through the list of things that are complex in software development (like classes, ordering of concepts, ORMs etc.) and, for each one, showed what simple concept can be used instead. During this part of presentation he actually started using Closure as an example (which was nice).

Finance: infrastructure and modelling

For the second and third slot I’ve chosen the financial track. I turned out to be great decision. Both sessions (by Todd Montgomery and Andrew Stewart) were very good. Todd (@toddlmontgomery) was talking about innovative ways of implementing reliable many-to-many communication for financial market solutions. The key to achieve really high throughput and low latency is getting rid of the message broker from the message transport path which means moving to peer-to-peer messaging. That’s great, but what about the reliability? Who would now be responsible for persisting messages and retransmitting in case of failure? Todd introduced a concept of redundant message stores. The publisher would first store the message and then send it to the receivers. If receiver fails or simply can’t cope with the rate messages are being sent, he can switch to ‘pull’ mode to fetch messages from one of the stores. Also, in such topology it is receiver who’s responsible for coordinating its own the failure recovery. This makes messages store a very simple thing to implement (compared to a broker).

Andrew Stuart was talking about the other side of the same coin – the modeling. Every system inevitably consists of a model and an infrastructure that allows the model to be executed. Fundamentally, every software system is a simulation of reality of some kind. The presentation was focused around the process people tend to go through when starting with modeling in software. It begins with euphoria, goes through all the way down to depression and (hopefully) ends with acceptation – acceptation that it’s just a model, not The Model.

Getting rid of these damn locks

For the last slot of the day I also have chosen the finance track and, again, it was a very good choice. Fortunately I was quite early as the room quickly became literally packed. The session about lock-free algorithms was presented by Martin Thompson (@mjpt777) and Michael Barker.

It started with a brief introduction to modern processor architectures. The key takeaway from this part is, the memory has a hierarchical structure and as the capacity increases, so does the access time. The other thing worth remembering is memory content is stored in cache in a structured form called lines and only one CPU core can claim a single cache line at a time.

Then speakers moved to explaining why locks are bad. This is pretty straightforward as the key problem is locks require kernel-level code to be executed in order to ensure atomicity. Switching between user mode and kernel mode is very costly comparing to arithmetic operations. Conclusion? Locks should be avoided at all cost when building high performance software.

It turns out that it is not as hard as people think to build a lock-free data structure like queue. In fact, Martin and Michael were able to fit the full code in two slides. The result was much faster than the classic version with locks but this was only the beginning as the code was missing a bit of ‘mechanical sympathy’ – it did not take into account how the processor works internally. How can we change this? Guys showed us a few very useful tricks:

Division is a very costly operation. It turns out in some circumstances (number is o power of 2) it can be replaced with a simple bit operation
Compilers tend to lay out class fields close to each other in memory which makes them end in same cache line. Even though each thread modifies its own value, cache line ownership is being transferred forth and back and core have to access memory to read the value

There were also other neat tricks shown which I do not remember now but when in need I can find them on Martin’s blog.

QCon day one

Szymon Pobiega — Wed, 07 Mar 2012 23:17:17 +0000

The day has not started especially great. I’ve overslept but fortunately I’ve managed to get to the venue on time. Well, actually, ahead of time. But let’s move to the interesting stuff.

The organizational side of the conference is great. There are no painful queues for anything, including men’s toilets. There were small snacks (rolls and stuff) in the morning, quite tasty lunch at noon and a cake in the afternoon. Also, the session evaluation mechanism is nice – they use iPhones so that people leaving the room can tap green, yellow or red area as their feedback. When I am writing this, I am still in the venue and I looking forward to the party across the street.

Stefan Tilkov’s session was the first one I attended (after the keynote by Martin Fowler and Rebecca Parsons which deservers a post on its own). What I liked most about the session, even before it started, was that the speaker had one simple idea that he wanted to sell us. The idea was to break apart huge systems into systems of small and focus systems. The reasoning behind this is the rules that apply to software development are not created equal. Or to be precise, you better make them not equal. Some of them you want to enforce on strategic level and other are merely tactical decisions. With one huge monolith you can’t really differentiate strategic from tactic. With system of systems, you can have rules that apply to whole portfolio of systems (strategic) and ones that you apply (and are adjusted) on a system-by-system basis.

The benefit of having stable strategic rules is your systems are able to communicate to each other (because they use the same principles in their APIs). The benefit of tactical rules is when building a system you can use the technology stack that fits best the requirements at hand (as long as it does not violate strategic rules of course)

The problem is, when starting a new system you have quite different objectives than you will have after 3 years. In the beginning you want to be as agile as possible with one small simple and homogenous application that does something meaningful. At some point in time, the objectives start to shift towards enabling heterogeneity, decoupling and other cool architectural stuff. The trick is to don’t overlook the moment objectives shift but adjust as soon as it comes by breaking up the growing monolith when it is still feasible.

Last but not least, Stefan provided some guidelines on how would we implement such system of systems. To me, this guideline seems to be 99% in line with what I’ve learnt from Udi Dahan’s presentations (and what I believe is THE TRUE about software engineering). In a nutshell, you should not be afraid of data replication from the producer (which owns the master copy) to consumers (which use it to execute their logic) and you should provide a consistent user experience by integrating the whole system of systems in the presentation layer. The interesting idea Stefan suggested is you should use pages and links (resources and hypermedia in REST lingo) rather than heavyweight portal solutions to perform this presentation-layer integration.

This was an ‘I love it because I agree with the presenter’ kind of session. Most of the stuff I’ve already heard about, mostly from Udi. It does not mean, though, that I did not like it. Quite the contrary – I enjoyed it very much. For me the key takeaway was the realization that REST is a perfect approach to use for presentation-level integration.

The second session was the one by Jesper Richter-Reichhelm. It was about Facebook flash games. Not a good subject for architecture track you say? Then you’re wrong. Jesper’s company (Wooga) host games that have to process > 50.000 state update requests per second. That is a lot. The session discusses a series of incremental changes to the architecture of a game system that allowed scaling from 250.000 users to over 2 million as well as the culture and approach that allowed such changes.

First of all, these changes were not applied on some common infrastructure that all games shared simply because there is no such thing at Wooga. They believe in share-nothing principle. The trade-off they intentionally did was sacrifice code reuse to get freedom of innovation in each new project. That seems to me a reasonable strategy for a small company that operates in the very fast-changing market.

Second, on technical side they moved from PHP to Ruby to Erlang and back to Ruby (with Erlang elements) with regards to programming language while moving from MySQL through Riak to S3 with regards to persistence. What I liked most is the ‘don’t solve the problem, just get rid of it’ approach. Instead of going down the database scaling path, they just changed the architecture so that database is no longer the limitation. This is the mindset we should have with regards to anything we do as software engineers.

So far I’ve enjoyed the conference very much. There were other session not so great but the average quality is very high. Stay tuned and expect further posts.

My take on the repository pattern

Szymon Pobiega — Wed, 29 Feb 2012 05:20:23 +0000

There’s quite a lot of anti-infrastructure buzz around recently. If I remember correctly, it started with anti-ORM movement. It was quickly followed by the anti-IoC uprising. While I can understand some points of these two, the most recent anti-abstraction (and anti-repository in particular) campaign started by Ayende does not make any sense to me. This post is about why.

Buzzwords

The ‘repository’ name is quite commonly used for something that provides CRUDish data access methods for objects of some kind. For some reason people think their architecture will magically get better if they use fancier names. That’s why they call plain data access objects repositories. Unfortunately nobody can claim ownership over the name (and the pattern) and punish its misuse.

Context is king

Critics of repository pattern usually attack it alone, without the context of whole domain model pattern group. Indeed, it does not make any sense to use it alone because it leads to the aforementioned data access object pattern. It is much better to use the data access library (be it ORM or NoSQL API) directly.

When do you need repository

You need a repository when you want to define meaningful aggregates in your domain model. This is the only way to properly encapsulate the retrieve and store operations. Why this is so important? Because aggregates are boundaries of transactions and unit to locking. This means, you cannot perform atomic operations on more than one aggregate at once (even aggregates of same type). Why would you want to voluntarily agree on such a limitation? The obvious answer, which is the desire to prepare for data access technology changes, is not true. This happens really rarely. The correct answer is, you would (and I did a couple of times) do it because it helps you decouple concepts in your model. And yes, there are models so complex that it pays off.

While it is good idea to keep bounded context consistent with regards to modelling approach (either use or not use domain model patterns), it is perfectly legal to mix and match persistence implementations within a bounded context. Thus you can have one repository that uses event sourcing and another that uses plain old SQL database.

How do you use repository

The classic usage pattern of repositories is following

var aggregate = repository.Get(id);
var result = aggregate.ExecuteLogic(params);
repository.Store(aggregate)

You get the aggregate instance from the repository, then you execute some business logic (possibly returning a value) and finally you store the changes in some database. Transactions are handled by the repository thus enforcing the atomicity of operation.

But what about reading the data, you may ask. The answer is, you don’t use repository to read data for displaying on the UI. In such cases you hit your data access library directly. Nobody wants another abstraction layer here.

When you don’t need repository

In all trivial cases not complex enough to justify modelling using domain-driven design patterns. Fortunately you don’t have to make the decision on a system level. It is perfectly legal (and indeed encouraged) to use different approaches in different bounded contexts depending on their complexity. In some you would use repository (and all related patterns) while in others you would use your favourite data access library directly.

What you should definitively not do when using repository

Never ever create generic repositories or generic base classes for them. Never. If you find yourself doing so it means your repository became a data access object. Better delete it, quickly.

The simplest home budget application

Szymon Pobiega — Tue, 14 Feb 2012 06:07:26 +0000

As you probably all know, it is Excel. I would argue that is is also the most powerful one. I want to share with you a spreadsheet I created last weekend to finally be able to predict my financial condition. I wanted to have a single chart that would plot the expected balance of my account on each and every day of the coming year by taking into account

planned expenses and incomes
average monthly cost of living (mostly food and entertainment)

Logically, the task is quite simple. You list all your expenses and incomes in a table with amount and date. Then, you list all days from now till the end of the year. Finally, for each day the expected balance would be the sum of expense and income table entries with dates earlier than or equal to current.

The problem is how to implement it in Excel. I was hoping to use SUMIF formula but it turned out that it only accept very simple conditions that can’t contain variables. I nearly dropped the whole idea when I learned about a thing called ‘array formulas’. They are similar to apply operator in functional programming — they apply a formula to each cell in a range. Here’s an example:


{=SUM(IF(Sheet1!$B$8:$B$38<=B2;Sheet1!$C$8:$C$38))}

This tells Excel to apply IF(cell_value<=B2;cell_value;0) formula to all cells in Sheet1!$B$8:$B$38 range and then sum up the results. Have you noticed something unusual? The curly braces? Yes, they distinguish array formula from ordinary one. The trick is, you can’t just put the braces in the input field. To add them you need to press Crtl+Shift+Enter when focus is in the input box. Easy, right?

The results of these simple steps, at least to me, look quite amazing. Here’s my chart for this year:

And to draw yours, you can download a ‘template’ from here. And this is just the beginning. I am planning to add ‘tentative’ feature so that you can assign probability to expenses and incomes and the end result would be three lines instead of one: optimistic, pessimistic and expected.

Automated deployment security concerns

Szymon Pobiega — Fri, 03 Feb 2012 07:37:11 +0000

This post is a part of automated deployment story

One of the blockers to widespread adoption of automated deployment tools is the fear that they cause greater security risk than humans executing a written deployment procedure. The greatest of fears is that an attacker would be able to push a malicious version of binaries to the production environment.

If you want to succeed implementing an automated deployment solution you must ensure at least same level of security as when humans manually copy binaries.

Who can deploy?

When there is no automation, the deployment is performed by designated humans. For testing environment it can be the QA manager, for production it is usually an operations team. They (and only they) are in possession of credentials required to log on to the target environment machines to copy the binaries and perform other deployment-related tasks.

People who have just begun automating the deployment tend to think that, since everything can be automated, the deployment process can be started straight from the build agent without any human action. This was also true in my case. Fortunately some wiser people reminded me about how important is to be able to name the person (not a machine) who was responsible for particular deployment.

The rule of thumb is, you can (and should) automate everything, but two things. First is starting the whole procedure. There should be a person that has to hit ENTER key in order to start deployment. We’ll be the one to blame if something goes wrong (for example upgrading the production site during peak usage hours). The second thing not to be automated is authentication. You should never store production (or even testing) environment credentials in order to be automatically used by the script. Whenever credentials are required, the script should ask the user to provide them. Sometimes it is possible to store them temporarily in memory so that user does not get prompted for same credentials twice.

What can be deployed?

Usually the more layers of security, the better. Should one get compromised, the other can prevent the disaster. Beside controlling who can deploy, it is also worth controlling what can be deployed. The easiest thing (and this is what we have actually implemented) is digital signature-based verification. A binary package is signed using a certificate stored on the build agent. The corresponding public key along with a gateway script is securely installed on all machines of the environment.

The only remotely accessible endpoint that is exposed by target environment machines is the aforementioned gateway script. This ensures that an attacker can’t bypass the security measures put in place. One can only trigger the deployment on the machine via this script and the script ensures that deployment package signature is verified against stored public key of the build agent.

Tools

Unfortunately there is no command-line tool to sign and verify signature built into Windows. That’s why PackMan was born. I mentioned this tool before in context of building a package. When building a package, PackMan also calculates the hash of the data and encrypts it using private key from provided certificate. It can be done with a command like this (MSBuild variable syntax)

PackMan.exe -i d:$(PackageDir) -o $(OutDir)\Package-$(BuildVersion).zip --cn DeployerCert -a create

When asked to unpack, PackMan first verifies the signature using a provided public key (PowerShell variable syntax)

PackMan.exe -p ${package_store}\${package_file} --vcn DeployerCert -a unpack -d ${tmp_package_dir}

This ensures that package is authentic and not corrupted.

Deploy based on external description of the environment

Szymon Pobiega — Tue, 24 Jan 2012 08:27:55 +0000

This post is a part of automated deployment story

On of the problems with many simple deployment solutions is, the structure of the target environment is embedded into the deployment scripts. This was also the case with the previous, batch based, version of my deployment process. With the advent of PowerShell, everything changed.

Commas

CSV is one of the simplest formats for representing tabular data. It’s easy to read, easy to edit (also in Notepad) and it behaves nicely when stored in VCS. All these properties make it an ideal candidate to be used to describe the deployment environment. Last but not least, PowerShell has very nice built-in features for handling CSV files: Import-Csv, Export-Csv, ConvertTo-Csv and ConvertFrom-Csv. The most interesting one is Import-Csv as it allows to load data stored in file into an object form with one object per row and one property per column. It makes loading entire environment description file as easy as

$machines = Import-Csv environments.txt

The structure of the file is also quite simple. Because I deploy to DEV environment quite frequently (10+ times a day) and that it is done by an automated process, I’ve chosen to store credentials straight in the config file.

IP, Environment, Roles, User, Password
192.168.0.1, DEV, Web|App, devUser, p@ssw0rd
192.168.1.1, TEST, Web,,
192.168.1.2, TEST, App,,

Given these, you can imagine that getting the list of machines in particular environment (you need it to know where to deploy) can be done in another one-liner

$target_machines = $machines | Where-Object { $_.Environment = $target_environment }

Roles

You have probably noticed a column called ‘Roles’ in the description file. A concept of role is key to my deployment strategy. I borrowed the name from cloud computing lingo but the meaning is slightly different. My role is a named set of things that are deployed together and form a logical whole. The current list of roles in my application include web, tools (which is an odd name for application server stuff), tests (this role is installed only on DEV) and db.

As you can see in the sample environment description, a DEV machine serves both roles while in test environment there’s dedicated machine for each role. You can imagine, that production would probably have 3 or 4 machines serving web role and maybe 2 for application role. Having a simple file that has all this information really helps organize things.

Orchestration

Looking from 10.000 ft, the process of deploying one role to one machine is following

stop the role
update the binaries for this role
start the role
(optional) verify health of the role

Given that we have multiple machines, each of which potentially serving multiple roles, the question arises how do we orchestrate the whole process so we minimize the down time. The answer, as for all difficult questions, is, it depends. Because it depends, we want to abstract away the concrete orchestration and be able to pick the actual implementation based on requirements at hand. In my project I’ve identified two distinct cases.

If I don’t have to change the structure of transaction database, I can upgrade the machines one by one. To achieve zero downtime I need to fake the response for balancer’s health enquiry telling it that the machine is down before is actually is. This way clients will be served normally before load balancer picks up the faked ‘down’ response and actually removes the machine from the cluster. Then I can safely upgrade this one machine. Last but not least, I have to wait some time before load balancer figures out the machine is up. Voilà! A super-simple zero-downtime deployment.

In case I don’t need to change the structure (and assuming I can’t write code that can work with both structures) I want to upgrade all machines in the environment as quickly as possible. This is where PowerShell v2 jobs come in handy. You can use Start-Job to virtually deploy to each machine in a separate thread of execution. Because the bulk of work is done not on the coordinating machine but on the target machine, this literally cuts the deployment time to the amount it takes to deploy to one machine. Cool, isn’t it?

The release candidate repository

Szymon Pobiega — Thu, 19 Jan 2012 16:53:49 +0000

This post is a part of automated deployment story

I am sorry you have to wait so long for a new episode of the story. The truth is, this episode was written a week ago and saved as a draft. Just before publishing I got an e-mail from the IT department that the solution I proposed (using SharePoint site) is not acceptable from the security point of view. They are not going to allow any access to the site from an automated process accounts. Period. So the blog post went to trash but not the idea. Here it is, reborn, better than ever!

Release candidate repository

I’ve taken the idea of release candidate repository from the Continuous Delivery book. The idea is, release candidate is not a term describing a binary package generate just before releasing, waiting for final tests and go-live flag. Instead, a Release candidate is every binary that passes unit tests (or commit stage tests how book authors tend to call them). The candidate then goes through various stages of the deployment pipeline, passing (or failing) integration tests, automated user acceptance tests, load tests, usability tests etc. During this journey, a candidate is deployed to various environments. Finally, a successful candidate ends up being deployed to production. As you probably expect, I was in desperate need of a tool that could track my RCs from the very beginning to the end of their lifetime. Buying an expensive and have-it-all tool was, of course, not an option.

Release Candidate Tracker

It took me one afternoon to hack a quick and dirty solution. As always, you can download it from github. Please don’t complain about the code quality. I know it’s not the cleanest code on the planet, but it works (or sort-of). RCT uses an embedded RavenDB database to store information. The database files are stored in the App_Data folder. If I understand Raven’s license correctly, you can use RCT anywhere you want, also in commercial environment.

Workflow

Here’s the workflow describing the typical usage scenario of RCT. First, the build script (MSBuild in my case) creates a release candidate after successfully running unit (commit stage) tests. To achieve this, it uses curl tool to call RCT API.

$id = .\curl -s --data "State=${state}&VersionNumber=${version}&ProductName=${product}" "${server}/ReleaseCandidate/Create"
if ($id -ne $null) {
    .\curl -s --upload-file $scipt_file "${server}/ReleaseCandidate/AttachScript/${id}"
}

The first call creates a RC entity while the second one attaches a generated deployment bootstrap script. At this point, a candidate is in initial UnitTestsPassed state. You can see it on the release candidate list

The subsequent stages exercise the candidate using various test suites: integration, user acceptance and so on. However, before the candidate can be tested, it has to be deployed to a suitable test environment. Here comes another feature of RCT — the deployment bootstrap script. You can download it simply by clicking a ‘Deploy’ link on the candidate list. If you want, you can even associate the .ps1 extension with PowerShell so that it will be automatically executed. The script (which will be covered in detail in later episodes) starts the deployment process. Eventually, a deployment script completes the deployment and updates the state of the candidate. There’s another API call and another script that does this

.\curl -s --data "Environment=${environment}&VersionNumber=${version}" "${server}/ReleaseCandidate/MarkAsDeployed"

After executing the tests, the state of the candidate needs to be updated to reflect the result. Here’s a script for this task

.\curl -s --data "State=${state}&VersionNumber=${version}" "${server}/ReleaseCandidate/UpdateState"

Eventually, is the candidate manages to successfully pass all the tests, it can be potentially deployed to production. Of course not every successful candidate ends up on production. Each change of candidate state is reflected on its detail view page

Any contributions to RCT are, of course, more than welcome. Happy deploying!

Building the deployment package

Szymon Pobiega — Thu, 05 Jan 2012 09:24:56 +0000

This post is a part of the automated deployment story.

The first custom step of my build process is building the deployment package. Starting from two applications in the solution it is impractical to just copy over a bunch of DLLs. Much better idea is to package them somehow so they can be easily handled as a whole. There is a number of packaging technologies available for .NET applications, including:

None of them is a complete and perfect solution. First two are biased towards packaging and managing reusable libraries so they put emphasis on versioning and enabling usage of packages in IDE and in the build process. Web Deploy is focused on, well, web deployment and it is lacking good support for any other application type.

Web Deploy

In my solution I’ve chosen Web Deploy because it few reasons. First, it was already there since it was the foundation of old deployment scripts. Second, it has a very nice feature of so-called publishing a web application. You may know this feature from VisualStudio as it is available from context menu on web projects. Basically, it removes all the files that are not necessary to run the application (like .cs, .csproj).

There are two central concepts in Web Deploy: operation and provider. Operation describes what to do. There are three (only!) possible operations:

dump – displays information about an object
delete – deletes an object
sync – synchronizes two objects

Web Deploy comes with a great variety of providers. Providers implement specific deployment steps like changing the machine.config file or putting an assembly to GAC. The most important one for me is the package provider. It allows to pack a specified web site in IIS into a zip file and clone it somewhere else. What you can’t read on the documentation page (but can find on the Internet, of course) is, you can build similar package via MSBuild. Do do so, just call

MSBuild "ProjectName.csproj" /T:Package

After your main build process completes. The output is a nice zip file containing all the information necessary to deploy the web application.

DRYing the build script

For each application I deploy I need to call some packaging routing in the build script. This can quickly become a copy-pasted spaghetti. Fortunately I found out that MSBuild supports iteration. Here’s how you define the collection of elemenents

And here is how you call a specific routine on all of them

Nice, isn’t it?

One to rule them all

Bare Web Deploy would probably be enough for three or four web applications. As you remember, in my case there is about a dozen of them and another dozen of console tools. That’s why I decided I need another layer. Later on it turned out to be a good idea also for another reason — security. During the audit process one of the auditors pointed out that we don’t have any mechanism to guarantee that the binaries deployed to production are not forged.

I thought it will be a trivial task to implement — just use a command-line tool to zip all the packages (and console applications, each in it’s own folder) and another command-line tool to sign the zip file digitally. Unfortunately it turned out that there are no built-in tools on the Windows platform for these simple tasks. I didn’t like the idea of installing applications like 7zip or similar on production servers so I decided to create a custom tool for the task. This is exactly how PackMan was born.

PackMan is a quick and dirty tool for packaging a bunch of files together in a digitally signed zip file. Of course it also allows you to verify the signature and unpack the contents. PackMan is stream-based so it has no problem supporting quite large packages (mine has about 120 MB). It uses Windows PKI to retrieve the keys for signing and verifying.