Webhook für Smart Mirrors

Atlassian hat einen neuen Webhook ausgeliefert, der CI-Systemen mitteilt, wenn ein Spiegel-Server die Synchronisation bestimmter Änderungen beendet hat. Dieser Webhook stellt sicher, dass CI-Systeme die richtigen Änderungen auch garantiert registrieren.

Integriertes Informationsbanner

Ein neues Ankündigungsbanner dient dazu, wichtige Informationen, die z.B. die Systemverfügbarkeit, geplante Downtimes usw. betreffen, klar und transparent zu kommunizieren.

Optimiertes File Locking für den Git LFS

Mit der Version 6.3 hat Atlassian das File Locking für den Git Large File Storage ausgeliefert. Hier ist der Hebel nun noch einmal an der Nutzerfreundlichkeit angesetzt worden: Ein neues Icon neben einem gesperrten Objekt macht sofort deutlich, dass es derzeit geschützt ist. Per Hover ist außerdem ersichtlich, wer die Datei gesperrt hat und wann.

File Locking für den Git Large File Storage

Der Git Large File Storage bietet nun die Möglichkeit des File Lockings. Damit hat ein Entwickler jetzt die Option, vor dem Editieren zu schützen, während er an ihr arbeitet. Diese Vorsichtsmaßnahme soll dabei helfen, schwierig aufzulösende Merge-Konflikte zu vermeiden, wenn Teams beispielsweise an Videos, 3D-Modellen und anderen Arten von großen Binärdateien arbeiten.

Commits vergleichen

Per Klick auf das neue Compare-Sysmbol in der Sidebar können Nutzer einen Commit mit einem anderen Commit, Branch oder Tag vergleichen und die Ergebnisse dieses Vergleichs schnell mit dem Team teilen, indem sie die URL senden.

Zusätzliche Beschreibungen für Repos

Repositories können nun um kurze Beschreibungen ergänzt werden. Damit werden sie leichter identifizierbar und um zusätzlichen Kontext reicher. Beschreibungen lassen sich direkt beim Erstellen eines Repos oder nachträglich in den Repo-Einstellungen hinzufügen.

Absolute Zeitstempel

Teams haben jetzt die Option, in ihrer Instanz statt der relativen Zeitangaben absolute Timestamps mit Datum und Uhrzeit einer Änderung ausgeben zu lassen. Das kann in bestimmten Szenarien für zusätzliche Präzision sorgen.

SVG-Quellcode einsehen

Entwickler können den Quellcode von SVG-Dateien direkt in Bitbucket einsehen und sogar editieren. Das ist sowohl in der Diff- als auch in der Source-Ansicht möglich.

Check vor dem Löschen

Um die Gefahr eines versehentlichen Löschens von Projekten und Repos fügt Bitbucket diesem Prozess eine zusätzliche Aufmerksamkeitsschwelle hinzu. Vor dem Löschen eines solchen Objekts steht jetzt ein zusätzlicher Check: Der User muss zur Bestätigung erst den Namen des Projekts oder Repositorys eingeben.

Anpassbarer Support-Link

Der Kontakt-Link im Fußbereich einer Bitbucket-Instanz ist nun anpassbar, sodass Teams hier beispielsweise direkt den Support oder auch eine E-Mail-Adresse verlinken können.

Commit-Graph zur Visualisierung von Commits

Um das Auffinden von Commits zu erleichtern, die Beziehungen zwischen ihnen besser verständlich zu machen und das gesamte Repository zu visualisieren, bietet Bitbucket nun einen nativen Commit-Graphen (ein- und ausklappbar). Hier können Entwickler die Commit-Historie jederzeit schnell einsehen.

Technische Weichenstellung für die zukünftige Weiterentwicklung

Für das neuen Major Release 6.0 hat Atlassian die technischen Grundlagen von Bitbucket Server und Data Center aktualisiert. Bitbucket bietet jetzt Unterstützung für Java 11 JRE. Außerdem wurden Großteile des Bitbucket-Kerns aktualisiert - darunter Apache Tomcat, Spring Boot, Spring Framework, Hibernate und andere wichtige Abhängigkeiten. Auch die Clustering-Middleware Hazelcast hat ein Update erhalten, um für Data-Center-Installationen eine noch höhere Zuverlässigkeit und eine noch bessere Performance zu erzielen.

Zusätzliche Speicherorte hinzufügen

In großen Teams kann der Umfang an Repository-Daten in einer Bitbucket-Data-Center-Instanz zu groß werden, um sie in an einem einzelnen Speicherort vorzuhalten. Für solche Szenarien bietet Bitbucket jetzt die Alternative, weitere Orte für die Datenspeicherung hinzuzufügen.

Anonymisierung von Nutzer-Accounts

Im Release 5.16 hat Atlassian die bestehende Löschen-Funktionalität verfeinert, indem die Möglichkeit hinzugefügt wurde, gelöschte Nutzer-Accounts zu anonymisieren. Dabei werden der Nutzername und persönliche Mentions sowie ggf. die Personendaten in persönlichen Projekten durch nicht zurückführbare Alias-Angaben ersetzt. Außerdem übernimmt das System den User-Cleanup, falls noch nicht geschehen (z.B. Löschen von Avataren, SSH-Schlüsseln, Berechtigungen).

Die eigentlichen Inhalte des Nutzers (z.B. Kommentare, Pull-Requests) und die User-Daten in der Git-Historie bleiben erhalten.

Coming soon: Bitbucket Data Center in Azure installieren

Bitbucket bietet nun eine Referenz-Implementierungsvorlage, die hilft, Bitbucket Data Center in Microsoft Azure zu installieren. Dieses Template lässt sich nach Bedarf anpassen und via Azur Marketplace oder per CLI deployen. Diese Möglichkeit kann beispielsweise dazu dienen, Bitbucket auszuprobieren, ohne zunächst eigene Hardware zur Verfügung stellen zu müssen.

Code Insights

CI-Systeme und andere Tools zur Code-Analyse produzieren vielerlei Informationen über die evolvierende Codebasis, aber kann das Entwicklungsteam sich diese Informationen auch zunutze machen?

Code Insights versetzt Entwicklungsteams in die Lage, von diesen Daten ohne ständige Kontextwechsel und Commit-Revisionen zu profitieren. Nun lassen sich wichtige Entwicklungsinformationen direkt in Pull-Requests präsentieren, beispielsweise statische Anaylseberichte, Ergebnisse von Security-Scans, Artefakt-Links, Unit-Tests, Build-Status. Damit ist es möglich, potenzielle Probleme proaktiv zu diagnostizieren, Testzyklen zu verkürzen und besser fundierte Entscheidungen zu treffen.

Code Insights bietet eine API und ein User Interface, sodass Drittanbieter-Apps entsprechende Daten liefern können.

Data-Center-Migrations-Feature

Ein neues Data-Center-Migrations-Feature unterstützt Administratoren bei der Konsolidierung der Bitbucket-Instanzen im Unternehmen. Das Werkzeug erlaubt es, alle Git-Daten und Pull-Requests (inklusive Kommentaren und Anhangshistorie) zu importieren oder zu exportieren und reibungslos aus anderen Server-Instanzen in ein zentrales Data-Center-System umzuziehen.

