This chapter describes the environment in which the development, testing and deployment occur.
In the worst case the developers are allowed to modify the production code, scripts or configuration. This is generally considered to be undesirable, but what is the preferred arrangement?
5 Levels
The proposal here is for a five level configuration environment where changes progress from development, through testing to deployment into the production environment.
Level 1
This level is for the software developers to create new software or to create patches for existing software. This level needs to be easy to configure by the programmers themselves since they may need to try various configuration alternatives in rapid succession.
Programmers should run their unit tests in the level 1 environment.
Level 2
The second level is for the integration of the software created in level 1. The only development at this level is for the build system and similar configuration elements. The software should be built on this level so that there is confidence that the correct supporting libraries are being used (and not something that is under development by some programmer).
Programmers should run tests to confirm that the software builds and runs as specified.
Development software, such as compilers should only be accessible from levels 1 and 2.
Level 3
The third level is for the formal testing of the software. The package created in level 2 should be installed in a controlled manner and then subjected to the testing specified for the system.
Level 4
The fourth level is for confirming that the new software will run in the production environment. Hence this level should be as close as possible in configuration, and size to production.
The software should be installed by the same system administrators responsible for the production system.
Level 4 is also the correct place for acceptance testing by the client to confirm that what has been delivered is what they are expecting.
Level 5
The last level is for the production system. Software should only be installed here after it has passed all tests and the client has agreed that it is OK to install.
Versions
It is typical for there to be more than one version of the software in existence at any one time. It would be wasteful to put the programming and testing teams on hold while the acceptance testing was being done, for example.
In a large project you may have several development teams working on different enhancements to the system at the same time as the test team is performing their test work, and the client might have a production version running while they are acceptance testing the next release.
It is also possible that there will be multiple versions of the software in production at the same time. A large distributed environment, for example, may not be able to promote all sites to the next production version simultaneously (or they may consider it unwise to do so).
If there are multiple clients for the software some may be constrained to old versions of the software for various reasons, both economic, and technical.
Increments and Releases
Modern software development practices emphasise the need to work on small, well defined and focused developments, rather than huge multi-year projects. Typically an increment to the development will take a few weeks to go through the analysis, design and programming phases.
On the other hand the client will find that performing acceptance testing is expensive and time consuming, and is not something that can be undertaken frequently.
To reconcile these two competing requirements we can keep most increments in the Level 1 through Level 3 environments, and only promote to Level 4 when the client is ready for the next round of acceptance testing.
This can be done by nominating a special increment to be a Release of the software.
Platforms
Sometimes it is necessary to support software on multiple platforms. These can range from different versions of Windows, to support across a variety of operating systems such as Windows, Linux, HPUX, Solaris, AIX, BSD, MacOS, etc. along with the multiple versions of each.
Support for different hardware is also becoming a much more common requirement as the ARM architecture is rapidly gaining prominence.
Finally support for different user interfaces is recently become a hot topic. It might be necessary to support a conventional desktop with keyboard and mouse, a touch screen device such as a touch enabled laptop or tablet, and perhaps even a smart phone. One should also not overlook the usefulness of a simple command line interface when it comes to remotely administering a computer.
Configurations
The software might be required to operate in a wide variety of different configurations. It may need to work on a simple stand-alone computer, to a large network within an organisation to a "cloud enabled" distributed system.
Different clients may also use different supporting software, such as databases, GUI libraries, and so on. These can be just different versions of, for example, Java, through to entirely different products.
Virtual Machines
If we multiply our five level deployment model by the number of supported versions of the software we can already get quite an unmanageable number. Multiply that again by the number of potential platforms and configurations and it becomes obvious that no one could have every combination ready to develop and test on.
The answer is, of course, to set up a collection of virtual machines with the most common combinations, and have some others that can be adapted to the more unusual arrangements.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
