Steps to begin versioning a web application

Question

Until now, we have not had an application version strategy or version-ed our application. We are considering doing so with our next release. What are the minimum tasks necessary to transition to a version-ed application? Answers in the form of bullet points, not necessarily in chronological order would be sufficient. It's okay to keep it high level. A few examples might be:

• Determine version control name convention Major.Minor.Build.YY...
• Revise on screen imaging or text to display current version
• Prepare release notes template for communicating new releases to users

We're a .Net shop using TFS if that helps. If it's not obvious already, I'm not a developer. I'm the solution expert/BA acting often as the project manager.

• Joel Etherton: What does "versioning" buy you? Will you offer access to disparate versons? Will you have simultaneous versions available? Are you simply attempting to provide some measure of communication with the user base as to what features will be available in which version?
• Drano: Thanks for the comment. Mainly for communication purposes but also managing what's in the feature request pipeline. From a project management standpoint, we can group planned feature and functionality enhancements into future releases. I'm also thinking it will be easier to build test suites in our test case management tools when grouped by releases.
• Basile Starynkevitch: Do you use some version control system (like git which I recommend) on your source files?
• Joel Etherton: @BasileStarynkevitch: It's in the question - We're a .Net shop using TFS
• Drano: TFS is Team Foundation Server. We have a few developers but one core developer that works on the Trunk. He sometimes will make a new branch depending on the change.

Answer 1

If your goal is to be able to track a version being used by a customer when this customer is reporting a bug, any technique would work. As soon as the revision number (from the version control) appears anywhere on the page, you can link the bug to the corresponding revision.

In .NET, you can easily auto-increment the version of the assembly. The remaining task is to:

• Display the version number if the users are expected to report it to you (through a screenshot or manually),

• Or simply store in the log when a given version was deployed on a given server: this will make it possible to determine the version by inspecting the HTTP logs (particularly useful when you monitor HTTP 500 errors, without waiting for the end users to report the errors to you.)

Additional note: release notes are fine for software products. For web apps, users simply don't care what version do they use. For example, do you know the current version of GMail? What about Office 365? Or maybe Facebook? Or Stack Exchange (yes, you can have a peek at the bottom of this page)? This is actually becoming true even for software products. Google Chrome is an excellent example. Adobe Creative Cloud is becoming more and more another example.

• Drano: Interesting point that users don't care what version they use. I believe that would certainly be the case for our users. Matter a fact, we may not want to promote new relases, major or minor as you have to then deal with user expectation that the app includes ground breaking improvements through the entire product. I'm mostly interested in using a version system for product development planning, testing and giving our developers a more industry standard approach to work in.
• Arseni Mourzenko: @Drano: one of the reasons the users don't care is continuous deployment. If a company is pushing to production several dozens of new versions every day, the very notion of version becomes irrelevant for the end user. The only thing which would matter is the major version, but if changes are implemented progressively, there is no major version per se (Stack Exchange doesn't have one; if GMail does, it corresponds to a purely technical number, irrelevant to the user experience.)
• Drano: Well then in our case, new releases would be not be considered continuous development. Each new deployment to production would likely include a feature enhancement or bug fix that would be noticeable to the user. I just want to be careful that when we announce a release that we're managing expectations.
• Arseni Mourzenko: @Drano: version irrelevancy and progressive enhancement don't mean the users won't notice that things change. Many features introduced in or (especially) removed from Google Chrome or GMail are noticed by the users; some are expected for a long time, and others are plainly rejected (example: the awful Google Chrome bookmark manager Google ended up removing). What I rather wanted to focus is the paradigm change: instead of waiting for the version 3.4, users expect the new features to appear right now, magically.
• Drano: Okay I see what you mean. I like the idea of this (I expect things now too!), however I worry we won't meet user demand in that case. Waiting for releases is somewhat of a crux for us, giving us time to develop and test the new features. However assuming we adopt a more progressive enhancement approach, do we version control in the same manner, using the same tools and methodology but just in a more agile and rapid progression and without the release announcement hoopla?

Answer 2

Imagine the life of your product as a string of pearls. The underlying string is the constant background plumbing: software definition processes, issue management processes, development processes, etc. It's the skeleton.

The pearls are distinct releases. Some are cultured. Others are natural. There are saltwater pearls and freshwater pearls.

Actually, that's a bad example because there's no concept of time. Time is important in release management. That's the thing we're really talking about: improving release management. So let's build a better metaphor. The life of your product is a running reel of film. That's better. The dark part between the cells -- the part perforated with holes so the projector can pull it through -- that's your plumbing. The releases are the cells. They're moving through time. The film is unfolding. We're watching it.

Now, the trick is to gather everything you need to create a particular cell so that it fits between its neighbors and let's the story flow smoothly. You need a director, writers, actors, set builders, producers (the money people), camera people, an assistant to the director, and maybe a cinematographer. Yeah, I like this. This is working.

• Stuff that goes into a cell: plot (feature development), scene tuning (bug fixes), product placement (inane client requests), shot structure (UX).
• You've got to coordinate all of those things perfectly so they not only fit together in the cell, but also in the film.
• External shareholders want to know which cells their material appears in.
• Internal shareholders want to know which cells they're expected to contribute to and what they're expected to contribute.
• That's why strong (but flexible) scheduling is a must. With long time frames, a rough estimate is adequate, but as cells draw near it's important to communicate precisely where an issue or feature will appear.
• The problem with the items mentioned in your question and other answers is that they represent a small part of the film-making process. Version numbers, version number display, CI... those are all important things but they represent a small part of a film. Maybe they're the camera people (developers) and cinematographer (architect). Remember that a lot more goes into each cell.
• Most importantly (and here's where our metaphor really shines!), remember that a good story isn't told with a single cell in a film. It's a bunch of cells together to form a scene, a bunch of scenes together to form an act. It's all about timing. Not only does everything need to come together for the cell, but the cells need to be sequenced to maximize their affect!

More:

• 8 Ways to Improve your Enterprise Release Management Process
• Filmmaking

• Drano: This is great, I really like the theme and how you suggest not building a strategy in order to produce a single cell but a strategy that tells a story. If I could vote I would!

Answer 3

Labels would be the important point to note. Figure out how you want to use the TFS built-in functionality that is similar to tagging in Subversion for being able to pull out a particular build of the code.

There are other ideas like continuous integration, code freezes and scheduling that can be useful but wouldn't be necessary for having versions in an app.

Continuous Integration - this is basically about running all the tests whenever someone commits code. Useful for finding old bugs that have resurfaced as someone's changes in one place may have side effects. TFS has some of this built into it.

Code Freeze - this is basically about preventing new features from being added to the main trunk while the release is stabilized. Think of this as preventing others from using a kitchen while one group is cooking in there.

Scheduling is part of the code freeze in terms of communicating when is the release ready to do basic QA testing, when does it have user acceptance testing and when is the release. Each stage is important but depending on your process not all of these will apply.

• Drano: These other ideas you mention, such as scheduling, without having to version, can you elaborate?