Blog

Docker und Container im Allgemeinen sind in der modernen Softwareentwicklung nicht mehr wegzudenken. Auch lokal werden oftmals Container genutzt, um Probleme mit der lokalen Entwicklungsumgebung und dem Betrieb der zu entwickelnden Software zu vermeiden. Das bringt allerdings neue Herausforderungen mit sich In diesem Blogpost beschreiben wir, warum Container ein erster Schritt in die richtige Richtung sind, aber nicht alle Probleme lösen.

Einer der komplexesten Aspekte von Entwicklungsumgebungen ist, dass die zu entwickelnde Software selbst Teil der Entwicklungsumgebung sein soll. Viele Unternehmen setzen daher große Hoffnungen in automatisierte CI/CD Pipelines: Diese ermöglichen es, die zu entwickelnde Software über einen automatisierten Prozess auf einem Remote-Server zu installieren. Daraus entsteht oft die Erwartung, dass das lokale Betreiben der zu entwickelnden Software obsolet wird. Ist das richtig?

Eine CI/CD-Pipeline ermöglicht Entwickler_innen, Änderungen kontinuierlich zu integrieren und Tests durchzuführen. Dazu ist eine Pipeline notwendig, die oft über eine Konfigurationsdatei definiert oder per grafischem Interface zusammengeklickt wird. Müssen komplexe Projekte bearbeitet werden, führen Konfigurationsdateien zu hohem Aufwand. CI/CD als Code ist eine Alternative, um diese Herausforderung zu meistern. Wie das funktioniert und wir das bei Cloudomation umgesetzt haben, zeigen wir in diesem Blogpost.

Unternehmen wie Slack und Uber setzen bereits auf Cloud-Entwicklungsumgebungen (Auch als Cloud Development Environments / Remote Development Environments bezeichnet). Der Trend wird sich wahrscheinlich fortsetzen, weil immer mehr Unternehmen Telearbeit oder ein Hybrid-Modell einführen und Tools benötigen, um ihren Mitarbeiter_innen ein schnelles und unkompliziertes Entwickeln zu ermöglichen. Welche Tools gibt es für den Einsatz von Remote Development Environments / Cloud Development Environments?

Stellen Sie sich vor, Sie haben ein Produkt auf den Markt gebracht, das sehr gut funktioniert. Mehrere Versionen sind im Umlauf und werden von Kunden genutzt. Soweit so gut. Allerdings machen Ihnen Bugs in den alten Versionen zu schaffen. Es geht viel Zeit für das Fixing verloren und Ihr Entwicklerteam beschwert sich regelmäßig über diesen Aufwand. Der Grund dafür ist aber nicht das Bug-Fixing an sich, sondern all die Nebentätigkeiten, die damit verbunden sind. Vor allem der Switch zwischen verschiedenen Versionen frisst Zeit. Wie lässt sich das verhindern?

Die Perspektive von Manager_innen und Entwickler_innen scheint stark auseinander zu gehen, wenn es um die Akzeptanz von RDEs geht. Um die Analyse dieses Widerspruchs, der unterschiedlichen Perspektiven und die Gründe dafür – darum geht es in diesem Beitrag.

Ein gutes Onboarding ist wie ein erstes Date – es entscheidet über eine langfristige Beziehung oder über eine schnelle Trennung. Tatsächlich ist die Wahrscheinlichkeit um 58 % höher, dass Mitarbeiter_innen (und damit auch Entwickler_innen) nach drei Jahren noch im Unternehmen sind, wenn sie ein ordentliches Onboarding erhalten. Leider passiert es am Anfang aber noch immer oft genug, dass neue Entwickler_innen wie verwirrte Touristen in einer fremden Stadt herumirren müssen. Doch es geht auch anders.

Remote Development Environments (RDEs) scheinen in letzter Zeit überall Thema zu sein. Hier ist die Geschichte, wie ich als CEO anfing, über RDEs als etwas nachzudenken, das wir brauchen könnten, bis zu dem Punkt an dem wir als Unternehmen beschlossen, ein RDE-Produkt zu entwickeln.

Details zu CI/CD-Pipelines werden kaum preisgegeben. In diesem Beitrag zeigen wir deshalb, wie unsere Pipeline aufgebaut ist und warum eine CI/CD-Pipeline die lokale Entwicklungsumgebung nicht ersetzt.