Remote Development Environments (RDEs) are in vogue. But what can you expect from RDEs? We present 5 companies and their results in this blog post.

Docker and containers in general have become indispensable in modern software development. Containers are also often used locally to avoid problems with the local development environment and the operation of the software to be developed. However, this brings new challenges. In this blog post we describe why containers are a first step in the right direction, but don’t solve all the problems.

One of the most complex aspects of development environments is that the software to be developed should itself be part of the development environment. Many companies therefore place high hopes in automated CI/CD pipelines: these enable the software to be developed to be installed on a remote server via an automated process. This often leads to the expectation that running the software to be developed locally will become obsolete. Is this correct?

A CI/CD pipeline allows developers to continuously integrate changes and run tests. This requires a pipeline, which is often defined via a configuration file or clicked together via a graphical interface. If complex projects have to be processed, configuration files lead to high effort. CI/CD as code is an alternative to overcome this challenge. We show how this works and how we implemented it at Cloudomation in this blog post.

Companies like Slack and Uber are already using cloud development environments (Also referred to as Cloud Development Environments / Remote Development Environments). The trend is likely to continue as more and more companies adopt teleworking or a hybrid model and need tools to enable their employees to develop quickly and easily. This article explores the tools for remote development environments.

Imagine you have launched a product that works well. Several versions are in circulation and being used by customers. So far so good. However, bugs in the old versions are giving you a hard time. A lot of time is lost on fixing them and your development team regularly complains about this effort. The reason for this is not the bug-fixing itself, but all the ancillary activities that go along with it. Especially the switch between different versions eats up time. How can this be prevented?

The perspectives of managers and developers seem to diverge strongly when it comes to the acceptance of RDEs. This article is about analysing this contradiction, the different perspectives and the reasons for it.

Good onboarding is like a first date – it makes the difference between a long-term relationship and a quick breakup. In fact, employees (and developers) are 58% more likely to be with the company after three years if they receive proper onboarding. Unfortunately, it still happens often enough in the beginning that new developers have to wander around like confused tourists in a strange city. But there is another way.

Remote Development Environments (RDEs) seem to be all the rage lately. Here’s the story of how I, as CEO, started thinking about RDEs as something we could use, to the point where we decided as a company to develop an RDE product.