Release Management Influences on Tarchitecture

Knowing what the release management requirements are can improve your tarchitecture by encouraging choices that make release management easier. Consider the following.

Recreate everything. The most important rule of release management is that everything shipped to the customer must be either derived (such as building an executable from source code) or created (such as printing a manual from a Framemaker file). This can create some funny behavior among dedicated workers, especially if they don't trust that IS is backing up their machines. I once had a director who copied every aspect of the source tree, along with all of the tools necessary to build the product, to multiple machines as well as burning multiple CDs, simply because she didn't trust our IT department to properly backup our source code machines. I'm glad she did this, because our IT department failed us more than onceand her backups saved the day.
Use existing solutions and infrastructure wherever possible. Chances are good that some aspects of your deployment architecture can handle any number of issues associated with technical configuration management. Microsoft, for example, has an extensive (some would say nightmarish) infrastructure for managing components packed as DLLs and their associated dependencies. Learn these infrastructures and leverage them when you can.
Put version information in your tarchitecture as early as possible. Once you've identified the need for version information, put it in without delay. Retrofitting version information is expensive and painful.
Components should know their dependencies. In component-based systems, your components should know which versions of other components they can work with. This is easiest with a data-driven approach, perhaps through a special dependency-checking component that processes dependency information stored in a configuration filefor example, when a client is directed at a server that can't support it, instead of failing outright , the client can inform the user of the problem and ideally provide him with some information on how to rectify the situation.
Messages and protocols should be versioned. Messages sent between components should be versioned so that changes in content or processing rules can be managed.
Databases and tables within them should have versions. One way to do this is to create a system table that contains the version identifier of each table in the schema. It can be extended to provide release information for specific columns within tables as needed by your application. Versions facilitate upgrading schemas in the field, detecting changes made to released schemas, and ensuring that components that read from and/or write to the database do this properly.
Any component that can be updated should be versioned. Versioning makes certain that your technical support organization can quickly assess whether a component should be updated in response to a customer problem. It also simplifies the installation of partial and patch releases.
Internal components should understand the versions of the external components they require. If your system requires Solaris 2.8, check for it. If you know your system has problems running on Windows XP, check for that.
There must be a way of obtaining versions of all versioned artifacts. This enables technical support to help the customer and is the foundation for customer self-service and automatic software updating.
Beware the testing and support implications of patches. Creating more components, and providing support and/or backward compatibility for previous releases, can increase testing and verification complexity at an exponential rate. Just because you can provide backward compatibility support, don't think that you must.