Support für Git v2

Als erste On-premise-Plattform unterstützt Bitbucket Server jetzt das Git-Protokoll 2.

Pull-Requests zu Commits sehen

In der Commit-Suche ist zu einem gegebenen Commit nun der entsprechende Pull-Request direkt sichtbar. So ergeben sich ein klarer Kontext und ein vollständiges Bild einer Änderung.

Label für Repositories

Label eröffnen einen Weg, um unter den zahllosen Repositories das gewünschte gezielt zu suchen und zu identifizieren. Bis zu fünf solcher Tags ermöglichen es jetzt, ein Repo beispielsweise nach Sprache, Framework, Service-Typ und weiteren Kriterien in Kontext zu setzen.

Neue Anordnung in Pull-Request-Kommentaren

Jede neue Anmerkung in Kommentaren ist jetzt sofort oben sichtbar, ohne scrollen zu müssen – egal, ob es sich dabei um einen neuen Kommentar oder um eine Antwort handelt. Mit einer neuen Antwort wird also der entsprechende Kommentar wieder nach oben gespült. (Andere Aktivitätstypen wie Updates oder Freigaben werden weiterhin chronologisch sortiert, da sich hier nachträglich nichts ändern kann.)

Pull-Request-Links

Bitbucket bietet jetzt Pull-Request-Links in Commits. Damit können Entwickler direkt zu Pull-Request springen, um den Kontext einer Code-Änderung besser zu erfassen.

Just-in-time-Fetching (nur Data Center)

Wenn ein Smart Mirror nicht mit dem Primär-Cluster synchron läuft (z.B. wegen eines Neustarts oder weil die Synchronisierung gerade durchgeführt wird), kann es passieren, dass eine Repository-Kopie vom Smart Mirror nicht mehr aktuell ist. Wenn ein Repo von einem Smart Mirror geklont oder gefetcht werden soll und der Smart Mirror "weiß", dass die lokale Kopie nicht aktuell ist, wird er versuchen, das Repo mit dem Upstream zu synchronisieren, bevor die Anfrage bedient wird.

Überarbeitetes Design

Die aktualisierten Atlassian Design Guidelines wurden nun auch für Bitbucket Server umgesetzt. Sie betreffen Änderungen an Typographie, Farben und Icons. Die Navigation ist davon unberührt geblieben.

Repositories beobachten

Nutzer haben jetzt die Möglichkeit, Benachrichtigungen zu Änderungen auf Repository-Ebene zu abonnieren. Sie erhalten dann automatisierte E-Mail-Notifications zu Aktivitäten in Pull-Requests und zu Push-Aktivitäten im Repo.

Neue Diagnostik-Tools

Performance-Probleme eines Git-Servers können massive Produktivitätsverluste zur Folge haben – und tatsächlich sind zahlreiche bekannte Issues auf das Zusammenspiel interner Komponenten mit Drittanbieter-Plugins zurückzuführen. Mithilfe neuer Diagnosewerkzeuge und -oberflächen in Bitbucket Server 5.9 können Administratoren Performance-Problemen auf den Grund gehen und sie nachverfolgen.

Globale Suche nach Commit-Hashs

Dank der verbesserten Commit-Suche können Entwickler nun den Commit-Hash in die Schnellsuche einkopieren und gelangen so direkt zur Commit-Ansicht.

Verbesserte Erstellung von Jira-Vorgängen aus Pull-Requests

Bitbucket erlaubt es bereits seit längerem, Jira-Vorgänge und Pull-Request-Kommentar zu verknüpfen. Bislang musste allerdings der Vorgangsdialog geöffnet werden, um auf Details wie Beschreibung, Typ und Status zuzugreifen. Diese Infos sind jetzt per Standard und ohne Extra-Klicks zugänglich.

Berücksichtigung von Interpunktion in der Code-Suche

Die Code-Suche bringt eine nuancierte, aber doch wichtige Neuerung mit. Bitbucket ist nun intelligenter, wenn User Suchen mit Zeichensetzung durchführen und beispielsweise Punkte oder Unterstriche mit einbinden. Sie können Abrfagen also exakt spezifizieren. Zuvor wurden solche Eingaben in der Suche nicht berücksichtigt.

Verbesserte Repo-Suche

Das Bitbucket-Team hat Suchzeiten, Nutzererlebnisse und inkonsistente Suchmethoden gründlich evaluiert und die Suchfunktion in Bitbucket Server verfeinert und optimiert. Neben einem neuen Look & Feel bietet sie funktionale Änderungen.

Fork-Sichtbarkeit

Atlassian hat auch daran gearbeitet, das Auffinden der eigenen persönlichen Forks sowie der anderen Forks eines Repositorys zu erleichtern. Alle Forks eines Repos können von einer Seite aus eingesehen werden. Von dort aus können User einfache Filter anwenden und gezielt finden, wonach sie suchen.

Personal Access Tokens

Mit Bitbucket 5.5 werden Personal Access Tokens ausgeliefert, die an die Stelle einer Basis-Authentifizierung treten und Integrations deutlich vereinfachen. Diese Zugriffs-Tokens werden auf einer Per-Nutzer-Basis angelegt und erben dieselben Berechtigungen wie dieser User - außer der der Möglichkeit, sich in die Bitbucket-Benutzeroberfläche einzuloggen.

Rebasing-Workflows

Statt wie bislang einen Client-seitigen Workaround nutzen zu müssen, können Teams jetzt die neue Rebasing-Option wählen, um einen Pull-Request-Branch zu aktualisieren oder um den Pull-Request insgesamt fertigzustellen.

Support für Webhooks

Die Unterstützung von Webhooks erlaubt es, Applikationen mit Bitbucket zu integrieren. Sie sind über die Bitbucket-Oberfläche konfigurierbar, sodass Bitbucket für spezifische Ereignisse Webhooks an Drittsysteme sendet.

Contribution-Guidelines

Diese neue Markup-Datei dient dazu, die Regeln und Standards transparent und sichtbar zu machen, die für ein Repository gelten.

Repository-Administration auf Projektebene

Statt wie bislang jedes neue Repository manuell konfigurieren zu müssen, ist es nun möglich, alle Repos in einem Projekt zentral zu administrieren (Branching-Modell, die Art der Merge-Strategie für Pull-Requests, Beschränkung des Branch-Zugriff, GPG-Signatur-Pflicht für Commits etc.). Diese Eigenschaften können auf alle Repos im Projekt angewendet werden. Neu angelegte Repositories erben die für das Projekt definierten Konfigurationen.

Push-Proxy für Smart Mirrors (Data-Center-Version)

Bisher waren bei der Arbeit mit Spiegel-Servern zwei URLs zu pflegen - eine für das Fetchen vom Spiegel und eine für das Pushen zum Primär-Server. Mit Bitbucket Data Center 5.2 hat Atlassian Push-Proxies eingeführt, wodurch beide Operationen zu einer einzelnen HTTP- oder SSH-URL kombiniert werden.

GPG-signierte Commits

Bitbucket bietet jetzt einen Git-Hook, der Commits oder Tags zurückweist, die nicht mit GPG-Schlüsseln signiert sind.

