Plutora Blog - Software Development, Test Case Management, Test Environment Management, Test management, Value Stream Management
What Is a Development Environment? How to Get Started NowReading time 7 minutes
When it comes to environments, there’s not much mystery about production: that’s where the real application lives and users can access it. The trouble is with the other environments: development, staging, QA, pre-prod…There seems to be no shortage of new ones. This post is part of a series that will tackle the main environments used in the software development life cycle, and today we’ll cover the development environment.
So, let’s start by making this abundantly clear: we’re not talking about an integrated development environment, or IDE! This post isn’t about dev tools per se, but about environments as a metaphorical “place” where developers can implement and test their features in an efficient and safe way.
We’ll start by defining development environment, explaining its purpose, and giving some examples to keep in mind while you plan. After that, we’ll go a bit deeper, exploring some of the best practices that a good dev environment ought to follow. Let’s get started.
Solve the Achilles' Heel of Software Delivery. End test environment headaches in just 4 weeks. Starting at $25K.Learn More
Development Environment: The Fundamentals
Let’s open by exploring the what-why-how of development environments.
What Is a Development Environment?
A development environment is the space where developers can work, experiment, and test without worrying they’ll interfere with the experience of real users.
Of course, software being something intangible, when we talk about “space” we don’t mean a physical place you can walk into. Instead, we’re talking about a set of services, infrastructure pieces, configurations, and rules that, together, make up this scenario where developers can do their work.
Why Use a Development Environment?
In a nutshell, a development environment allows software developers to create, run, and test their application code in a way that’s adequately realistic and safe. If that still sounds too vague, let’s go for more specific examples.
Virtually all non-trivial applications use some form of database. So, developers also need a database to test their code against when working. Besides databases, applications commonly talk to a variety of services: APIs, message brokers, observability services, and so on.
During development, it’s important there’s something simulating or replacing those dependencies. Here’s why:
- User experience: Developers shouldn’t interact with the real database/APIs/etc., so they don’t create problems in the real production app.
- Cost: By interacting with the real services, the organization might be incurring costs. There’s no need to incur those costs during development.
- Safety/privacy: Interacting with the real dependencies might create security and privacy concerns.
How Do You Implement a Development Environment?
When it comes to how you create a development environment, it all depends on the specifics of your needs, the dependencies your code relies on, the size of your team, the maturity of your infrastructure, and so on.
In its most basic form, the development environment is simply the developer’s machine itself. With the popularization of Docker, it became relatively easy to create on-demand, reproducible environments that you can fire up by running a single command. You could have, for instance, a setup composed of three images: one for your back-end API, another for your front-end app that consumes that API, and a third one for the database.
Sometimes, this isn’t enough and you need to move the dev environment out of developers’ machines. When that’s the case, it might make sense to leverage some of the infrastructures you already have to create the development environment. For instance, create development databases and provide those string connections for developers to use. Populate said databases with synthetic data or a slice of production data that’s been properly masked/anonymized. Create mock APIs to avoid accessing the real one. In a nutshell: for every external dependency, create a development version your engineers can use safely.
Development Environment: A Few Best Practices
We’ve just covered the fundamentals of test environments. You’ve learned what they are, why they exist, and how to implement one. Now, let’s walk through some best practices to keep in mind when implementing a dev environment.
Your Development Environment Should Be Fast
Over the years, I’ve read some people arguing you should give developers slow machines so they’ll be forced to write performant code. The way I see it, that’s nonsense. Developer machines should have great performance, and that extends to the entire development environment.
Your Development Environment Should Offer Isolation
As a developer, I want to “own” my dev environment. That means I want to be able to do whatever I need in my environment without concern I’m breaking someone else’s work. I want to be able to do structural changes to the database—or even trash the whole thing if I’m feeling like it.
That level of isolation is essential if you want to give your developers freedom to experiment and explore.
Your Development Environment Should Be Realistic, But Not That Much
One of the most infamous phrases in software development is “It works on my machine!” I know I’m guilty of saying it. Such problems occur when the development environment and the production environment drift apart. I might have used a feature of .NET 6, but the production server doesn’t support that version yet, and things break after I deploy. Or perhaps my PHP code requires an Apache module to be activated, and since the server doesn’t have the module, the code doesn’t run.
We solve this problem by keeping the environments as close to each other as possible. Containers, mentioned earlier, are a great technology for enabling that.
Of course, your dev environment will never perfectly mirror the real world—you won’t have the same volume of requests, for instance—and you shouldn’t aspire for it to do so. When implementing a test data management strategy, for instance, there’s really no need for you to duplicate your infrastructure costs in order to have the same amount of data you have in production.
In a nutshell, keep your dev environment as realistic as you need it to be for developers to run their code in a predictable and safe manner, but not more.
Your Development Environment Should Be Compliant
Last but not least, we have to talk about compliance. We live in a post GDPR world, and more regulations inspired by it keep popping up. Preventing access to user data is actually a great reason for having dev environments in the first place. But since developers still need realistic data for testing, what are we to do?
Generally speaking, the options are two: synthetic data generation or production cloning (plus anonymization). Both have their pros and cons, but they solve the problem.
Development Environment: Understand It and Control It
Yes, I get it. We, developers, often speak in ways that might be confusing. There’s so much jargon that it’s often hard to keep up. But don’t worry; with the right amount of help, you can become versed in developer-speak one term at a time. Already in this post, we’ve clarified the term “development environment.”As you’ve seen, the development environment can take many different forms, but at the end of the day, it serves the same purpose: to allow developers to create, experiment, and explore in a safe, compliant, and performant way. Along with test environments, the dev environment is a crucial component of modern software development. All of these environments together—when properly implemented—enable organizations to deliver software quickly, without forgoing the quality the market demands.