Early on in the development of Tower, we had a vision of having a clean separation of development and production. We intended to give teams and individual users sandboxes, where they would develop their apps and code. This way, they could experiment and play around with ideas. 

Once the code and apps were tested, well-developed, and all around ready, they could promote them, so that the apps could become critical workflows for the business. We were working on a major iteration of this functionality, and are now ready to promote it to general release. 

Isolated environments - or “don’t break prod by accident, ever”

That’s it. That’s the message. Try it now. 

But seriously, the idea was to reflect how most data engineers work today. You have your development sandbox, likely a laptop, where you have locally installed tools and databases. This is where you build, experiment, and break things.  Separately, you have shared resources like a cloud database, a cloud compute cluster, and so on. The cloud is where companies do integration testing and prod workloads. 

Tower environments allow you to reproduce this. You now have a “local” environment to do what you do, and then “production”, where everything that’s built to last runs. Engineers work in a certain workflow - so the tools they use should reflect that. 

This Tower update introduces a single place to define and manage environments in account settings.

It also adds an easy selector to define which environment you’re working with, to avoid any confusion - or accidents. 

Big impact for power users

If you have built more than a handful of apps, or are planning to, and want to push some of them to an environment where they can run on a regular schedule, or share them with your team, this update should make you happy. 

This update is a reflection of our philosophy at Tower. Devs should have tools that understand how they work, and encourage them to work this way. Multiple environments reflect our daily workflows - and I’m sure yours. 

What’s next for environments? 

We are working on an easier way to support hierarchies of environments. Right now we only have a 2-level hierarchy, where every environment inherits secrets and settings from the “default” environment. We want to make it easier to support multi-level hierarchies, where, for example, you can have a base “development” environment, and all your developers can override settings in their personal development environment.

Until that update, try out the new environments setting and tell us what you think! 

Our last release revolved around scheduling - read more about that release in our blog post.