Löschen von Pull-Requests

Es ist nun möglich, abgelehnte oder offene Pull-Requests zu löschen, beispielsweise wenn ein Pull-Request versehentlich erstellt oder obsolet geworden ist.

Verbesserungen an der Suche

Teams können festlegen, welche Objekte von Elastic Search indiziert werden und welche nicht. Das ist für Teams hilfreich, die viel mit Forks arbeiten und dabei viel Speicherkapazität verbrauchen, hilfreich, denn sie können synchronisierte Forks von der Indizierung ausschließen.

Committer-Verifizierung

Mit Bitbucket 5 wird ein neuer Committer-Verifizierungs-Hook ausgeliefert. Mit ihm kann ein Team festlegen, dass nur der Ersteller eines Commits diesen auch ins zentrale Repo pushen kann.

Verbessertes Smart Mirroring (Bitbucket Data Center)

Bitbucket Data Center 5 bietet Authentifizierungs-Caching. Auch im Fall kurzer Ausfälle der Master-Instanz haben Entwickler weiterhin Zugriff auf den Spiegel-Server: Statt bei jedem Login-Ereignis mit dem Haupt-Server zu kommunizieren, werden die Zugangsdaten nun fünf Minuten lang im Cache des Mirrors vorgehalten.

Repository-Shortcuts

Mit Bitbucket 5 steht Teams eine neue Verknüpfungsmöglichkeit zwischen Repositories und anderen Inhalten zur Verfügung. Mithilfe von Repository-Shortcuts können Entwickler beliebige Objekte und Inhalte aus dem Repo heraus verlinken: Jira-Board, einen Confluence-Bereich, Bamboo-Pläne, Hipchat-Räume etc.

Noch tiefere Integration mit Bitbucket

Mit dem neuen In-Progress-Build-Status und Pull-Request-sensiblen Builds in Bamboo haben Entwickler mehr Kontrolle darüber, wann ihre Builds starten, und können die Fortschritt aus Bitbucket heraus nachverfolgen.

Emojis und Emoticons in Kommentaren

Bitbucket bietet in Kommentaren nun Emojis und Hipchat-Emoticons.

Zugriffsschlüssel auf Branch-Ebene

Um dem CI-Server und anderen automatisierten Prozessen die Interaktion mit dem Quellcode zu ermöglichen, können Teams Berechtigungen an Zugriffsschlüssel vergeben. Das ist nun auch möglich auf der Ebene einzelner Branches.

Automatisch aktualisiertes persönliches Dashboard

Das persönliche Dashboard muss nun nicht manuell aktualisiert werden, um Änderungen zu sehen. Wenn es Updates an Pull-Requests gibt, werden sie automatisch und ohne Refresh auf dem Dashboard angezeigt.

Verbesserte E-Mail-Benachrichtigungen zu Pull-Requests

Hinweise zu Änderungen bietet nun schon der Reviewer-Status im Kopfbereich der Benachrichtigung.

Dateien im Browser editieren

Für geringfügige Änderungen wie das Korrigieren eines Tippfehlers oder das Bearbeiten eines Readme-Files können Entwickler Dateien in Bitbucket editieren. Um bei Änderungen zu helfen, trifft der Editor eine Vorauswahl der Syntax basierend auf dem Dateityp. Der Entwickler kann eine Commit-Nachricht eingeben und er hat sogar die Option, einen Pull-Request zu erstellen. Einfache Änderungen lassen sich jetzt also viel schneller vornehmen, ohne Repositories klonen und lokal arbeiten zu müssen.

Assoziierte Jira-Issues leichter finden

Als weiteren Teil dieser Integration führt Bitbucket Server eine nochmals verbesserte Einbindung von Jira-Vorgängen ein: Vorgangsschlüssel werden über die gesamte Bitbucket-Oberfläche hinweg automatisch immer zu Deeplinks auf das angebundene Jira-System.

SAML-2.0-Support (Bitbucket Data Center)

Für Administratoren, die das Nutzermanagement in Bitbucket Data Center vereinfachen möchten, bietet das System mit der neuen Version Out-of-the-box-Unterstützung für Single-sign-on mit SAML 2.0.

Elastic Experiment Executor (E3)

Das neu ausgelieferte Tool Elastic Experiment Executor (E3) hilft bei systematischen Performance-Experimenten. Mit diesem Werkzeug können Teams beliebige Bitbucket-Konfigurationen durchspielen, das System einer wiederholbaren Arbeitslast von beliebigem Umfang und beliebiger Art aussetzen sowie den Durchsatz, die Antwortzeiten und weitere Statistiken einsehen, während Bitbucket läuft.

Iterative Reviews: Änderungen seit dem letzten Review sehen

Mit dem neuen Release zeigt Bitbucket Server exakt an, was sich in einem Pull-Request seit dem letzten Review verändert hat. Damit sind das mühsame Durchsehen von Dateien nach Edits und das Re-Reviewen von Code, den man bereits angeschaut hat, passè. Wenn ein Entwickler zu einem aktualisierten Review zurückkehrt, bietet Bitbucket ihm automatisch die Zahl der Commits seit seinem letzten Review. So kann er sich darauf beschränken, tatsächlich nur die ganz aktuell hinzugefügten Commits zu kommentieren.

Iterative Reviews: Mit Gewissheit mergen

Hat denn auch jeder im Team den Fix für diesen großen Vorgang gesehen? Ist der Pull-Request nun bereit zum Mergen? Dank der iterativen Reviews beantwortet Bitbucket Server diese Fragen eindeutig und beseitigt damit viel Unsicherheit aus dem Prozess. Entwickler haben die Gewissheit, dass das Team alle Änderungen reviewt hat, ehe es ans Mergen geht.

Disaster Recovery (nur Data Center)

Disaster Recovery ermöglicht es, den Status einer Primärinstanz auf eine Cold-Standby-Instanz an einem anderen Standort zu replizieren. Falls die Primärinstanz gestört ist, kann Bitbucket Data Center auf die Standby-Instanz umschalten. Die Bitbucket-Instanz und die verwalteten Daten (Quellcode) sind also auch verfügbar, wenn das Primärsystem ausfällt.

Merge-Strategien

Mit Bitbucket Server 4.9 wird ein neues Feature ausgerollt, das sich auf Workflow- und Code-Review-Strategien fokussiert: Merge-Strategien. Diese Funktion ist eine Ergänzung zu den Merge-Checks, die es in Bitbucket Server schon eine Weile gibt. Sie gibt Nutzern und Teams die Kontrolle darüber, wie Pull-Requests gemergt werden, statt zu kontrollieren, ob ein Pull-Request gemergt werden kann.

Repositories aus anderen Hosting-Diensten importieren

Es gibt Fälle, in denen ein Team ein neues Projekt startet, das eine Migration von vielen Repos von einem Produkt zu einem anderen oder von Repos von einem Server auf einen anderen Server erfordert. Statt Skripte schreiben oder zeitaufwändig ein Repository nach dem anderen importieren zu müssen, ermöglicht die neue Import-Repository-Funktion nun Massenimporte, um Teams die Fähigkeit zu verleihen, mit echten oder mit Demo-Daten herumzuprobieren.

