Why deploy to the development environment?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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

Answer 4

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."