https://slack.engineering/development-environments-at-slack/
In this article, development environments refer to sandboxes where you can test your code changes before deploying, and should not be confused with integrated development environments (IDEs) like Eclipse or Microsoft Visual Studio.
Dev environments have always been a mystery to me. Despite learning about them on my first day at Slack, and using them almost every day for the last three years, I have never understood how they truly worked.
Half a year ago, I set a goal to understand dev environments inside and out. I interviewed some of the most senior engineers at Slack, studied countless pages of documentation, and sifted through years of Slack conversations. What I discovered was a fascinating journey of how our dev environments evolved over time.
Dev environments are copies of our application that we can modify freely. Their main value is allowing us to test changes to our application without impacting real users or putting real data at risk.
They enable us to iterate rapidly because it’s quick and easy to test changes on them. They also make it possible for us to easily share our changes with others for review.
Altogether, dev environments drastically increase development speed and safety.
Slack’s dev environments are copies of our application that live on remote servers — Amazon EC2 instances to be exact. These instances are configured to run the Slack application and the many services it depends on.
Each dev environment hosts its own Slack subdomain, which we can navigate to on our browser to see the changes we make.
No changes in dev environments can impact real users because they use their own set of infrastructure (e.g. databases) isolated from production.
The development and production environments are completely separate.
At Slack, we develop remotely, meaning our dev environments live on servers. Another option is developing locally on our personal computers. Local development is great for smaller projects because it’s fast and doesn’t require an internet connection. However, for larger projects, remote dev environments offer significant advantages.
First, we don’t have to set up the Slack application locally. Given that Slack has a very complex architecture that depends on many different services, not having to set things up locally is immensely valuable.
Second, if a change works in dev, it’ll most likely work in production, because our dev environments are configured to mirror production. Some level of drift may still happen with especially long-lived dev environments, but the likelihood and magnitude are much smaller than when developing locally with unique machines that often end up with inconsistent configurations.
Third, remote dev environments don’t rely on a personal computer, which may crash or lag. Cloud hardware is much more affordable, resilient, and scalable. Further, they allow us to easily develop on multiple machines and share our work with teammates for review.