Reviews auf Commit-Ebene für Pull-Requests

Das neue Review auf Commit-Ebene bietet Diff-Ansichten per Commit und eine Kommentarfunktion im Pull-Request, um Reviewern zu helfen, individuelle Commits durchzugehen, die einem Pull-Request hinzugefügt wurden. Wenn ein Request-Autor seine Arbeit beispielsweise sorgfältig in logische Commits aufgebrochen hat, kann der Reviewer nun schrittweise durch die Änderungen eines jeden Commits gehen. Dabei sind die effektiven Diffs für die kompletten Pull-Requests jederzeit verfügbar, um das große Ganze im Blick zu behalten.

Standard-Reviewer festlegen

Dank des neuen FeaturesDefault Reviewer haben Teams für jedes Repository die Möglichkeit, standardmäßige Reviewer festzulegen, die dann automatisch in das Formular zur Erstellung eines Pull-Requests übernommen werden. Standard-Reviewer können sogar für Quell- und Ziel-Branch definiert werden. Dabei ist es jederzeit möglich, die Liste bei Bedarf um Personen zu ergänzen oder Leute von ihr zu nehmen.

Backups ohne Downtime

In Bitbucket Server und Bitbucket Data Center ist es nun möglich, Backups zu erstellen, ohne die Instanz zu sperren oder abzuschalten und ohne Nutzer in Bedrängnis zu bringen. Bitbucket bietet diverse Backup-Strategien – Details finden sich auf Atlassians Seite Data recovery and backups.

REST- und Java-Service-APIs für Pull-Request-Beschränkungen

Für die Version 4.7 hat Atlassian eine Lücke geschlossen und REST- und Java-Service-APIs für das Setzen von Pull-Request-Beschränkungen hinzugefügt. Neben der Möglichkeit, via remote Repos zu erstellen und Branch-Berechtigungen zu definieren, kann nun ein Minimum an Freigaben und erfolgreichen Builds festgelegt werden, die erforderlich sind, damit ein Pull-Request bereit zum Mergen ist. Für Entwickler von Drittanbietern, die ähnliche Merge-Checks zu schreiben, steht eine konsistente API zur Verfügung.

Tags über die Oberfläche hinzufügen und löschen

Es war schon immer möglich, das via Git zu tun, und auch die REST-API von Bitbucket Server kann dafür genutzt werden. Aber viele Teams haben sich einen einfacheren Weg gewünscht, um mit Tags zu arbeiten. Nun erlaubt die Bitbucket-Oberfläche es, Tags zu Commits hinzuzufügen und Tags zu löschen.

Verbesserung beim Teilen von Raw-Dateien

In früheren Versionen von Bitbucket Server war es schwierig, eine URL für eine Raw-Datei zu teilen. Um in einem Repository auf die Datei zuzugreifen, musste sie mit dem Suffix ?raw versehen werden, was zu Problemen mit manchen Web-Server-Konfigurationen geführt hat. Mit Bitbucket Server 4.7 gibt es nun ein neues URL-Schema zum Zweck relativer Verlinkungen.

Code-Suche

In Bitbucket 4.6 können User direkt aus dem Suchfeld heraus nach Code suchen. Dabei bestehen diese Möglichkeiten:

• Suche nach Code über alle Projekte und Repos hinweg
• Suche nach Code in einem spezifischen Projekt oder Repository
• Nutzung von Such-Operatoren, um präzisere Ergebnisse zu erhalten
• Suche nach Code basierend auf der Programmiersprache

Commit-Nachricht und Zeitstempel in der Quellansicht

Wenn ein Entwickler durch ein Repository browst, kann es hilfreich sein zu wissen, wann genau die letzte Änderung an einer Datei vorgenommen wurde. Dafür bietet Bitbucket Server nun im Datei-Browser für jede Datei Details über den letzten Commit. Wenn der Nutzer den Curser über dem Commit positioniert, wird ihm per Hover außerdem die komplette Commit-Nachricht angezeigt.

Blame in der Diff-Ansicht

Individuelle Timestamps

Um Verwirrung mit Zeitstempeln zu reduzieren, kann ein Entwickler jetzt seine individuelle Zeitzone einstellen. Remote-User und verteilte Teams haben damit akkurate lokale Zeitstempel in ihrer Oberfläche und in ihren Notofication-E-Mails.

Reviewer-Status

Atlassian hat eine Reviewer-Status-Funktion ausgeliefert, damit die Intention des Reviewers für alle klar ist. Sowohl der Autor als auch die Reviewer können sehen, welche Pull-Requests Aufmerksamkeit erfordern. Um Entwicklern zu helfen, im Hinblick auf Code-Revies schneller zusammenzuarbeiten, ist der Kopfbereich eines Pull-Requests optimiert worden. Nutzer haben die Möglichkeit, sich selbst schnell und einfach als Reviewer hinzuzufügen oder zu entfernen. Das ist vor allem in Teams mit vielen Reviewern hilfreich. Ein Reviewer kann sich ausklinken, während klar ist, wer weiterhin für Code-Reviews zur Verfügung steht.

Flexiblere Branch-Berechtigungen

In Bitbucket Server ist es nun möglich, Ausnahmen für alle verfügbaren Beschränkungen festzulegen – sei für das Erzwingen von Pushes, das Löschen von Branches oder das Vorgeben von Pull-Requests. Teams können also sicherstellen, das die Änderungen der Entwickler stets den Pull-Request-Workflow durchlaufen müssen, während der Release-Manager bereits reviewte Änderungen ganz normal mergen kann.

Smart Mirroring (nur für Bitbucket Data Center)

Smart Mirroring erhöht die Clone-Performance für verteilte Teams. Smart Mirroring kann die Lese-Performance (clone, fetch, pull) für verteilte Teams, die mit großen Repos arbeiten, drastisch erhöhen, indem diese auf einem nahegelegenen Server verfügbar gemacht werden.

Git Large File Storage (nur für Bitbucket Data Center)

Durch den neuen Git-LFS-Support können Software-Teams sämtliche produzierten Objekte an einem Ort abbilden und gleichzeitig produktiv sein. Große Dateien werden in einem parallelen Speicher festgehalten, während leichtgewichtige, schlanke Referenzen im Git-Repository gespeichert sind, das somit kleiner und schneller ist.

Smart Commits

Smart Commits erlauben es Repository-Committern, Vorgänge in Jira-Software durch die Nutzung von speziellen Kommandos in der Commit-Nachricht voranzutreiben.

Diagnostik für Anwendungs-Links

Bitbucket Server 4.2 bietet komplett überarbeitete Application Links inklusive nativer Status- und Diagnose-Informationen.

Verzahnung mit Hipchat

Zentrales Feature ist die Integration zwischen Stash und Hipchat. Nun ist es möglich, in Projekten oder Repositories Benachrichtigungen zu konfigurieren, sodass in Hipchat-Räumen Echtzeit-Meldungen über Pull-Requests und Commits ausgestrahlt werden.

Branch-Berechtigungen

Die Behandlung von Branch-Berechtigungen wurde verbessert: Es ist nun möglich, Rechte auf der Ebene einzelner Branches zu vergeben, je nach Branch-Modelltyp oder Branch-Permission-Muster in einem Repository.

