Anti-FAQs: Use localhost for collaboration?? Seriously?!

Answering the questions you're *really* asking about collaborating on localhost

Anti-FAQs: Use localhost for collaboration?? Seriously?!

What exactly are “Anti-FAQs”?

Regular FAQs are everywhere.

As the name suggests, it’s a convenient format for answering some of the standard questions asked regarding any product or service. The assumption behind these questions is that the questioner is actually interested in the product (or at least the product premise), and they are just trying to clarify some details before deciding to move forward with it.

In this regard, “Anti-FAQs” are the complete opposite.

This is what I like to call the cynical, skeptical questions that people ask (often rhetorically) to justify why they’re NOT interested in using the product.

negative

I like to focus on the Anti-FAQs because they are usually the juicer, more interesting discussion points. Ironically, once these items are actually clarified, the skeptics can be converted to become raving fans of the product they now better understand and appreciate.

The Anti-FAQs of localhost sharing

We’ve currently been thinking about several Anti-FAQs regarding a new Docker Extension we just launched.

The extension enables developers to to instantly share local containers with anyone, without the need for staging environments or CI builds. And we’ve included built-in collaboration tools that give technical teammates access to remote debugging and less-technical teammates the ability to leave review feedback in context, while the code is still hot off the press, on the developer’s machine.

It’s an amazing way for developers to continue to “shift-left” and bring critical review cycles to earlier stages of the development workflow, saving everyone time, headache, and money.

It’s a cause that Docker themselves are championing as recently as this year’s DockerCon, rolling out a series of native tools and features that expand the boundaries of developer collaboration.

But, pushing boundaries brings healthy skepticism. So we wanted to take the opportunity to address some of those “Anti-FAQs” you might be asking yourself about the prospect of sharing your localhost and using it to collaborate with your team.

Isn’t Ngrok already doing the same thing?

Not really. Ngrok (and others like it) are great ingress-as-a-service platforms, but the Livecycle extension takes localhost sharing even further.

Here are some important points to keep in mind:

First and foremost - the Livecycle Docker Extension is integrated with Docker, and provides a smoother experience for Docker users. Consistent URLs, private environments, organizations, and Google/Github authentication are supported out of the box.

Furthermore, in order to facilitate the collaborative workflows that developers need, it’s not enough to just share the local environment. A complete workflow solution also needs to get the team’s feedback back to the developer in an effective way. Sharing work without facilitating feedback doesn’t really help get the job done.

That’s why our shared environments include built-in collaboration tools that enable technical teammates access for remote debugging, and less-technical teammates the ability to leave review feedback in context, while the code is still sitting on the developer’s machine.

The Livecycle dashboard provides debugging capabilities that include log inspection, shell access, and container inspection.

This ability to both share and collaborate is a powerful differentiator that sets Livecycle apart from other infrastructure-focused solutions.

Here are two common use cases to illustrate this:

In-progress UI Reviews

One of the most common use cases for the Livecycle extension is enabling collaboration between developers and non-technical stakeholders early in the workflow. Using the Livecycle extension, you can get instant feedback on the latest front-end changes you’re working on your machine.

By simply opening a tunnel and creating a shareable URL, you enable anyone on the team to use a browser to securely access the relevant services.

So designers, QA, marketing and management can all see the application and use built-in commenting and collaboration tools to leave clear, actionable feedback. And since everything is in context, you’ll be able to communicate quickly and fix issues MUCH earlier in the development lifecycle.

In-progress debugging

Another common use case is enabling developers to work together to review and debug code changes as soon as possible.

With the Livecycle extension, you can instantly share any front end or back end service running on your machine.

By simply opening a tunnel and creating a shareable URL, you enable your team to use their browsers to securely access these services.

Your teammates can now see real-time logging, catch errors and execute commands in a terminal, so you can collaboratively fix issues MUCH earlier in the development lifecycle.

Self-hosted ephemeral environments

And in addition to all this, Livecycle doesn’t stop with just sharing localhost. Developers can also provision self-hosted ephemeral environments in the cloud provider of their choice to maintain the current state for longer review sessions that continue even when the developer's local computer is offline.

We’ll talk more about this in the following question.

At some point, that developer needs to close their computer. What happens then??

It’s true. Developers are people too. And sometimes even they need to close the computer and go home for the evening.

Thankfully, using Livecycle, this doesn’t need to mean the end of the review cycle.

This is because, in addition to securely sharing localhost, developers can use Livecycle to provision self-hosted ephemeral environments in the cloud provider of their choice to maintain the current state for longer review sessions that continue even when the developer's local computer is offline.

This is done using “Preevy” - our open-source tool for quickly provisioning preview environments to any cloud or Kubernetes cluster. It works seamlessly with the Docker Extension to publish shareable environments on demand, or as an automated part of your CI workflow, per PR or commit.

To learn more about how to use Preevy, just check out the docs site.

Come on. There’s no way this kind of thing is secure.

Sorry to disappoint you. But you’re wrong. :-)

wrong

The Livecycle Docker Extension uses a secure SSH tunnel to expose your local development environment using Livecycle's tunnel server, which is only accessible using HTTPS.

Furthermore, you can use the settings to enable private URLs to further control and restrict access to your environments.

So security is not something you’ll need to worry about.

Great. But this probably has limited support for the frameworks and languages I’m working with.

Not so fast buddy… you’ll be happy to know that Livecycle is language and framework-agnostic. It works with anything that runs in a Docker container. And if you’re using Preevy to provision preview environments to the cloud, you can use any cloud back end or Kubernetes cluster to do so.

What if I run into a problem? I’m sick of wasting my time talking to AI chatbots.

Good news - we’re 100% human. We’re a team of experienced developers building tools that are impacting the way dev teams collaborate with each other. Join our Slack channel to get updates, or get in touch with our team at any time and with any questions.

We'd be thrilled to have you join the community and try our Docker Extension today.