|
While purely local development works, the problem you often face in a fast-paced development environment is differences between your local system and production. That's not only dealing with things like file paths and service versions and configuration; it's also very stateful. With DevLab, you not only get an environment that very closely matches (or can be made to closely match) production, you also get a clean, blank-slate installation any time you run tests or any other task against your app. If you're developing locally, you're prone to database cruft, evolving configurations, pre-existing tempfiles, and other complications that can be easily avoided with the use of good development tooling. Now extend that idea to multiple applications: chances are, your team isn't developing just one thing. You probably have multiple development concerns, and if you have an architecture like an SOA, you may have a multitude of microservices. When you update the language they're based on, be it node, go, python, or anything else, you need the ability to test and update your applications individually. You need your entire team to be using the same versions for the same applications. And more than anything, you need your potentially large team to get all these updates without collective hours of manual work to orchestrate those configurations on their own local machines. My colleague addressed the question of DevLab vs. Compose elsewhere in this topic, but even if you don't use DevLab, I do heavily encourage virtualizing your environment to avoid these pitfalls in the way that makes the most sense for your team. |