Several times recently, I’ve discussed how architectures should be set up for development, both internal and external. This is just a primer on the subject for those curious, since it seems like a lot of people are these days. 

When it comes to developing software for PCs or the web, the structure of development environments hasn’t radically changed over the past 20 years (Note: If you are using minis or mainframes, I’m not sure any of this advice is relevant).

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP—Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware. It is acceptable to have one or more of these systems set up as virtual servers. In most cases, the important part is isolation, not performance, so having virtual servers or virtual machines on the same hardware is acceptable.

Development

In most modern systems, development is done on the individual developer’s laptop or desktop system.  This is perfectly fine, as long as proper version control systems are in place. Developers will need to have a complete, if truncated, environment. All the pieces of the system need to be part of their system. For a developer building web based applications, this means they will need, at a minimum, the following:

• The same web server used in production.
• The same database used in production. A feature- or size-limited version is acceptable for resource utilization as long as all of the features being used in the system are available.
• The same language being used in production.

Because development leads production, it is acceptable to have newer versions in development than are being deployed in production, however, because development is distributed across multiple machines,  it is important that all development be done on the same versions of all tools. Developers should be discouraged from updating to a new version until the entire development group is ready to update as well.

Your development server may also be your source code control repository. If so, it will be where unit tests are run either upon check-in or at pre-determined times.

Testing

Once the code passes its unit tests, the testing server is where integration testing takes place. On a pre-determined schedule, your testing server should—hopefully automatically—check out all the code, refresh the database and then execute a bottom-up testing script. All unit tests are run, then integration and regression testing are performed to make sure that all the pieces fit together and nothing previously working was broken.

Acceptance

The acceptance testing server should always mirror your production server in services and revision levels.  When code is ready for release, it is checked out onto the Acceptance server. Some teams re-run the integration/regression testing suite at this point also, as one final sanity check before the client sees the code. Acceptance testing for web based applications should be where your client actually sees the code and tests it using their own testing plan. 

Acceptance is also where you test your version-migration scripts.

Production

The final phase of the development process is to stage your code into production.  If all goes well, this should be a fully-automated process—or, at least, a highly automated operation. 

Conclusion

Properly setting up your environments and making sure that all your tools work together before beginning development is very important. Starting a project while implementing these procedures is a sure way to frustrate your developers and delay your project.  In Part 2, we’ll discuss the smaller moving pieces.