Tags: , , , | Categories: Articles Posted by RTomlinson on 11/12/2012 1:16 AM | Comments (0)

NuGet isn't just a means of acquiring and sharing libraries externally. It's a great way to distribute your shared libraries internally within and across your development team(s). There’s no need to checkout updated copies of a shared library and build it on a developers machine and re-reference it within Visual Studio. I’ll show you how to setup TeamCity as a NuGet server to make sharing dependencies a little easier.

Setting up TeamCity

It’s extremely simple to enable TeamCity to act as a NuGet Server.

Go to the Administration section and select “NuGet Settings” and enable the NuGet server.

teamcity admin section

You will see that TeamCity has it’s own WCF service URL called the “Authenticated Feed URL”. This is what we will use to tell Visual Studio where to look for our NuGet feed (more on this later).

Configure your build to produce a NuGet package

If your project configuration in TeamCity doesn’t already have a build that compiles your project you will need to do this first. In this example I’ll simply use the built in Visual Studio build runner type that uses MSBuild to compile a solution.

nuget package runner type

Once you have a compiled binary you can use TeamCity’s built in NuGet Pack runner to ouput a .nupkg (NuGet package) of your compiled library. TeamCity will ask for a Specification file and this is usually a .nuspec file that you add to your project that details detailed information about the package. However, you can also simply use the .csproj file to provide this information.

specification file

The two build configurations are shown below:

build steps screenshot

Configure Visual Studio to use TeamCity NuGet server

Firstly open up Visual Studio and open up the NuGet Package Manager. At the bottom left selection “Settings…”.


In the “Package Sources” dialog add a new source and specify the source as the TeamCity feed URL that I mentioned earlier.


Now when you go back to manage NuGet packages you will have the new package source as an option.


Now when your team updates a shared dependency it will be built by TeamCity on checkin and a NuGet package is produced and it will be updatable from within Visual Studio using the package manager.

Tags: , , , | Categories: Articles Posted by RTomlinson on 10/25/2012 6:28 AM | Comments (0)

I'm still amazed that there are software companies out there that are delivering software far too infrequently. Most of the time there are no valid excuses for monthly or quarterly (or more) deployments. If the business isn't demanding a faster time to market then the Dev/Operations team should be continuously evaluating and improving their processes for the benefits that continuous delivery give.

Historically writing, testing and delivering software have been scary for me and the teams that I have worked in. In the past I've worked in teams where we would write a month's worth of software, have a test team test the release, fix those bugs, test again and then release. The process was long and painful and we dreaded the release and the following few days were nervous ones.

Since then I've been on a path to continuous delivery and work with a great team who see the value in doing so.

Why releasing often is so important

Here's just a few points:

  • Continuous feedback - With every check-in we build and run tests (unit and other variants) and continue in our deployment pipeline. The sooner developers code is integrated, compiled and tested the sooner we can fix issues. This also holds true for deployments.
  • Problems are localized - When problems do occur it's usually pretty easy to spot if only a few changes are being deployed at any one time. With larger deployments, if the shit hits the fan, then it's going to take longer to diagnose and resolve.
  • Competitive advantage - Not much explaining here. If you can release features incrementally to your customers the advantages are two-fold. They benefit from the features themselves and they benefit from a learned user experience. That is to say that smaller changes are easier to adapt to than larger rollouts of features.
  • Deployment confidence - The more you do something the more confident you get in doing it. The same goes for most tasks and skills. 

How often is often?

This really depends on many factors but when you have changes waiting daily there really isn't any reason not to release daily. There are many release strategies that you should consider. The most common are release branching or releasing from trunk. In the case of the latter it is common to use feature toggles for unfinished or unreleasable code but this is too big a subject so I'll save for another post.

At tombola, we release daily for each country. Everything is driven from our TeamCity build server that runs custom MsBuild scripts to compile, transform configs and deploy (using MsDeploy) to several environments (including the cloud). 

teamcity build

