Private developer environments
What will you do when your QA environment goes down?
Why private developer environments
Shared dev/QA environments are easy, but downtime and experimental code can cause cascading problems in your development lifecycle.
No developer collisions
Shared QA environments get littered with experimental code during the development process leading to unexpected and confusing behavior for others working on integrations.
No single point of failure
Teams that rely on a shared QA environment for daily development are exposed to major productivity risks. If QA goes down, which is will, no one can get any work done until its back up.
Test early. Test often.
Developers creating and maintaining private environments means that everyone is testing your deploy processes daily. This early testing further ensures nothing goes wrong when it comes time to go to production.
How to achieve private developer environments
Private environments should be easy and approachable for everyone
You can’t expect other teams integrating your app or service to know how to run it. Containerization and a common code registry ensures that everyone uses the same processes for running apps and services.
Declare your dependencies
Even if someone can run your code, your code still needs to integrate with other databases, messaging queues, or APIs in order to complete its work. Declaring these dependencies ensures that these resources are always available and resolvable.
Automate dependency integration
It takes more than downloading code or containers to resolve network dependencies. Dependency resolution for cloud applications happens when code is deployed to ensure everything is up, healthy, and resolvable.