Die Webanwendungsentwicklung hat sich markant verändert, wobei zahlreiche Tools und Frameworks versuchen, die Abläufe in der Programmierung zu vereinheitlichen. Die Builds und Deployments von Webanwendungen sind jedoch zunehmend komplexer geworden und erfordern oft eine Vielzahl an Konfigurationen. Die Zeiten der schnellen Deployments mit scp oder rsync auf dedizierten oder gemeinsam genutzten Hosting-Servern scheinen vorbei zu sein.
Im Mittelpunkt all dieser Fortschritte steht Git, das sich zum Industriestandard für Versionskontrolle, Codeverwaltung und Zusammenarbeit entwickelt hat. Git ist auch die Grundlage für moderne Software-Release-Lebenszyklen geworden. Genau hier kommt Deploio ins Spiel und liefert das fehlende Bindeglied, um den Release-Prozess von der Entwicklung bis zum Deployment in die Produktionsumgebung zu vervollständigen.
Deploio passt sich an Ihren Arbeitsablauf auf der Grundlage von Git-Revisionen an, unabhängig davon, ob Sie in der Anfangsphase schnell iterieren, bereits einen strikten Release-Zyklus aufgestellt haben oder ein Legacy-Projekt mit unregelmässigen Aktualisierungen pflegen.
Falls automatisierte Deployments neu für Sie sind, müssen Sie keine eigene CI/CD-Pipeline einrichten. Deploio übernimmt die Erstellung Ihres Projekts und kann sogar vorab Ihre geschriebenen Tests ausführen, um einen unterbrechungsfreien Service zu gewährleisten, wobei all dies auf der Infrastruktur von Nine betrieben wird.
Git-Revisionen: Branches, Commits und Tags
Die folgenden drei Git-Objekte können auch als Revisionen bezeichnet werden.
Commits: Die kleinste Einheit, mit der eine Änderung in einem Repository vorgenommen werden kann. Sofern sie nicht Teil eines main Branches sind, werden sie möglicherweise irgendwann gelöscht oder durch andere Commits ersetzt.
Branches: Branches ermöglichen es, zusätzliche Entwicklungslinien zu starten, sodass an verschiedenen Gruppen von Commits gleichzeitig gearbeitet werden kann. Branches werden oft mit anderen zusammengeführt, was zu einer neuen Revision führt.
Tags: Tags verweisen auf bestimmte Commits, in der Regel auf main Branches, und werden oft verwendet, um einen Release zu definieren. Sie sollten als unveränderlich betrachtet werden.
Verwalten von Releases auf Deploio mit Git
Es gibt zahlreiche Software-Release-Strategien, die oft mit anderen Entwicklungspraktiken verbunden sind. Um sich auf den Deployment-Aspekt dieser Strategien zu konzentrieren, haben wir sie anhand ihrer Frequenz in drei Haupttypen eingeteilt.
Denken Sie daran, dass kurzlebige Revisionen wie Commits und Branches aus Ihrem Git-Repository verschwinden können, wodurch Deploio-Builds fehlschlagen können. Im Allgemeinen werden laufende (verfügbare) Deploio-Releases nicht durch fehlgeschlagene Builds oder Releases ersetzt, die nicht gestartet werden können.
Kontinuierliche Deployments
Kontinuierliche Deployments, die auch als Rolling Releases bezeichnet werden, sind in der Regel an einen bestimmten Branch gebunden. Da sie eine hohe Frequenz an Deployments ermöglichen, sind sie ideal für instabile Integrations- und Entwicklungs-Branches, bei denen schnelle Feedback-Zyklen erwünscht sind.
Im folgenden Szenario wird eine separate Entwicklungsinstanz für die Anwendung erstellt, die auf dem ‘dev’ Branch basiert. Da Optionen wie –port zuvor in den Configuration Presets der Projekt-Konfigurationsebene gespeichert wurden, müssen diese nicht angegeben werden:
nctl create application urlshortener-dev \
--project=marco-deployment-demo \
--git-url=https://github.com/ninech/deploio-examples \
--git-sub-path=dockerfile/java-kvs \
--dockerfile \
--env=SPRING_PROFILE_ENV=dev \
--size=micro \
--git-revision=dev # Git branch
Änderungen an den Commits auf dem dev-Branch führen automatisch zu einem Build- und Release-Vorgang auf Deploio.
Kontinuierliche Deployments können natürlich auch auf Produktionsumgebungen angewendet werden, insbesondere, wenn bereits ausgereifte CI/CD-Praktiken und -Tools vorhanden sind, zum Beispiel auf der Grundlage von GitHub Actions.
Geplante Deployments
Auch als stabile oder fixierte Releases bekannt, werden Änderungen bei geplanten Deployments auf der Grundlage einer definierten Version ausgerollt, welche in der Regel ausführlich getestet wurde. Die Release-Version kann durch ein Git-Tag abgebildet werden und einem gängigen Schema folgen, zum Beispiel dem der semantischen Versionierung.
Im folgenden Beispiel wird ein bestimmtes Versions-Tag ausgerollt:
nctl update application urlshortener-prod \
--project=marco-deployment-demo \
--git-revision=v1.1.0 # Git tag
Sofortige Deployments
Manchmal sind Deployments ausserhalb der regulären Release-Zyklen erforderlich. Dabei kann es sich um ein Rollback zu einer früheren Version aufgrund von Produktionsproblemen handeln, um die Rückportierung einer Änderung aus dem main-Branch in eine ältere Version oder um ein Deployment eines bestimmten Branches oder Commits.
Hier ist ein Beispiel, bei dem die Entwicklungsinstanz verwendet wird, um einen bestimmten Feature-Branch für externe Tests verfügbar zu machen:
nctl update application urlshortener-dev \
--project=marco-deployment-demo \
--git-revision=feature/dark-mode # Git branch
Bei Bedarf kann auch ein bestimmter Commit aus einem beliebigen Branch verwendet werden:
nctl update application urlshortener-dev \
--project=marco-deployment-demo \
--git-revision=e8273c3f # Git commit
Schrittweise Bereitstellung
Wie bereits erwähnt, kann für Software auf verschiedene Arten ein Release erstellt werden. Ein fortschrittlicher Ansatz, der sich besonders für umfangreiche und potenziell verteilte Anwendungen eignet, ist die schrittweise Bereitstellung (Progressive Delivery). Dabei werden neue Funktionen oder Versionen nur teilweise für eine Untergruppe von Benutzern oder Umgebungen freigegeben, bevor sie in vollem Umfang bereitgestellt werden.
Beliebte Techniken im Rahmen der progressiven Bereitstellung sind Canary Releases und Blue-Green Deployments. Zum Zeitpunkt dieses Beitrags sind solche Deployments auf der von Nine verwalteten Infrastruktur nur möglich, wenn das Deployment auf Kubernetes stattfindet, verwaltet von beispielsweise unserem Argo CD Service, zusammen mit Managed GKE oder NKE.
