In a distributed architecture, why is it difficult to manage versions?

Question

I see it again and again. The UAT Test Manager wants the new build to be ready for testing by Friday. One of the first questions asked at the pre-test meeting was “which version will I test?” (which is a fair question). The room is quiet, then someone will return, "All meetings have their own version, just right-click and look at the properties ...".

From the point of view of test managers, this is useless. They want to have a version / tag / tag tag all that tells them what they are working on. They want this information to be easily accessible.

I saw solutions in which the version of various areas of the system is stored in a data warehouse, and then shown in the main application about the field. The problem is that this needs to be supported.

What solutions did you see that turns out to be the solution to the problem?

EDIT. The distributed system covers VB6, classic ASP, VB.Net, C #, web services (by department, and which version are we using?), SQL Server 2005.

Answer 1

I think the problem is that you and your testing manager are talking about two different things. Build options are great for builds, but your test manager talks about a higher level version, a "system version" if you want. At least that I read your post.

What you need to do in such situations is to map all of your various component assemblies to the system version. You say something along the lines of "Version 1.5 of the system consists of Foo.Bar.dll v1.4.6 and Baz.Qux.dll v2.6.7 and (etc.)." Hell, in a distributed system, you may need different versions for each of your services, which themselves may consist of different versions of the DLL. For example, you can say: “Version 1.5 of the system consists of the service Foo v1.3, which consists of Foo.dll v1.9.3 and Bar.dll v1.6.9 and the service Bar v1.9, which consists of Baz.dll v1.8.2 and Qux.dll v1.5.2 and (etc.). "

Doing such things is usually the task of the software architect and / or build manager in your organization.

There are a number of tools that you can use to solve this problem, which has nothing to do with your language of choice. My personal favorite is Jira , which, in addition to tracking bugs, has excellent support for product versions and roadmaps.

Answer 2

You might want to take a look at this page , which explains some ways to integrate consistent version control into your build process.

Answer 3

There are many different things that contribute to this problem. At the top of my head, here is one:

One of the advantages of a distributed architecture is that we get enormous potential for reuse by creating services and publishing their interfaces in one form or another. What this means is that client application releases are not necessarily closely synchronized with core service releases. Thus, a new version of a business application can be released that uses the same old reliable service that it uses for a year. How do we apply a single release tag in this case?

However, this is a fair question, but one that requires a non-trivial answer in order to be meaningful.

Answer 4

Do not use assembly-based version numbering for anything other than internal links. When the UAT manager asks the question, you say "Friday."

The only trick is to make sure that marking is happening reliably in your original control.

* insert the appropriate datestamp / label here

Answer 5

We use .NET and Subversion. All our application builds have a version number that is obtained from manually updated major and minor revision numbers and Subversion version numbers ( <major>.<minor>.<revision> ). We have a pre-build task that updates this version number in the general AssemblyVersionInfo.vb file. Then, when testers ask for the version number, we can either give them the full 3-part number, or just a revision of the subversion. The libraries we consume do not change or the changes are not related to the tester.