20 Jul 2015 in Deis v1 PaaS

New Maintainer - Kent Rancourt

Please join us in welcoming Kent Rancourt as a core maintainer of the Deis project!

Kent Rancourt is a software engineer, lifelong martial artist, avid hiker, and self-described comic book nerd. His background is in application development and architecture as well as devops.

Kent lives in Connecticut and will be working remotely. He'll be focusing on production-hardening Deis.

Follow Kent on Twitter: @krancour

15 Jul 2015 in Deis v1 PaaS

Welcome Seth Goings to Team Deis

Seth is a software engineer who has always despised how much time, effort, sweat, and tears are involved in producing high quality software projects. He'd rather spend time running away from snarling Chihuahuas, riding his bicycle off into the sunset, cooking up an all-kitchen-appliances-necessary dinner, or remodeling his house at 3AM than stepping through a testing spreadsheet during "release night." Due to this drive, naturally he'll be working on improving the build, test, and deployment infrastructure within the Deis project.

Seth lives in Colorado and will be working on Deis full time in Engine Yard's Boulder office.

Follow Seth on Twitter: @sethgoings

15 Jul 2015 in Deis v1 PaaS

Welcome Jonathan Chauncey to Team Deis

Jonathan Chauncey is a software engineer, search geek, and general tinkerer of all things. He has built a custom Docker PaaS and understands the problems with running Docker in production.

Jonathan lives in Colorado, and will be hanging out in Engine Yard's Boulder office. He'll be working full-time on a monitoring and telemetry platform for Deis.

Follow Jonathan on Twitter: @jlchauncey

15 Jul 2015 in Deis v1 PaaS

Deis v1.9 Community Release Planning Meeting

The Deis open roadmap is influenced by the needs and concerns of our community. To help us plan Deis releases, we invite the community to attend monthly release planning meetings to share with us any issues they'd like to see addressed in the next release.

Last week, we held the second such meeting, a planning meeting for Deis v1.9. A video of the meeting is on YouTube.

Meetings are coordinated on our mailing list. If you're not already a member of the deis-users mailing list, I'd encourage you to sign up. We have a great community of users who share all sorts of experience running Deis in different environments.

See you at next month's planning meeting!

14 Jul 2015 in Teamwork

How Containers Can Help Non-Developers in Your Business

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.

Read More