Deep-Links auf Quelldatei-Zeilen

Die Verlinkung von Quelldateien ist nochmals verbessert worden. Per Shift+Klick kann ein Entwickler Zeilen auswählen, per CMD+Klick (oder STRG+Klick) dieser Auswahl separate Zeilen hinzufügen und dann die URL kopieren, um sie mit anderen zu teilen.

AWS-Unterstützung

Flexibilität ist ein wichtiger Erfolgsfaktor für professionelle Software-Entwicklungsteams, ob es nun Infrastruktur, Workflows oder Skalierbarkeit betrifft. Gerade im Hinblick auf die Infrastruktur ändern sich die Anforderungen schnell. Aus diesem Grund unterstützt Stash nun Deployments mit Amazon Web Services (AWS). Dabei können User ihre AWS-Server ihren Anforderungen entsprechend konfigurieren oder vorgebaute Amazon Machine Images (AMIs) nutzen.

Automatischer Setup

Bisher musste man selbst bei der automatischen Installation von Stash immer noch den Stash Setup Wizard im Browser besuchen, um den Admin-Account, die Basis-URL und die externe Datenbank-Verbindung einzustellen und um die Stash-Lizenz hinzuzufügen. Mit Stash 3.8 werden all diese Einstellungen in der Config-Properties-Datei spezifiziert: Die Installation und das Aufsetzen einer Stash-Instanz können ohne manuelle Eingriffe erfolgen. Stash liest die Datei aus und wendet die Einstellungen nach dem Launchen automatisch an.

Besseres Performance-Monitoring

Stash 3.8 bietet Werkzeuge für ein besseres Monitoring der Performance. Die Metriken enthalten die Anzahl der Projekte, Repositories und Git-Pushes und -Pulls sowie diverse Pool-Metriken. Diese werden als JMX-Counter angeboten. Das Stash-Monitoring ist also über einen JMX-Client wie JConsole möglich.

Bessere Trennung von lizenzierten und nicht autorisierten Nutzern

Die Behandlung von nicht lizenzierten und nicht autorisierten Usern, die aus externen Nutzerverzeichnissen gezogen werden, ist besser überschaubar. Beim Auswählen der Reviewer für ein Pull-Request werden nur die User angezeigt, die berechtigt sind, das Repository einzusehen. Nicht lizenzierte und nicht autorisierte Nutzer sind nicht aufgelistet. Das gilt auch für @-Mentions: Anwender ohne Stash-Lizenz werden bei der Nutzer-Auswahl nicht angezeigt.

Commit-Nachrichten beim Mergen anpassen

Mit Stash 3.7 haben Entwickler die Möglichkeit, den Merge-Commit-Nachrichten in Pull-Requests zusätzliche Informationen hinzuzufügen. So kann die Change-History eines Repositorys deutlich deskriptiver werden.

Kommentare aus E-Mails heraus liken und beantworten

Überarbeiteter Installations- und Upgrade-Prozess

Das Stash-Team hat den Installer überarbeitet, um die Unterschiede zwischen den Installations- und Upgrade-Pfaden besser herauszustellen. Insbesondere fragt Stash beim Upgrade nun den Ort des bestehenden Home-Verzeichnisses ab.

E-Mail-Batches

Benachrichtigungen werden für jeden Pull-Request aggregiert und dann an jeden Teilnehmer verschickt.  

Tasks für Pull-Requests

Stash bietet Tasks für Pull-Requests eingeführt, die sich per Klick anlegen lassen. Mit ihnen kann Feedback in Form verfolgbarer Aufgaben abgebildet werden; mit ihnen lassen sich die To-dos erfassen und tracken, die während eines Reviews zu tun sind.

Previews für Pull-Requests

In Stash 3.0 wurden Branch-Vergleiche eingeführt als Möglichkeit, die Unterschiede zwischen zwei Branches schnell zu identifizieren. So kann ein Entwickler all die Arbeit previewen, die in einen Pull-Request eingeht. Nun kann er von der Branch-Vergleichsseite direkt einen Pull-Request erstellen – mit einem Klick auf einen neuen Button. Dank dieses Nutzererlebnisses weiß der User genau, welche Code-Änderungen gemergt werden sollen, eher er diesen Pull-Request erzeugt.

Kommentar-Navigation

Ein aktiver Pull-Request kann mit der Zeit eine Menge Kommentare generieren, und mitunter kann es unhandlich sein, die Diskussion in der Diff-Ansicht durchzugehen statt in der Übersicht. In Stash 3.2 müssen User Kommentare nicht mehr über die Diffs hinweg suchen, sondern können die neuen Tastenkürzel “Shift+N” und “Shift+F” nutzen, um direkt von einem Kommentar-Thread zum nächsten bzw. zum vorherigen zu springen. Diese neuen Shortcuts ergänzen die Tastenkürzel “n” und “p” für die Navigation zwischen Diff-Hunks.

Leichterer Einstieg in Stash

Stash wird nun mit einer Willkommen-Seite für Teammitglieder ausgeliefert, die mit dem System noch nicht vertraut sind. Neue Anwender können zur Mitarbeit in Stash eingeladen werden, ohne dass jemand ihnen die Grundlagen erklären muss. Die Option “Welcome to Stash” im Hilfemenü zeigt an, welche Infos diese Seite enthält.

Suche in allen Diffs

Bei Commits und Pull-Requests, die oftmals diverse Dateien umfassen, ist es nicht einfach, in Diffs über all den Code hinweg nach spezifischen Änderungen zu suchen. Sucht ein Nutzer nach einem Method-Namen? Oder einer bestimmten Variablen? Nun bieten die Diffs in Stash eine Suchfunktion, um genau diesen Text-String schnell und einfach zu finden. Stash lokalisiert alle Stellen, an denen die gewünschte Phrase vorkommt – mitsamt den umgebenden Kontextzeilen.

Dateien und Bilder in Kommentaren

Stash unterstützt schon lange das Einfügen von Links und Bildern im Markdown. Mit Stash 3.1 gilt das nun also auch für Kommentare. Anhänge lassen sich einfach hochladen oder direkt per Drag & Drop einfügen, um Bilder und Dokumente zum Teil des kollaborativen Review-Prozesses zu machen.

Mehrsprachigkeit

Mitglieder internationaler Teams können nun in ihren eigenen Sprachen zusammenarbeiten. Ein Nutzer kann die Spracheinstellung in seinen Account-Optionen ändern und damit die voreingestellte Sprache außer Kraft setzen.

Branch-Vergleiche

Mit Stash 3 ist eine der meistgewünschten Optimierungen ausgeliefert worden. Vergleiche zwischen Branches in Form von Diffs für Dateien und Commits zwischen Branches sind schon längst ein integraler Bestandteil von Pull-Requests in Stash. Die Neuerung ist die, dass Entwickler nun ihre Arbeiten an Branches vergleichen können, während sie noch in der Entwicklung sind, also noch vor dem Erzeugen eines Pull-Requests.

Mehr Platz für Code, neue Sidebar

