14 Jul 2015
It’s easy to see how containers can help your developer team. But they’re also useful for people across your business, including developer relations, marketing, and technical documentation.
Being able to deploy any version of your app across any platform means that your technical writers can write about new features easily, your marketing team can get to grips with new product features quickly, and your developer relations team can demo your app with confidence.
It’s no secret that there’s a new product thought up every second. That’s why it’s more important than ever to make sure that you find your audience quickly: the people who will use your product, love it, and advocate it. This is exactly what the people outside of your dev team are responsible for. So it behooves you to make their jobs as easy as possible.
Getting to Know Containers
In the past, getting a specific version of your app up and running a local computer might’ve taken half a day. That’s because apps usually have a lot of dependencies, as well as runtime environment requirements. Getting this stuff set up as a dev can be tricky enough. But expecting someone outside of your dev team to do it is usually a no-go.
As we covered in a previous post, containers make it easy to automate all of this. Getting any version of your app running locally can be as easy as cloning the right branch of your repository and running make. This puts an identical copy of the app on each person’s computer, making it ideal for testing, QAing, documenting, and live demos.
Using containers like this (instead of a shared staging environment) means people can work individually, as and when they want, without placing additional burdens on the dev team to spin up new environments.
This will improve the efficiency and self-reliance of any team that works with your app, leading to quicker QA test cycles, quicker documentation, quicker marketing, and so on.