For live deployments we do blue/green deployments. That means that we hit the run button for the live configuration that is inactive (see image above). The load balancer will then drain out the users from the active node and bring the inactive node up to make it active. The benefit of this approach is the ability to roll back very quickly if we have any issues simply by switching the nodes back.

How to get there?

The process of getting to daily (or even weekly) releases doesn't have to be taken in one leap. Continuous integration is usually the first step. CI products like TeamCity are free and extremely configurable and easy to get up and running. Start by building your product on check-in and informing your developers when issues occur (using something like TeamCity tray notifier). Then move on to automated deployments to your developments environments. This will give you the confidence in the process over time to add automation to your stage/QA deployment pipeline.

Ultimately the key is to evaluate your processes. If you have processes that take a long time and hold the pipeline up then look at addressing those first. If you have a test team that is a bottle neck, look at what you can automate with regard to testing or look at who's remit testing is and see if you can disperse it amongst other teams.

Dev/Ops should be introspective and be focussed on continuous improvement in their development and deployment processes. Your deployment process is never perfect and is never set in stone.

Tags: , | Posted by RTomlinson on 5/22/2012 5:19 AM | Comments (0)

The software release process usually involves the deployment of a mixture of bug fixes and feature releases. Bug fixes usually come more frequently than features (or large abstractions) and software teams often hit the decision point to consider how they release small fixes when larger/longer fixes or features are in development. In an environment where the team are doing branch by feature then the pain is eased somewhat. Features are done in completely seperate branches are more often than not, using this branching strategy, fixes are done on the mainline (trunk). In a team where continuous delivery or continuous deployments are employed then the problem becomes more complex.

Release branching

Release branching involved creating a completely seperate branch where production ready code (or potential production ready code) is merged to and deployed from.

With this strategy the benefit is that the release manager can merge over only the chosen revisions that contain bug fixes and satisfaction comes from knowing only known revisions are applied and more importantly feature revisions are excluded.

Adopting continuous delivery/deployment means that this adds a manual step to the process. It's also not error proof as it's often difficult to exclude feature revisions that are checked in and the management and maintenence, over time, can become painful.

Builds, tests and deployments can then be done from the "stable" release branch to promote to staging or live (production) environments and development environments can continue to use trunk.

Branch by abstraction with feature toggles

Another method that can be employed is to use a mixture of branch by abstraction with feature toggling. This allows you to maintain a single trunk (WIN!!) and apply bug fixes on the trunk but larger or longer fixes of features can be effectively toggled off until they are ready to be deployed. The team can continue to fix and check in without having to worry that a half implemented feature will make it to live.

Branch by abstraction involves abstracting classes away from their implementation whilst in a development environment yet still maintaining the current class in the live environment. In practical terms that could mean creating a new class that implements an interface and (if using IoC) inject your feature class rather than the existing implementation.

Given the scenario whereby we're implementing a new feature for card payments:

  1. We would create a completely new concrete implementation of ICardWithdrawalService as FeatureXCardWithdrawalService.
  2. Create a configuration toggle. This could simply be an app setting of true/false in a Web.Config or App.Config with a transform for each environment targetted.
  3. At the point of IoC bootstrapping register the FeatureXCardWithdrawalService instead of the existing implementation to be injected.
  4. Where view (front end view) specific feature changes are applied the same toggle can be checked (ideally using a central helper to manage these).

Developers and release managers need not be concerned with branching and merging with this strategy and thus time is saved in doing so. However, concerns come from knowing when a toggle should be employed and the management of toggles throughout the codebase. Developers should be encourages to checkin early and often and it could be tempting to reduce the amount of toggles by not checking work in for longer fixes until it is complete.

The quality gate

Both strategies are not without dangers. The decision as to which is best is very much dependant on the product, the team, the release strategy (and amount of releases), the environment etc. The key in both is the quality gates at each step in the continuous delivery/deployment process. Ensuring that each stage of the test pyramid provides adequate coverage or your product and your existing features will define the quality and readiness of a release.

Further Reading