Je mehr Code auf den Bildschirm passt, desto einfacher kann man mit ihm arbeiten. Daher sind die Navigations-Links und die Repository-Aktionen in eine einklappbare Sidebar auf der linken Seite umgezogen. Doch auch im eingeklappten Zustand zeigt die Sidebar Icons an. Entwickler gelangen also vom Code rasch zur Repository-Verwaltung, zum Pull-Request-Dialog usw. Zum schnellen Ein- und Ausklappen der Leiste gibt es das praktische Tastenkürzel [.

Bessere Navigation in Side-by-side-Diffs dank Hunk-Maps

In Stash 2.11 hat Atlassian die Ansicht Side-by-side-Diffs eingeführt, die es einfach macht, Code-Änderungen in Commits und Pull-Requests zu überblicken. Allerdings ist die Navigation in dieser Ansicht nicht sehr bequem, wenn größere Dateien im Spiel sind. Hunk-Maps sollen diese Herausforderung lösen.

Diese Hunk-Maps bieten einen Überblick darüber, wie viele Änderungen an einer Datei vorgenommen wurden und wo sie sich befinden. Nutzer scrollen direkt zu einer Änderung, wenn sie einfach in der Hunk-Map klicken. Entwickler können Code reviewen statt nach Änderungen suchen zu müssen.

Kommentarzähler, um Diskussionen schnell zu finden

Mit In-line-Kommentaren sowie Kommentaren in Pull-Requests, zu Commits und auf Dateiebene bietet Stash viele Möglichkeiten, Code-Änderungen zu diskutieren. Neu ist der Kommentarzähler in den Tabs für Pull-Requests und Commits, der unmittelbar zeigt, was im Team derzeit besonders interessant ist und zu welchen Änderungen ein lebhafter Austausch läuft.

Lokale Bilder als Avatare

Stash erlaubt es dem Nutzer, ein beliebiges lokal gespeichertes Bild in sein Profil hochzuladen, statt den Dienst Gravatar zu nutzen. Gravatar wird nach wie vor unterstützt und ist auch als Voreinstellung definiert, aber User können Bilder in ihren individuellen Einstellungen ändern. Teams, die Gravatar nicht nutzen (können), haben die Möglichkeit, das Feature über das Administrations-Dashboard global zu deaktivieren.

DIY-Backup als Alternative zum bestehenden Backup-Client

Dieses Feature richtet sich speziell an Enterprise-Kunden. Teams, die mit vielen Projekten und Repositories arbeiten, können mit der DIY-Backup-Option Downtime reduzieren. Das DIY-Backup überlässt dem Team die Kontrolle über die Backup-Umgebung und die individuelle Wahl der Tools, um Dateisystem und Datenbank zu sichern.

SSH-Schlüssel: Read/Write- und Read-only-Keys

Bei SSH-Zugangsschlüsseln auf Projekt- und Repository-Level besteht die Wahl zwischen Read/Write- und Read-only-Keys. Das Build-System kann Zugangsschlüssel nutzen, um neue Tags zu pushen oder Merges in Stash anzufragen. Soll ein Zugangsschlüssel gelöscht werden, informiert Stash außerdem über alle betreffenden Projekte und Repositories, die diesen bestimmten Key nutzen.

Side-by-side-Diffs

Stash 2.11 führt für Diffs eine Side-by-side-Ansicht ein, wie sie aus Bitbucket bekannt ist. Die neue Ansicht zeigt Änderungen in einem Davor-und-danach-Stil in zwei Panels und bietet alle Features, die man von Diffs in Stash erwartet, inklusive In-line-Kommentaren und Hervorhebungen von Unterschieden auf Zeichenebene. Die Side-by-side-Diffs sind beim Scrollen synchronisiert, die korrespondierenden Change-Segmente sind immer zusammen zu sehen.

Commit-Kommentare

Manche Diskussionen über Code-Änderungen passen nicht richtig gut in den Lebenszyklus eines Pull-Requests, doch außerhalb dieses Kontextes gab es bisher keine Möglichkeit für einen solchen zentralisierten Austausch. Aus diesem Grund hat Stash 2.11 Commit-Kommentare eingeführt: Jeder Commit kann nun kommentiert werden.

Datei-Kommentare

Stash 2.11 bietet Usern nun die Möglichkeit, in einem Pull-Request oder in einem Commit jede Datei zu kommentieren, die geändert wurde. Es genügt ein Klick auf den entsprechenden Button in der Toolbar auf der rechten Seite.

Neue Jira-Integration

Mit dem neuen Development-Panel bietet das gerade ausgelieferte Jira 6.2 Entwicklungsinformationen an einer zentralen Stelle: Branches, Commits, Pull-Requests, Builds. Die neue Jira-Integration ermöglicht es, das gesamte Team auf dem aktuellen Stand in Sachen Projekt- und Vorgangsstatus zu halten.

Mehr Informationen auf der Branch-Übersichtsseite

Stash bietet mit Version 2.9 mehr Branch-Informationen an einer zentralen Stelle und macht diese Seite auch für Teamleiter und Release-Manager noch interessanter: Branch-Fortschritt auf einen Blick, Pull-Request-Informationen, Branch-Suche.

Zugangsschlüssel

Stash erlaubt Read-only-SSH-Schlüssel auf Projekt- und Repository-Ebene. Ein Zugangsschlüssel auf Projektebene kann auch für jede andere Build- und Entwicklungsaufgabe für Repositories in diesem Projekt wieder verwendet werden – ohne Zugriffsbeschränkungen. Der Zugang zu Repositories und Projekten lässt sich über verschlüsselte SSH-Keys kontrollieren.

Sichtbarkeit von Pull-Requests

Die Pull-Request-Inbox bietet seit jeher einfachen Zugriff auf die Pull Requests, die auf Reviews des Nutzers warten. Zusätzlich zeigt die Inbox nun auch die Pull Requests an, die dieser User erzeugt hat und die noch offen sind. Der nahtlose Wechsel zwischen diesen Sets kann direkt aus der Inbox heraus erfolgen.

Branching-Workflows

Stash ermöglicht die Integration der Best Practices in der Branch-basierten Entwicklung mit den individuellen Workflows des Entwicklungsteams. Ab Version 2.8 bietet Stash ein anpassbares Branching-Modell, durch das der Weg von der Branch-Erstellung bis zum Merging nahtlos ist. Durch die tiefere Verzahnung mit anderen Atlassian-Produkten ist das Branchen schnell und effizient.

Branches aus Jira oder Stash erstellen

Es ist nicht mehr erforderlich, Zeit zu investieren, um einen Jira-Vorgang auf die neuen Branch-Einstellungen in Stash zu mappen. Der Sprung von Jira zu Stash ist dank des Create-Branch-Links in der Development-Sektion des Jira-Tickets einen Klick entfernt. Stash zieht selbst Vorgangsdetails aus Jira und schlägt automatisch Einstellungen für den neuen Branch vor. Neue Branches in den Git-Repositories können auch direkt aus der Stash-Oberfläche heraus dank praktischer Shortcuts im Actions-Menü angelegt werden.

Branches organisieren und standardisieren

Anpassbare Branching-Modelle bringen Konsistenz in die Entwicklungs-Workflows des Teams. Es lassen sich Naming- und Destination-Konventionen für gebräuchliche Entwicklungsobjekte wie Bugfixes, neue Features oder Hot Fixes festlegen. Die Aktivierung von Cascading Merges zwischen Release-Branches reduziert die anfallende manuelle Wartung.

Zentrale Visualisierung aller Branches

Stash bietet eine Liste mit allen existierenden Branches auf einen Blick. Nutzer können schnell auf Branch-Details zugreifen und somit ausstehende Arbeiten, die gemergt werden müssen, direkt erkennen. Aufgaben wie das Löschen von Branches oder das Erstellen von Pull Requests lassen sich direkt von dieser Seite aus durchführen.

Transitions von Jira-Vorgängen aus Stash anstoßen

Stash 2.7 bietet dem Entwickler die Möglichkeit, verknüpfte Jira-Vorgänge direkt aus Stash heraus in eine andere Transition zu überführen. Beispielsweise kann er einen Pull-Request öffnen und das betreffende Jira-Ticket direkt ins In-Review-Stadium übergeben. Stash unterstützt im Hinblick auf Transitions auch individuelle Jira-Workflows und schränkt lästige Anwendungswechsel weiter ein.

Jira-Vorgänge aus Kommentaren und Pull-Request heraus verknüpfen

Dank der Stash-Unterstützung für Markdown in Kommentaren und Beschreibungen lassen sich relevante Jira-Vorgänge verlinken, indem man einfach den Vorgangsschlüssel erwähnt. Stash bietet den Kontext des Vorgangs automatisch in Stash an und erlaubt auch hier Ticket-Transitions (wie bei allen anderen Issue-Links in Stash). Issue-Links bieten vollständige Nachvollziehbarkeit von den in Jira abgebildeten Aufgaben und Vorgängen bis hin zum Quellcode, der diese Tickets betrifft.

Mehrere Jira-Server mit Stash verbinden

Viele Entwicklungsteams betreiben mehrere Jira-Instanzen im Unternehmen. Stash kann nun mit allen bestehenden Installationen verbunden werden. Speziell Enterprise-Teams profitieren von diesen Möglichkeiten.

Automatische Fork-Synchronisation

Stash 2.6 hat einen einfachen und zeitsparenden Weg zur Synchronisation von Forks eingeführt: Bei aktivierter Fork-Synchronisation in einem geforkten Repository wird dieses automatisch mit dem Original-Repo synchronisiert. Ist das geschehen, verweisen alle Branches auf dieselben Commits wie das Upstream-Repository. Treten Konflikte auf, bietet Stash direkt einen Problemlösungs-Guide an. Die Entwicklung an einem Fork ist nun identisch mit der Entwicklung direkt an dessen Original-Repository. Immer, wenn jemand einen Pull-Request pusht oder mergt, werden die Änderungen innerhalb von Sekunden in den Fork dupliziert.

Audit-Logs

Repository-Schnellsuche

Application-Navigator

User können direkt vom Stash-Header aus zwischen Stash und anderen Tools navigieren. Zusätzlich lässt sich der Application-Navigator so konfigurieren, dass beliebige interne und externe Anwendungen, die häufig genutzt werden, direkt ansteuerbar sind.

Public Access

Public Access berechtigt anonyme (nicht authentifizierte) Nutzer dazu, durch spezifische Repositories oder ganze Stash-Projekte zu browsen. Anonyme User können den Quellcode in einen Repository einsehen und diese klonen. Eingeloggte Nutzer erhalten Lesezugriff auf Repositories, für die Public Access besteht, sodass sie Forks vornehmen und Pull Requests erstellen können. Der Quellcode ist in Public-Access-Repos und -Projekten vor Änderungen jedweder Art geschützt. Public Access lässt sich für Repositories und Projekte separat konfigurieren.

Ziel-Branches für aktive Pull-Requests ändern

Der Ziel-Branch für einen aktiven Pull-Request kann geändert werden. Hat man beim Erstellen des Pull-Requests die falsche Destination gesetzt, muss man diesen nicht mehr löschen und dann einen neuen erstellen.

Mehr Kontext in Diffs

Stash bietet eine neue Möglichkeit, in den Diffs für Pull-Requests und Commits mehr Code-Zeilen einzusehen. Ein Klick auf die grauen Balken zeigt mehr Kontext bis hin zur kompletten Datei, wenn gewünscht. Graue Balken können in der Diff auch ganz oben oder unten erscheinen, falls mehr Kontext verfügbar ist.

Kollaborative Entwicklung mit Forks

Forks in Stash bieten Entwicklern einen Workflow, um Code zu einem Repository beizutragen, für die sie keinen Schreibzugriff haben, und bringen eine neue Ebene der Kontrolle in den Entwicklungsprozess. Mit dem Klick auf den Fork-Button eines Repositorys wird eine Kopie erstellt, die von Stash getrackt und unabhängig vom Original-Repository modifiziert wird, um dieses vor ungewollten Änderungen oder Fehlern zu schützen. Ein Repository lässt sich in jedes andere Stash-Projekt forken, für das Admin-Zugriff besteht. Zudem sind persönliche Forks möglich, für die anderen Entwicklern dann Zugriffsrechte erteilt werden können. Pull Requests erlauben das einfache Mergen von Änderungen zwischen Forks.

Änderungen via Pull-Requests beisteuern

Änderungen an der Fork-Repository tangieren die Haupt-Codelinie nicht. Sobald ein Fork soweit ist, kann er per dann Pull-Request in das Original-Repository gemergt werden. Stash und Pull-Requests erleichtern den Merging-Prozess solcher Änderungen. Das gibt anderen Entwicklern die Möglichkeit, Änderungen zu reviewen und zu diskutieren, ehe sie Teil der Haupt-Codebasis werden. Von dort aus lassen sich die Änderungen auf Basis der Pull-Request-Einstellungen und Branch-Berechtigungen in das Original-Repository mergen.

Persönliche Repositories

Stash 2.4 bietet die Option, ein persönliches Repository zu erstellen, das nicht mit anderen Projekten zusammenhängt. Dadurch haben Entwickler die Freiheit, Innovationen voranzutreiben und ihre privaten Arbeitsschnipsel abzulegen, Bugfixes zu einem Projekt beizusteuern, an dem sie sonst nicht beteiligt sind, oder Features zu einer verbreiteten Komponente hinzuzufügen, die von einer kleinen Gruppe im Unternehmen gewartet wird. Diese persönlichen Repositories können beliebig offen (oder geschützt) sein. Mithilfe der Repository-Berechtigungen können Entwickler dann mit anderen Nutzern und Gruppen zusammenarbeiten.

Überarbeitete Nutzerprofile

Die Einführung persönlicher Repositories und Forks hat es erforderlich gemacht, eine einfach erreichbare Stelle zu schaffen, an der diese Informationen zusammengefasst sind. Das Stash-Team hat die Nutzerprofile aufpoliert.

Berechtigungen auf Repository-Ebene

In frühen Stash-Versionen hat es zwei Kategorien von Berechtigungen gegeben: Globale Berechtigungen und Projekt-Berechtigungen, um den Lese- und Schreibzugriff zu kontrollieren. Mit Stash 2.0 wurde das Rechtekonzept dann um die Branch-Permissions erweitert. Stash 2.4 bietet nun eine noch granularere Zugangskontrolle: Berechtigungen auf Repository-Ebene.

Branch-Cleanup

Wenn Code final in den Ziel-Branch integriert ist, ist es oft sinnvoll und gewünscht, einen Feature- oder Hotfix-Branch zu löschen. Stash bietet die Möglichkeit, den Branch zu löschen, wenn der Pull-Request gemergt wird, sofern es sich um keinen Default-Repository-Branch handelt, der Nutzer die Berechtigung zum Löschen hat und der Branch nicht Gegenstand eines offenen Pull-Requests ist.

Git-Submodule

Submodule erlauben es, externe Git-Repositories in die Verzeichnisstruktur der eigenen Repository einzubinden. So lassen sich externe Codebasen wie geteilte Bibliotheken, die unabhängig vom Hauptprojekt aktualisiert werden, integrieren.

Single-sign-on mit Crowd

Stash unterstützt SSO mit Atlassians Crowd.

Git-Repository-Hooks

Git-Hooks erlauben es, Workflows des Entwicklungsteams an alle Anforderungen anzupassen. Administratoren können Hooks für jedes Repository direkt in Stash aktivieren und konfigurieren, ohne sie im Dateisystem installieren zu müssen.

API für Hook-Integration

Entwickler können einfach ihre eigenen Hooks schreiben. Stash managt die Persistenz, das Packaging und die Per-Repository-Konfiguration, sodass Stash an spezifische Projekterfordernisse angepasst werden kann.

Merge-Checks für Pull-Requests

Um Workflows anzupassen, lassen sich Checks setzen, die kontrollieren, wann ein Pull-Request gemergt werden kann.

Pull-Request-Integration mit Jira

Pull-Requests integrieren direkt mit Jira, Vorgangsdetails sind direkt einsehbar. Ohne Stash zu verlassen, sind Vorgangsstatus, Bearbeiter und Beschreibung ersichtlich.

Build-Status-API

Die Build-Status-API erlaubt es Build-Servern wie Bamboo und Jenkins, Build-Details in die Übersicht eines Pull-Requests zu liefern. Der Entwickler erhält einen schnellen Überblick, ob der Pull-Request bereit zum Mergen ist oder nicht.

Avatare für Projekte

Durch Projekt-Avatare sind Projekte auf dem Dashboard einfach zu finden und zu identifizieren. Stash bietet etliche Vorlagen-Icons und unterstützt individuelle Avatare.

Inbox für Pull-Requests

Die global verfügbare Inbox für Pull-Requests stellt alle Pull-Requests dar, die auf die Bearbeitung durch den Nutzer warten - über alle Projekte und Repositories hinweg.

Branch-Berechtigungen

Git erlaubt es Entwicklern grundsätzlich, Branches frei zu erstellen, zu mergen und zu löschen. Die große Neuerung in Stash 2 ist die Möglichkeit, Branch-Berechtigungen zu vergeben und Kontrollmechanismen zu etablieren. Schreibrechte für einzelne User oder Gruppen stellen sicher, dass stabile Branches stabil bleiben, und Development-Branches fördern die Zusammenarbeit.

@-Mentions

Mit @-Mentions lassen sich Teammitglieder besonders einfach in Diskussionen involvieren. Nutzer müssen nur das @-Zeichen gefolgt vom Namen des gewünschten Users in einen Kommentar tippen, der so erwähnte Teilnehmer erhält automatisch eine Nachricht, dass er in einer Pull-Request-Konversation erwähnt wurde.

Markdown-Unterstützung für Kommentare

Kontext herzustellen und wichtige Punkte zu betonen, ist wichtig, wenn eine schriftliche Diskussion um den Code herum geführt wird. Stash unterstützt das auch formal und bietet Markdown-Funktionen für Kommentare an.

Pull-Requests

Seit Version 1.3 unterstützt Stash Pull-Requests.

Diskussionen

Die Übersicht fängt die gesamte Aktivität rund um einen Pull-Request ein. Diffs, Replies oder neue Commits zum Branch können kommentiert werden.

Diffs für geänderte Dateien

Die Diffs für einen Pull-Request heben die Änderungen hervor, die aus dem Merge resultieren würden. Der Diff-Baum zeigt alle modifizierten Dateien, per Klick auf eine Datei sieht der Entwickler, was hinzugefügt, gelöscht oder verändert wurde.

Commits

Stash aktualisiert das Commits-Tab in einem Pull-Request automatisch, sodass immer ersichtlich ist, welche Commits gemergt werden.

Benachrichtigungen

Wird jemand als Reviewer hinzugefügt, kommentiert einen Pull-Request oder mergt Änderungen, erhält er zu den für ihn relevanten Pull-Requests künftig automatische Benachrichtigungen bei wichtigen Aktivitäten.

Datenbank-Unterstützung

Stash unterstützt alle wesentlichen Datenbanken: MySQL, Oracle, PostgreSQL und Microsoft SQL Server.

Datenbank-Migration

Der Wechsel zwischen der in Stash integrierten Datenbank und der Infrastruktur des eigenen Unternehmens ist einfach, ändert sich die Infrastruktur, ist die Migration nahtlos.

Dateisuche

Stash führt die Dateisuche ein, mit der sich alle Dateien in einem Repository finden lassen, ohne im Quellcode zu suchen. Suchabfragen können nach Pfad, CamelCase und Dateierweiterung gefiltert werden.

Merge-Filter

SSH-Support

Zusätzlich zu HTTPS unterstützt Stash SSH. Entwickler können ihre eigenen SSH-Keys managen und so viele hinzufügen, wie sie wollen. Stash-Admins können für jeden Nutzer SSH-Keys genehmigen oder widerrufen.

Schnelleres Browsen

Der Stash-Header bietet Entwicklern einen Repositories-Knopf, über den sich die zuletzt angesehenen Repositories direkt wieder ansteuern lassen. Einige neue Tastenkürzel erleichtern die Arbeit ohne Maus.

Einfache Berechtigungen

Stash führt ein neues Interface zur Verwaltung von Berechtigungen auf gobaler und Projektebene ein.

Browsen im Quellcode und in der History

Die initiale Stash-Version ermöglicht das Tracking von Commits zu Repositories, an denen man beteiligt ist: In den Changesets ist exakt sichtbar, was im Quellcode geändert wurde. Nutzer können durch Repositories navigieren und kommentierte Änderungen jederzeit einsehen.

Unterstützung von Enterprise-Anforderungen

Stash zwingt Administratoren nicht dazu, Pre-packaged-Anwendungen zu nutzen und Kontrolle abzugeben. Sowohl unter Windows als auch unter Linux und MacOS X kann Stash reibungslos betrieben werden, dank LDAP- und Crowd-Unterstützung und Jira-Integration ist das Tool für Unternehmensanforderungen gerüstet.

Jira-Integration

Stash trackt alle Jira-Vorgänge, die mit Commits verknüpft sind. User können schnell zu mit den Commits verlinkten Jira-Vorgängen navigieren, zudem werden alle Code-Änderungen, die sich auf einen Vorgang beziehen, in Jira integriert und dort dargestellt.