CST316 Software Enterprise II: Construction and Transition Spring 2011

Glossary: Configuration vs. Build vs. Release Management

Most programmers develop their skill by writing small programs that are compiled and linked into running programs. The focus of the activity is on developing the skill in the syntax and semantics of the programming language, and the compile/link part was sort of a rote activity that you had to do to create a running program. In fact many new programmers don’t even have to do the link step, it may be hidden as part of the IDE or compilation tool or simply not needed due to virtual machine (p-code) technologies such as Java or the interpreted nature of now popular dynamic languages.

Now, as you encounter more complex systems, you are exposed to situations where getting the code running is a multi-step process that involved much more than compiling (and linking). The source code may consist of dozens if not hundreds of source code files, perhaps even in multiple languages. Other non-source artifacts may be required to configure the source code (XML or property files). Compiling the source code may require several invocations of the compiler combined with external pre-compiled libraries, resulting in a software build. Running the software may involve copying it to a particular physical environment (i.e. a server, a phone, a board) together with yet different libraries to ensure it runs properly (the deployment process).

Here is our first conundrum – why would we need different libraries to create the build versus those that need to be present in the deployed environment? The answer is in what you learned about interfaces and implementations in your object-oriented programming class. It is sufficient to have present only the interface definitions at compile-time, and defer what resources serve as the implementation until run time. How does this work? Consider, for example, a Java program that wants to talk to a database. If the Java code is written to use only the JDBC specific APIs, then only the JDBC libraries need to be present when you compile. But when you need to run the program, you need to know exactly which database you are using (Oracle, Postgres, MySQL, Derby, etc.) and where it the database is running. When you know the former you can ensure that the vendor’s implementation of the JDBC specification is present (their JDBC driver .jar) at runtime, and when you know the latter, you can specify it in a configuration file that can be read in at runtime instead of coding the database location and credentials directly in the code. Note that neither the vendor implementation jarfile nor the configuration files are required at compile time.

Figure 1. JDBC interfaces versus vendor-specific implementation

Let’s stop and recap a few terms:

· Compile – the transformation of code in a presumably high-level language to machine level.

· (Static) linking – a process whereby the different machine-level code is combined into a larger machine-level object (presumably but not necessarily an executable program).

· Dynamic linking – The process of loading the external library code dynamically at run-time.

· Build – the process of assembling, transforming (compiling), and packaging a software component from a set of existing resources. Also used as a noun to describe the results of the process.

· Deployment – the process of moving a collection of components into the proper runtime environments with the proper configurations in order to execute.

OK, so now you have deployed software in an environment. What happens when someone reports a bug that needs to be fixed? Or the customer demands a new feature? Or a vendor whose library is in your deployed environment releases an upgrade? These and other issues may require you to perform software maintenance. You may have to change code and/or configuration information and get a new build out to the deployed environment. You could do this by going through the entire process (code-build-deploy) all over again. If it is a single computer or a small piece of software that you are talking about, that is perfectly reasonable. But if it is many computers and a non-trivial application, you may instead need to patch and hot deploy to get an updated environment. A patch is a small packaged update to already deployed software that corrects a defect, adds a feature, or addresses some upgrade issue without requiring a full re-install of the software. Hot deployment is the ability to apply a patch without shutting down the existing, running software.

OK, so some new terms from this discussion:

· Patch – An incremental modification to already packaged software that can be applied to the existing software without requiring a full re-installation.

· Hot deploy – the ability to apply a patch without restarting the running software.

· Production environment – a synonym, and better-known term, for the deployed environment. Operations and developers usually refer to it as just “production.”

· Software Maintenance (partial definition) – The modification of an existing set of software into new software that addresses defects or feature needs without fundamentally changing the intent of the software product.

Above the term production environment is defined, implying there are other environments – and there are. Developers certainly maintain their own environment to develop code. The code, once built, has to make its way out to production, but as you might expect there are some quality steps it has to go through first to ensure it belongs on a customer facing site. We will talk about these steps this spring, and next spring (in CST416) for that matter, but for now you can imagine there are environments where software builds are staged in order to be tested in various ways. A software build that makes it through the quality process and is ready to be used by customers (put in production) is called a release. The term release is used to suggest just what it says – software that is released by the organization for customer use. A release includes any related deliverables such as end user documentation, installation/administration guides, online knowledge bases, and training.

So, some final terms:

· Staging – The process of deploying software in a gated process (stages), with each stage addressing a new level of desired quality.

· Configuration – A particular combination of software artifacts used to build a specific release for a specific customer.

· Release – Software ready to be used by a define customer base (internal or external).