Setting Up Development Environments Based on Life Cycle
When working in an enterprise environment, invariably, you’re going to need to have a process for developing and eventually deploying applications to production. This is an important and potentially stressful process in development because it affects live data, business up-time, and highlights any failures in the development of the project.
There are several ways to structure the process of eventually deploying software applications and much of this depends on the business commitment to the software being developed. I will attempt to discuss what stages in the development life cycle to base environments on regardless of the software development life cycle (SDLC) methodology being employed.
Three-Stage Environments
We’ll start with what I consider to be the most basic, yet still complete, environment setup. This will consist of three physical (or virtual) boxes labeled: Development, Staging, and Production.
Development — This box will contain the latest and greatest (and most unstable) code which developers are currently deploying to or working against. This is not the local/client-development environment which developers write code against (Visual Studio for example). This is a stand-alone box which has the development-grade code deployed to it. This box may have a database associated with it which either resides on the same box or on another physical (or virtual) box within the development realm. Often times, developers using their local development environment (their client computer) may talk directly to this Development database instead of their own local versions.
Staging — This box contains the expected production-level code which may need to be tested or accepted prior to being deployed to production. The staging environment should be an exact replica of the Production environment in regards to physical attributes of the server and software installed on the server. Using three-stage environments, the staging server also acts as the quality assurance (QA) and user acceptance testing (UAT) environments. Once all tests are completed and the code is officially accepted, the code may be deployed again to staging to test the deployment procedure in a mock production deployment test. This procedure will be repeated when it is time to officially deploy the application to production.
Production — This box is the live system which end-users perform their work in. The production environment is always the oldest, and hopefully, most stable environment. Code changes, including bug fixes or patches, should only be deployed to production after they’ve been tested by the development team in the Development environment, and test/approved via the Staging environment before being deployed to production. In most cases, including Agile development, the production environment should not be in constant change because of the increased instability this often causes.
Pro’s
There are several pro’s to setting up three-stage environments; primarily, they’re fairly easy and more inexpensive than other models while still giving you much of the benefit of life cycle environments. Having a limited number of environments means lower maintenance of the machines, fewer licensing costs, and less backup responsibilities to worry about.
Con’s
Of course, this comes with a few trade-offs. Primarily, in larger environments where there is a dedicated QA team that can perform automated tests on the code which may be processor or bandwidth intensive can significantly impact the performance of an environment. This can therefore impact UAT testing or approval demonstration. Additionally, many QA software packages require additional software to be installed on the box which then somewhat invalidates the cardinal rule of Staging and Production environments being the same.
An additional note on Staging and Production being the same:
Even though we attempt to make Staging and Production exactly the same, there will be some differences; such as where the box sits relative to the network (firewalls, etc.), user permissions, production-specific data, etc. It is at your discretion which of these things need to be the same and which can be different; just keep in mind, the more differences, the more likely a failure during production deployment will occur.
Distributed Systems
Setting up environments based on the development life cycle for distributed systems is similar just on a larger scale. Instead of three boxes, you may have specific boxes for each layer in your architecture (such as Data Access, Business Logic, Presentation, etc.). In this scenario your environments would simply contain more physical (or virtual) boxes.
