Development Environments - How Many do you Need?

As much as I’m tempted to just say “42”, this is a more interesting question than it seems on the surface. Many Guidewire customers have an enterprise guideline for environments that every development project must adhere to, and our products fit nicely into such a structure. Others are looking for guidance and a best practice recommendation from a vendor like Guidewire.

One of the nice features of working with a Java-based application is that the technology is not an obstacle. Environments are relatively cheap and easy to provision and customers can consolidate multiple environments on the same physical server. Virtualization can be used to provide better physical separation as long as you plan capacity carefully.

In my mind the best way to think about it is in terms of the categories of environments, what role they need to play and who ultimately owns the environment. Here are some examples:

  • The sandbox is where you load the out-of-the-box applications with some sample data, to use as a reference point for the team as configuration progresses. The Guidewire Services team prefers to install this at the very beginning of the project since it is useful for almost any sort of workshop.
  • The build server is the deployment target of your continuous integration server, whether it is Jenkins, Hudson, Bamboo, etc. It is inherently unstable and will be restarted every time a build is deployed.
  • The QA environments are controlled by your QA team, and can be used for manual or automated testing. They are refreshed as needed but are not integrated with other systems.
  • Integrated environments are the first real proving ground of the configured application, as they are integrated to (and limited by the availability of) corresponding test environments of external systems. As an example, a stable integration test environment (SIT) can be refreshed once per iteration, while user acceptance requirements (UAT) are driven by a formal schedule.
  • The pre-production or staging environment is the final step before deploying code to production, and also is used to diagnose production bugs after go-live.
  • The performance environment needs to closely match your target production model in order to validate that your application will perform. Owned and managed by the performance management team.
  • If you are using an agile approach to your migration work, the migration instance is ideally one iteration behind the application configuration.
  • Your end-user training team controls the training environment and ensures it is refreshed for every training course. It is also nice to have an additional training sandbox with the configured system installed for business users to consult long after training is over.

At the end of the day whether you need everything on this list (or even more) depends on your organization and project.

P.S. I almost forgot about production! Probably a good idea to have one of those as well.