Development environment, Staging environment


General J2EE: Development environment, Staging environment

  1. Development environment, Staging environment (3 messages)

    Sun published an article about the use of multiple environments:

    The three environments are:
    Development Environment
    Staging Environment
    Production Environment

    Is anybody using this type of multi-environment setup?

    Does the development team have full control over the configuration of the Development Environment?
  2. Hi!

    I hope all professional development project use a setup with, at least, three environments!

    Normally, the configuration manager and/or technical lead control the development environment. Avoid a situation where every developer is responsible for their own environment. They will spend days on configuration!!

    When it comes to staging and production, I think the most important thing is that the environments must be possible to build based on delivered code in the project following an instruction. No quick and dirty stuff here!

    How big is your project? From my experience, you can manage a project up to 8 persons without that much configuration management. A project with more than 15 developers and without experienced configuration manager/technical lead will end in a disaster.

  3. Our company uses the following configuration:

    Desktop - Running local versions of Weblogic
    Development - A set of 2-machine clusters on a Unix OS
    Test - A set of 2-machine clusters running the same hardware/OS configuration as found in production.
    Production - A set of 2-machine clusters running production code.

    In our environment, we use a middleware support group to manage and administer Development/Test/Production. The Deployer and System Admin J2EE roles are found within this group meaning that the developers have no control or access to configuration on those servers.

    There are a number of issues with this type of configuration and here are a few ideas that we are trying out to alleviate the problems that we have found.

    Desktop development - The basic problem here is paying for a ton of weblogic licenses and providing the necessary hardware/software upgrades on the desktop to do development. What really happens is a few developers get the licenses and everyone else has to work off the development machine Weblogic cluster.

    Development - The problem here is that resources such as memory, CPU and hard drive space become limiting factors. Since it is so expensive to do desktop development, everyone else is running against the same server farm. This means that development can be down as much as 25% of the time due to system crashes and it take up to 30 minutes to get an application built and deployed because everyone else is also using it (we have dozens of applications and developer teams running in the same clusters).

    Test - The test system is more stable but we run our compatibility tests, integration tests, performance benchmarking tests and stuff like that here. We also do demos here. That means this system is always stressed.

    Production - No problems here really except where certain system configurations are different than test or development.

    The solution that we are working on now:

    Desktop development - Replaced by giving each project its own Weblogic cluster on a high end server farm. Many projects share the same physical hardware but have different Weblogic clusters to develop within. Developers have full access and admin rights to the Weblogic server here.

    Integration/Staging - This replaces the development machine and also part of the testing process. Developers have no access to administration here. Applications are deployed here to do the first phase of integration and testing.

    UAT/Integration/Stress - The test environment. These clusters must mirror production as closely as possible. As much as possible, there needs to be a separate UAT (User Acceptance Test) box or at least a separate cluster so that your users can play with the system and for demo/training purposes. Concurrently with this, the app needs to be run in a stress test and a compatibility test with all the other apps that are to be deployed in production. Since those things are resource intensive, they need their own system.

    Production - No changes here.
  4. article: The Ideal WebSphere Development Environment

    The article describes a Development environment, Development Integration
    Environment, System Test Environment, Performance Test Environment,
    Pre-Production Environment (Staging), Production Environment.