How to set up your development and testing environments

To build your product professionally, you need to set up three distinct technical environments: a ‘local’ one for writing code, a shared ‘repository’ for storing it, and a ‘staging’ one for testing it. This structure is the foundation of modern software development, preventing developers from accidentally overwriting each other's work and ensuring you catch bugs before they ever reach your customers.

What is a Local Development Environment?

Think of this as each developer's personal workshop, set up on their own computer. It’s where the actual coding and building happens day-to-day. A good local environment contains all the tools needed to work on the project, such as a code editor (like Visual Studio Code or Sublime Text), the relevant programming languages (e.g., JavaScript, Python), and a local version of any database your application needs.

The goal is to give each developer a self-contained, fully functioning version of the system on their own machine so they can build and test new features independently.

What is a Shared Code Repository?

A shared code repository is the single source of truth for your project. It’s a central, cloud-based location where all developers store and synchronise the code they write. By using a version control system called Git, every single change is tracked, creating a complete history of the project.

This means you can see who changed what and when, and easily roll back to a previous version if a new change causes problems. Services like GitHub, GitLab, and Bitbucket are popular platforms for hosting these repositories and are essential for any team project.

What is a Staging Environment?

The staging environment (also known as a testing environment) is a private, exact replica of your live system. When a developer has finished building a feature on their local machine and saved it to the repository, the changes are then deployed here. This is the dress rehearsal before the main show.

Here, you and your team can test the new code thoroughly to make sure it works as expected and doesn’t break any existing features. It’s your final quality-control checkpoint and a crucial safety net that protects your live users from potential disruption.

Putting It All Together: A Simple Workflow

1. A developer writes code for a new feature on their local machine.
2. Once complete, they push their changes to the shared code repository.
3. The new code is deployed to the staging environment for rigorous testing.
4. After passing all tests, the code is finally deployed to the live ‘production’ system for your customers to use.

Top Tip: Keep your environments as similar as possible. If your live system uses a specific version of a database, your staging and local environments should too. This consistency helps avoid the classic "but it worked on my machine!" problem, saving you time and headaches.