Die Webanwendungsentwicklung hat sich markant ver\u00e4ndert, wobei zahlreiche Tools und Frameworks versuchen, die Abl\u00e4ufe 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.<\/p>\n\n\n\n
Im Mittelpunkt all dieser Fortschritte steht Git, das sich zum Industriestandard f\u00fcr Versionskontrolle, Codeverwaltung und Zusammenarbeit entwickelt hat. Git ist auch die Grundlage f\u00fcr moderne Software-Release-Lebenszyklen geworden. Genau hier kommt Deploio<\/a> ins Spiel und liefert das fehlende Bindeglied, um den Release-Prozess von der Entwicklung bis zum Deployment in die Produktionsumgebung zu vervollst\u00e4ndigen.<\/p>\n\n\n\n Deploio passt sich an Ihren Arbeitsablauf auf der Grundlage von Git-Revisionen an, unabh\u00e4ngig davon, ob Sie in der Anfangsphase schnell iterieren, bereits einen strikten Release-Zyklus aufgestellt haben oder ein Legacy-Projekt mit unregelm\u00e4ssigen Aktualisierungen pflegen.<\/p>\n\n\n\n Falls automatisierte Deployments neu f\u00fcr Sie sind, m\u00fcssen Sie keine eigene CI\/CD-Pipeline einrichten. Deploio \u00fcbernimmt die Erstellung Ihres Projekts und kann sogar vorab Ihre geschriebenen Tests ausf\u00fchren, um einen unterbrechungsfreien Service zu gew\u00e4hrleisten, wobei all dies auf der Infrastruktur von Nine betrieben wird.<\/p>\n\n\n\n Die folgenden drei Git-Objekte k\u00f6nnen auch als Revisionen bezeichnet werden.<\/p>\n\n\n\n Commits: Die kleinste Einheit, mit der eine \u00c4nderung in einem Repository vorgenommen werden kann. Sofern sie nicht Teil eines main Branches sind, werden sie m\u00f6glicherweise irgendwann gel\u00f6scht oder durch andere Commits ersetzt.<\/p>\n\n\n\n Branches: Branches erm\u00f6glichen es, zus\u00e4tzliche Entwicklungslinien zu starten, sodass an verschiedenen Gruppen von Commits gleichzeitig gearbeitet werden kann. Branches werden oft mit anderen zusammengef\u00fchrt, was zu einer neuen Revision f\u00fchrt.<\/p>\n\n\n\n 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\u00e4nderlich betrachtet werden.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Denken Sie daran, dass kurzlebige Revisionen wie Commits und Branches aus Ihrem Git-Repository verschwinden k\u00f6nnen, wodurch Deploio-Builds fehlschlagen k\u00f6nnen. Im Allgemeinen werden laufende (verf\u00fcgbare) Deploio-Releases nicht durch fehlgeschlagene Builds oder Releases ersetzt, die nicht gestartet werden k\u00f6nnen.<\/p>\n\n\n\n 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\u00f6glichen, sind sie ideal f\u00fcr instabile Integrations- und Entwicklungs-Branches, bei denen schnelle Feedback-Zyklen erw\u00fcnscht sind.<\/p>\n\n\n\n Im folgenden Szenario wird eine separate Entwicklungsinstanz f\u00fcr die Anwendung erstellt, die auf dem ‘dev’ Branch basiert. Da Optionen wie –port zuvor in den Configuration Presets der Projekt-Konfigurationsebene<\/a> gespeichert wurden, m\u00fcssen diese nicht angegeben werden:<\/p>\n\n\n \u00c4nderungen an den Commits auf dem dev-Branch f\u00fchren automatisch zu einem Build- und Release-Vorgang auf Deploio.<\/p>\n\n\n\n Kontinuierliche Deployments k\u00f6nnen nat\u00fcrlich auch auf Produktionsumgebungen angewendet werden, insbesondere, wenn bereits ausgereifte CI\/CD-Praktiken und -Tools vorhanden sind, zum Beispiel auf der Grundlage von GitHub Actions<\/a>.<\/p>\n\n\n\n Auch als stabile oder fixierte Releases bekannt, werden \u00c4nderungen bei geplanten Deployments auf der Grundlage einer definierten Version ausgerollt, welche in der Regel ausf\u00fchrlich getestet wurde. Die Release-Version kann durch ein Git-Tag abgebildet werden und einem g\u00e4ngigen Schema folgen, zum Beispiel dem der semantischen Versionierung<\/a>.<\/p>\n\n\n\n Im folgenden Beispiel wird ein bestimmtes Versions-Tag ausgerollt:<\/p>\n\n\n Manchmal sind Deployments ausserhalb der regul\u00e4ren Release-Zyklen erforderlich. Dabei kann es sich um ein Rollback zu einer fr\u00fcheren Version aufgrund von Produktionsproblemen handeln, um die R\u00fcckportierung einer \u00c4nderung aus dem main-Branch in eine \u00e4ltere Version oder um ein Deployment eines bestimmten Branches oder Commits.<\/p>\n\n\n\n Hier ist ein Beispiel, bei dem die Entwicklungsinstanz verwendet wird, um einen bestimmten Feature-Branch f\u00fcr externe Tests verf\u00fcgbar zu machen:<\/p>\n\n\n Bei Bedarf kann auch ein bestimmter Commit aus einem beliebigen Branch verwendet werden:<\/p>\n\n\n Wie bereits erw\u00e4hnt, kann f\u00fcr Software auf verschiedene Arten ein Release erstellt werden. Ein fortschrittlicher Ansatz, der sich besonders f\u00fcr umfangreiche und potenziell verteilte Anwendungen eignet, ist die schrittweise Bereitstellung (Progressive Delivery). Dabei werden neue Funktionen oder Versionen nur teilweise f\u00fcr eine Untergruppe von Benutzern oder Umgebungen freigegeben, bevor sie in vollem Umfang bereitgestellt werden.<\/p>\n\n\n\n Beliebte Techniken im Rahmen der progressiven Bereitstellung sind Canary Releases<\/a> und Blue-Green Deployments<\/a>. Zum Zeitpunkt dieses Beitrags sind solche Deployments auf der von Nine verwalteten Infrastruktur nur m\u00f6glich, wenn das Deployment auf Kubernetes stattfindet, verwaltet von beispielsweise unserem Argo CD Service, zusammen mit Managed GKE<\/a> oder NKE<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Die Webanwendungsentwicklung hat sich markant ver\u00e4ndert, wobei zahlreiche Tools und Frameworks versuchen, die Abl\u00e4ufe 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.<\/p>\n","protected":false},"author":23,"featured_media":3823,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[399,405],"tags":[413],"class_list":["post-3828","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-know-how-de","category-product-news","tag-deploio-de"],"acf":[],"yoast_head":"\nGit-Revisionen: Branches, Commits und Tags<\/h2>\n\n\n\n
Verwalten von Releases auf Deploio mit Git<\/h2>\n\n\n\n
Kontinuierliche Deployments<\/h3>\n\n\n\n
\nnctl create application urlshortener-dev \\\n\u00a0\u00a0--project=marco-deployment-demo \\\n\u00a0\u00a0--git-url=https:\/\/github.com\/ninech\/deploio-examples \\\n --git-sub-path=dockerfile\/java-kvs \\\n\u00a0\u00a0--dockerfile \\\n\u00a0\u00a0--env=SPRING_PROFILE_ENV=dev \\\n\u00a0\u00a0--size=micro \\\n\u00a0\u00a0--git-revision=dev # Git branch\n<\/pre><\/div>\n\n\n
Geplante Deployments<\/h3>\n\n\n\n
\nnctl update application urlshortener-prod \\\n\u00a0\u00a0--project=marco-deployment-demo \\\n\u00a0\u00a0--git-revision=v1.1.0 # Git tag\n<\/pre><\/div>\n\n\n
Sofortige Deployments<\/h3>\n\n\n\n
\nnctl update application urlshortener-dev \\\n\u00a0\u00a0--project=marco-deployment-demo \\\n\u00a0\u00a0--git-revision=feature\/dark-mode # Git branch\n<\/pre><\/div>\n\n\n
\nnctl update application urlshortener-dev \\\n\u00a0\u00a0--project=marco-deployment-demo \\\n\u00a0\u00a0--git-revision=e8273c3f # Git commit\n<\/pre><\/div>\n\n\n
Schrittweise Bereitstellung<\/h3>\n\n\n\n