We now have Starter Projects for Django, Flask, Nest, and Nuxt! Check them out on GitHub

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

Standardize packaging

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.