Setting up WCF-Service developement using Resharper, TeamCity & Subversion


I'd like to get some feedback from the community to find a good working method and avoid predictable problems before competely automating everything.


I'm setting up a development environment for a team that's quite new to continuous integration & code branches (in SVN).

- We're developping in VS (2008) a series of WCF services, that must be able to evolve independently of each other (even though they do use each other).

     --> this means that for each service there will always be only 1 version in production.  (framework & published interfaces may have several versions, backwards compatible or not)

     --> each service will build upon a shared framework

     --> each service will expose a 'ServiceDomain' assembly that will be shared by applications using the service.

              This assembly will contain data and the behaviour specific for that data valid in all contexts.  (to avoid duplicating this behaviour)


         deployed components - evolved versions.jpg

              -->  Service A has gone through some updates while its consumers were released in between those updates.

              -->  They all have a different ServiceDomain versions, but they are all backwards compatible (in order for this to work).

              -->  If not possible to stay compatible, Service A needs to increment its major version-number and all clients need to be updated...


  --> We use a convention to increment the major build version only if we can't stay backwards compatible.

        version format : Major . minor . fix . revision

             - minor is incremented on each normal release (every iteration).

             - fix is incremented during an interruptive releases to fix something that can't waint until the next release.

             - the last version number refers to the revision in SVN.

Referencing Artifacts

The main issue here is how to deal with references to projects outside the solution.

   - Thrid Party References

   - Our other WFC services

The projects will NOT reference the artifacts placed on a shared folder, created by the CI.

  --> because when a change is required in 2 related solutions, I have to commit (and let CI create the artifact) before I can test the effect in the consuming solution.

To deal with this we create following folder structure

>  Solutions

     > Next Release

           > SomeService    > 1.x > Solution > SomeService.sln

           > AnotherService > 1.x > Solution > AnotherService.sln

           > Framework       > 1.x > Solution > Framework.sln

                                     > 2.x > Solution > Framework.sln

A post-build target (added to our project templates) will copy the artifacts to a folder next to the 'Solution' folder

           > SomeService    > 1.x > Solution > SomeService.sln           <-- source code folder

                                             > Application > SomeService.dll        <-- artifacts folder

When another service needs a reference to 'SomeService.dll'.  it will refer to ..\..\..\SomeService\1.x\Application\SomeService.dll

  --> making clear that it refers to the latest version of the 1.x branch.

The code gets committed to an SVN structure looking like :




                 | ------ 1.x

                 |          |

                 |          |

--> the folder structure refers to the SVN structure and the build script ran by TeamCity can recreate the folder structure when changes get committed:

> Solutions

     > Next Release

           > SomeService    > 1.x > Application > SomeService.dll

           > AnotherService > 1.x > Application > AnotherService.dll

           > Framework       > 1.x > Application > Framework.dll

                                     > 2.x > Application > Framework.dll

--> the build configuration can then do an SVN checkout in the '1.x' folder of  'SomeService'

> Solutions

     > Next Release

           > SomeService    > 1.x > Application > SomeService.dll

                                                Solution      > SomeService.sln

           > AnotherService > 1.x > Application > AnotherService.dll

           > Framework       > 1.x > Application > Framework.dll

                                     > 2.x > Application > Framework.dll

--> building the most recent code, overwrites the Artifacts for this solution.  Plus it copies them to a shared folder :

      > Latest Artifacts

           > SomeService    > 1.x > Application > SomeService.dll

--> As each application gets build, the 'Latest artifacts' folder will always contain ... the latest artifacts.

     This allows developers to copy this folder over their local 'next release' folder to overwrite their local artifacts with the latest.

     It also provides a safe (generated) structure to SVN checkout solutions that you've never worked on before.

--> also part of the buildscript is packing all files & configuration needed to get the application deployed into a .zip file which is also placed in a shared folder:

     > All Packages

           > SomeService    > 1.x > Packages >

--> this will allow a deploy script to find this .zip and unpack it somewhere to get it deployed (automatically or manually)

This is Part I of the setup: Adding new funcitonality to the latest version of an application

Part II will be about deploying them

Part III will be about fixing deployed applications (to UAT or PRD) when developement for the next release has already started.

I expect this post to be edited and refined in the comming days to make the plan more clear & readable.

--> but don't hold back if you already have comments or questions.



Please sign in to leave a comment.