I can't seem to find a good enough answer, nor can I reason it out myself. Why deploy to the development environment?

In most examples I've seen, automated unit tests and integration tests run as part of CI when we merge a feature into the develop branch. As far as I'm aware, there is no need to deploy when conducting these types of tests.

I can see why deploying to a staging environment is necessary, but not the development environment. So what are we supposed to do in a deployed development environment that I fail to see?

  • 2
    Does nobody ever look at the dev environment to e.g. make sure everything's working as expected, accept the user stories, ...? Maybe you don't need it, we can't tell you that.
    – jonrsharpe
    Jul 26, 2021 at 13:34
  • 24
    Where do you test and debug your deployment code in your organization? In the staging environment?
    – Doc Brown
    Jul 26, 2021 at 15:39
  • @DocBrown I'm guessing he just feels it's taken care of during local development; and then especially if there's a QA environment before staging, a separate development environment might just seem redundant with the QA one. Jul 27, 2021 at 19:03
  • Normal because I wish to have a debug build with debugger etc but everything else the same as a full deployment.
    – Ian
    Jul 28, 2021 at 13:24

4 Answers 4


You deploy to dev because you can't actually do real integration testing without actually really running the code.

You can call the environment something else like Staging, but if it's the lowest non-production environment, it's just dev by another name.
There are plenty of things that can work locally, but break when deployed, firewalls, missed dependencies, bad configuration, services that don't actually match contracts, and more.
Having a real dev environment helps find these sort of issues, and fix them faster without compromising the staging environment that should be dedicated for user acceptance testing (UAT).

  • 13
    We have n DEV environments (at least one per developer), CI, TEST, STAGE, and multiple PROD (one per customer). STAGE is only allowed realistic data; TEST and below anything goes.
    – Joshua
    Jul 26, 2021 at 22:15
  • 1
    This answer opened my eyes a little bit, in terms of why to have a separate Dev environment. Containers can help with integration testing during local development (like with a containerized database), but if it's for local development, they're still in more of a "test tube" on the developer's personal machine or wherever. Jul 27, 2021 at 19:07

Often, the tests that are run as part of a build are done in a clean environment. The build server establishes a new database, and the tests are responsible for seeding the necessary data for test execution. This is fine to get rapid feedback on if the system is behaving as expected. However, it doesn't find issues that may exist in your deploy scripts, database migrations, non-test configuration files, and anything else that may not be exercised in testing. Deploying to an environment also gives people the chance to interact with the system and perform user acceptance testing or exploratory testing to find potential defects sooner.

As far as what the environment is called, that doesn't matter so much. Some organizations have more environments than others. For example, you may have a development environment where the development teams have full access to the infrastructure and a staging environment under more control. This ensures that developers have a place to experiment with changes to infrastructure and configuration while also having a place that is very close (if not identical) to production to be able to apply changes to code and configuration. The number and types of environments, along with what you call them, will depend on your team's or organization's process.


Actually I think you raise a valid point. In these days of CI spinning up a full stack in a containers and running integration tests, the need for a DEV environment, as apposed to to a TEST or UAT environment is questionable.

It could also be beneficial NOT to have a DEV env, as often you need several to cater for the needs of different teams. If instead of cloud services they spin up stacks on their local machines in containers you could save a considerable amount of money


I think your question amounts to saying, "Why have a Development environment at all?" Please explain if you mean something different.

There are at least three reasons to have a Dev environment distinct from the developers' desktops.

One: The Dev environment can and should be configured very similar to the Production environment. That is often not possible on a developer's desktop. At a minimum, the Dev environment should be on a server running the same OS as Prod, it should be on a SERVER and not on a desktop, it should have similar network configuration, etc. There could be many things that will work on a desktop but not in a "more realistic" environment.

For example, one web site I was working on worked fine on my desktop but didn't work in Dev. Turned out I was using a 32-bit DLL. My web server was configured to run 32 bit DLLs, but Dev wasn't.

Two: By deploying to Dev, you are forced to figure out the steps necessary to deploym. Maybe this is as simple as "update from the repository". Or maybe it's not. Maybe you have to make database changes. Maybe you have to create work directories, or install additional software, or many other possible things.

Three: Do you have a dedicated testing group? Where are they going to test? They're probably not going to test on your desktop. There has to be some environment to deploy the app to where the testing group can do their thing.

If you don't have a dedicated testing group, than if at all possible you should get one. Programmers are notoriously bad at testing their own work. I routinely find myself saying to our testing folks, "You did what? Why would you do that? I never thought to test that, it never occurred to me that anyone would do that."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.