Atlassian hat die digitalen Boards in Jira Software einer Generalüberholung unterzogen und ein neues, überarbeitetes Nutzererlebnis vorgestellt, das zunächst für Jira Cloud ausgeliefert wird. Hier sind die wichtigsten Neuerungen.
Heute Abend bieten wieder ein Webinar an, das viele unserer Atlassian-Kunden interessieren könnte. Diesmal geht es um systematisches Dokumentenmanagement in Confluence – ein Thema, das angesichts der Offenheit von Confluence zahlreiche Unternehmen umtreibt. Von 21:00 bis 22:00 Uhr werden Martin Seibert (//SEIBERT/MEDIA) und Simon Gatto (Comalatech) die Confluence-Erweiterung Comala Workflows vorstellen und diskutieren.
Code-Reviews bilden ein wichtiges Werkzeug im Prozess der Software-Entwicklung, um eine bestmögliche Code-Qualität sicherzustellen. Sie fördern den Austausch im Team über die Code-Struktur, den Stil und die Architektur, und natürlich dienen sie dazu, sowohl Optimierungspotentiale als auch Schwachstellen aufzudecken. In diesem Artikel zeigen wir, wie Atlassians Git-Repository-Manager Stash in Kombination mit SonarQube, einem ausgereiften Tool zur statischen Code-Analyse, und dem Sonar-Plugin für Stash Code-Reviews und damit den Entwicklungsprozess effektiv unterstützen kann.
Die Grundlagen des Forking-Workflows für Teams, die Git als verteilte Versionskontrolle nutzen, wurden im vorangehenden Artikel umrissen. Nun folgt ein konkretes Beispiel, das zeigt, wie Entwickler nach diesem Prozess zusammenarbeiten können.
Der Forking-Workflow unterscheidet sich fundamental von den bislang besprochenen Git-Workflows. In diesen kommt ein einzelnes serverseitiges Repository als zentrale Codebasis zum Einsatz. Im Forking-Workflow jedoch hat jeder Entwickler ein serverseitiges Repository. Jeder Beteiligte arbeitet also mit zwei Repos: einer privaten, lokalen Instanz und einer öffentlichen auf Server-Seite.
Der Gitflow-Workflow definiert ein striktes Branching-Modell für Entwicklungsteams, das auf die nahtlose Auslieferung von Releases in großen Software-Projekten abzielt. Nachdem der vorangehende Artikel die Grundlagen dieses Prozesses umrissen hat, zeigt das folgende Beispiel eines einzelnen Release-Zyklus‘ nun, wie ein Team konkret nach diesem Workflow arbeiten kann.
Diese Reihe von Artikeln beschäftigt sich mit Workflows für Entwicklungsteams, die Git als verteiltes Versionskontrollsystem adaptieren. Nach dem zentralisierten und dem Feature-Branch-Workflow geht es nun um den Gitflow-Workflow, der sich weitere Vorteile von Git zunutze macht und einen belastbaren Rahmen für große Software-Projekte bietet.
Im letzten Artikel sind wir auf die Vorteile eingegangen, Feature-Branches in den Entwicklungsprozess mit Git zu integrieren, um die Zusammenarbeit zu intensivieren und die Kommunikation zwischen den Entwicklern zu straffen. Dieser Folgebeitrag bietet ein Beispiel dafür, wie Entwickler nach dem Feature-Branch-Workflow kollaborieren und sich Pull-Requests zunutze machen können.
Git-Workflows: Der Feature-Branch-Workflow (Teil 1) [ 6:05 ] Jetzt abspielen | Play in Popup | DownloadFür Teams, die Git als verteilte Versionskontrolle adaptieren wollen, ist es oft problematisch, den richtigen Einstiegspunkt für die Implementierung zu finden. Wir beschreiben in mehreren Artikeln die am häufigsten genutzten Git-Workflows in Enterprise-Settings und zeigen einige Möglichkeiten auf, Aspekte verschiedener Workflows zu vermengen und anzupassen, um individuelle Anforderungen des Entwicklungsteams abzudecken. Nach dem zentralisierten Workflow, der den Subversion-Prozess auf die Git-Entwicklung überträgt, kommen wir nun zum deutlich flexibleren Feature-Branch-Workflow.
Wenn Teams Git adaptieren wollen, ist es oft problematisch, den richtigen Einstieg für die Implementierung zu finden. Daher erläutern wir in mehreren Beiträgen die am häufigsten genutzten Git-Workflows. Der erste Teil dieses Artikels ist auf den klassischen zentralisierten Workflow eingegangen, den viele Teams von Subversion kennen. Nun zeigen wir, wie ein exemplarisches kleines Team mithilfe dieses Workflows zusammenarbeitet: Entwickler A und Entwickler B können an verschiedenen Features arbeiten und ihre Beiträge via zentralisierter Repository teilen.
