 |
| Photo credit: gothopotam on Flickr |
In production, we expect and demand nothing less than correct operation when we deploy a new version of our application. We expect this environment to be permanently available. If there are any problems, they must be specific to the production environment only. We can reduce the probability of this occurring by using a "regression" or as-live environment.
In regression, we know that our application has been fully tested, but we expect to encounter problems related to configuration changes or perhaps database versioning issues. We expect this environment to be permanently available as production, but accept there may be problems from time to time. By encountering these in regression, we are able to address the issues before our application makes it into production. We make sure that our application is performing as per specification and that there are no defects, by using a system test environment.
In system test, we know that our application works, in that it starts up and functions, however business functionality and overall operation has not been independently tested. We expect this environment to be generally available during testing, but accept that new releases may bring in problems which have to be addressed, and also that the application may fail during testing due to major defects. We expect to encounter these issues as well as some relating to the configuration of the environment and resources it uses, such as databases. However, we can have confidence that our application basically works, by using a development environment.
In development, nothing is guaranteed. The application may or may not work, for reasons which will be investigated by development staff. The development environment is used to ensure that released applications are basically sound, and configuration issues explored. We expect this environment to be generally available, but accept that certain tasks during the development phase may require it to be extensively rebuilt or reconfigured.
Applications (as created by your continuous integration build cycle) should be released to each environment in turn, and where problems are found, be prepared to back track and rework - and start the cascading release process again once the fixes are in place.
If you ever find yourself deploying to production and changing the production database because of a bug or change to requirements, and then back-propagating to development, you have a major problem!
In this short series I'm outlining the tools you really do need for a professional quality software development environment. Many of them will seem like common sense to many of you. Many of them have been inexplicably missing from development environments I've seen over the past few years. The list isn't meant to be "the final solution" - you may have these things, you may have alternatives, you may have nothing at all - in which case you know where to start.
