2

Situation - We have a .net mvc solution with WCF layer. the solution has about 20 odd projects that get compiled into DLL. the site is running on SQL server 2008. we maintain the SQL scripts in the solution folder as versions. So we have SQL scripts eg. version 1.0.0.0 to lets say latest which is 3.0.0.1.

the solution is source controlled in TFS, we also use TFS to manage the work items, bugs etc etc. SQL script files are also in TFS

Question - the question is that do we need version numbers on the assemblied i.e. dlls aswell. Our DLLS are not exposed in any way or from to the outside world they are just in the runtime of the mvc app. we do not expose the WCF to outside clients,again its just used by the mvc app.

the deploy process is simplly the latest code against the latest db, so when we deploy we check what version the db is in and run a tool to upgrade it to the latest version that is in the db project in the solution.

One of our senior architects is saying that we should maintain the version numbers in the assemblies aswell. I am saying that we dont need any version numbers in the code. beacuse TFS manages that. when we release we just deploy the latest code with the latest assemblies/ deploy package.

I have not come accross the assembly versions unless them assemblies where released to the outside world (if you know what i mean)

please can you suggest... Also note we dont do feature development its just version numbers so that we know what version a particular DB is at.

Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Sunny
  • 53
  • 5

2 Answers2

1

I would prefer the security of knowing and being able to double check versions. If there were a problem with the publishing process, or there were a bug that manifested itself that appeared to be a publishing problem I would want to rule things out as quickly as possible. I also think that it's so easy to implement you've spent more time discussing and thinking about it than you would have actually spent doing it, and there is no down side to it that I can think of.

Alex
  • 12,749
  • 3
  • 31
  • 45
  • we are moving towards auto deployment using TFS automated builds and deploy process, doesnt this mean that our manual version numbers would interfere, or atleast we would have to do some more work in changing the build scripts etc. If the process is latest code against the latest db, dont understand why would we need version numbers in code. we cant deploy code which is not latest. - cheers – Sunny Jan 22 '13 at 16:09
  • I understand your situation. I am not saying you need to, I am saying it might prove helpful someday and it's easy enough to do. Although I've never gone this route, couldn't you just use the wild cards in AsssemblyFileVersion? That wouldn't require any changes to your build scripts or process. – Alex Jan 22 '13 at 16:36
  • Thanks Alex. I think we will try out the version numbers – Sunny Jan 22 '13 at 17:16
1

In a similar project at my job, we use version numbers.

Every commit against the version control system (VCS) causes our CI server (TeamCity) to build a new artifact, with the version set to "LATEST". Every successful build of "LATEST" get deployed automatically to our test environment. We could, in theory, also deploy this "LATEST" version to production, but we don't.

When we want to deploy a new version to production we run a different, manual build job which creates a versioned release (e.g. 1.4.7). The build job also creates an SVN "Tag" of the current codebase. To have our DLLs have the appropriate version, we use TeamCity's AssemblyInfo Patcher feature. This way, we don't have to constantly manually update our projects' AssemblyInfo.cs files. Instead, they get to always have placeholder version info like this...

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.0.0")]

These number get automatically updated during the build by TeamCity. The versioned artifacts (which include any corresponding SQL scripts) are saved to our "Releases" directory where we keep all our versions of the codebase.

Now this all seems like overkill, right? Not really.

This gives us the following benefits...

  • Our deploy process does a wget to our monitoring page which lists the version number and asserts the versions match up (version expected to have been deployed vs. the version currently running on the server). This gives us confidence that our deploy process worked properly.
  • If bugs are found in the versioned release (the production release candidate), we can SVN checkout the tag, apply a fix, and create a new release without having to worry about other changes on trunk which could compromise the release. It is hard to stay "releasable" all the time, this allows to not have to be. Although, don't get me wrong, it has it's advantages.
  • If problems are found with a versioned release but they can't be resolved quickly, you can always just re-deploy the older artifact which is known to work. Being able to revert a deployed release to an older version has definitely saved us on a couple occasions.
  • If bugs are found on production that need to be investigated, we are free to deploy the same versioned artifact to any of our test environments so that we can try to reproduce the problems outside of our production environment.

There are probably more advantages I am forgetting at the moment but the above list should give a general idea of the power that proper version management can bring to the table.

What I would advise against is continuously, manually updating 20+ projects' version files. This seems like a lot of busy work which is mostly a waste of time because it is prone to human error. Whatever you decide to do, automate it and verify the results.

Jesse Webb
  • 43,135
  • 27
  • 106
  • 143
  • our deploy process basically is get latest, then using the VS2010 publish feature, publish out the dlls etc etc and then copy over to the server. run the tool to bring the DB inline. this tool also updates the db version number in the DB itself. My suggestion was get the app to read the version number from db and that about it – Sunny Jan 22 '13 at 16:17
  • Boy I hope you cut and pasted that wrong. It seems you would want AssemblyFileVersion Incrementing every compile and AssembyVersion either never increasing or increasing only on majors. – Alex Jan 22 '13 at 16:39
  • @Sunny - That seems like a good start; having at least *some kind* of version on your deployed code. I wasn't providing this answer to say "This is how it should be", take it more like "This is a solution that works for team". Take what you want from it, try some things, and find out what works best for you. – Jesse Webb Jan 22 '13 at 16:56
  • @Alex - No, it is not a copy and paste error. That is simply what the default values are when I create a new project in VS. Those values don't matter anyway, the point in showing you them was to demonstrate that they don't matter; TeamCity's AssemblyInfo patcher feature takes care of updating these values when the code is built. It uses version numbers of the build configuration. So for our CI latest build that gets run every commit, it replaces those values with "0.0.0.0". In the "Create Versioned Release" build configuration, we specify a real version number like "1.2.3.4". – Jesse Webb Jan 22 '13 at 17:00