Viele Confluence-Nutzer erreichen einen Punkt, an dem sie mehr benötigen, als ein einzelner Server ihnen bieten kann. Wenn sich Anwendungen innerhalb eines Unternehmens immer weiter ausbreiten, werden sie zum missionskritischen Aspekt für jedes beteiligte Team. Wir nennen diesen Zeitpunkt den „Wendepunkt“; Unternehmen entscheiden sich zu diesem Zeitpunkt für einen Wechsel zu einer Active-Active-Clusterumgebung, die höhere Verfügbarkeit und skalierbare Performance bietet, mit anderen Worten: Data Center.

Das Problem ist, dass die Entscheidung für ein Upgrade häufig zu spät stattfindet, nämlich dann, wenn bereits ein Problem aufgetreten ist. Deshalb haben wir eine Liste der 5 häufigsten Anzeichen zusammengestellt, mit deren Hilfe Sie herausfinden können, ob Ihr Unternehmen bereit für den Wechsel von Confluence Server zu Data Center ist.

Data Center ist eine Deployment-Option für Atlassian-Produkte (Confluence, JIRA Software, JIRA Service Desk, Bitbucket), die speziell für Kunden entwickelt wurde, die in missionskritischen Umgebungen arbeiten. Data Center stellt Ihnen die Produktfunktionalität zur Verfügung, mit der Sie bereits vertraut sind und verleiht Ihnen gleichzeitig Vorteile wie beispielsweise Deployment-Flexibilität, Skalierbarkeit, hohe Verfügbarkeit, verbesserte Authentifizierung und Kontrolle.

1) Schneller und unerwarteter Anstieg der Confluence-Nutzer

In der Lage zu sein, die verschiedensten Dinge erstellen zu können, macht Confluence für Teams so attraktiv. Das sorgt wiederum dafür, dass innerhalb eines Unternehmens Confluence in kürzester Zeit von vielen Teams übernommen wird. Das kann zu einem unerwarteten Anstieg von Confluence-Nutzern führen. Diese Art Wachstum ist in der Regel „organisch“, bzw. ein „Grassroots“-Wachstum, bei dem einzelne Teams und Nutzer Zugriff auf Confluence erfragen. Das ist zwar großartig für die Einführung von Confluence, kann aber auch zu suboptimaler Performance und möglicherweise sogar zu Ausfällen führen. Mit Confluence Data Center können Sie mehr Nodes zum Data-Center-Cluster hinzufügen, um mit sofortiger Wirkung und ohne Leistungseinbußen die Kapazität für gleichzeitig auftretende Nutzer zu erhöhen, was wiederum die Planung und Vorbereitung auf zukünftiges Wachstum erleichtert.

2) Die Arbeit liegt auf Eis, wenn Confluence nicht erreichbar ist

Confluence ist für viele Unternehmen die „Single Source of Truth“ und ist für viele Teams essentieller Bestandteil ihrer Arbeit. Teams verlassen sich beim Erstellen von Inhalten, der Zusammenarbeit bei Projekten und dem Zugriff auf Informationen auf Confluence, unerwartete Downtimes mindern daher die Produktivität oder sorgen sogar häufig für einen vollständigen Arbeitsstopp. Mit Confluence Data Center können Sie Cluster aus mehreren aktiven Servern erstellen, um für unterbrechungsfreien Confluence-Zugriff zu sorgen, sollte es jemals zu einem unerwarteten Hardwareausfall kommen. So können Ihre Teams ohne Probleme rund um die Uhr zusammenarbeiten.

3) Ihre Management-Teams verwenden Confluence

Wenn wir sagen, dass Confluence missionskritisch für Unternehmen ist, müssen Sie verstehen, welche Arbeit als missionskritisch gilt. Für viele Unternehmen könnte dies die Notwendigkeit von 24/7-Verfügbarkeit sein (im Gegensatz zu normalen Geschäftszeiten), oder es könnte Arbeit sein, deren Auswirkungen sich nicht auf das Team beschränken, sondern die sich auf das gesamte Unternehmen auswirkt. Es lässt sich also ohne Zweifel feststellen, dass die Arbeit, die von Management-Teams in Confluence erstellt, organisiert oder diskutiert wird, automatisch missionskritischen Status erreicht. Stellen Sie sich vor, Ihre Management-Teams würden Dokumente zur Strategieplanung oder eine Rebranding-Kampagne auf Confluence hosten. In solchen Fällen ist Downtime völlig inakzeptabel und kann negative Auswirkungen auf viele verschiedene Geschäftsebenen haben. Wenn Management-Teams Confluence verwenden, lautet die Frage nicht „Sollen wir Data Center verwenden?“, sondern „Wie schnell können wir zu Data Center wechseln?“.

4) Es gibt keinen Confluence-Rettungsplan im Falle eines Desasters

Wenn die gesamte Arbeit Ihres Teams zentral in Confluence gespeichert ist, können Sie es sich nicht leisten, dass etwas schief geht. Clustering bietet Ihnen zwar eine Ausfallsicherung im Falle eines einzelnen Node-Ausfalls, aber was passiert bei einem standortweiten Ausfall? Mit Confluence Data Center bietet Atlassian eine vollständige Desaster-Rettung an – ein essentieller Aspekt jedes Deployments auf unternehmerischem Level. Sie haben die Möglichkeit, im Zuge einer Ausfallsicherung, zu einer Cold-Standby-Instanz zu wechseln, die über eine replizierte Datenbank und Datenspeicher verfügt, sollte der Strom oder die Netzwerkverbindung an Ihrem Hauptstandort ausfallen. Confluence Data Center stellt sicher, dass die Dinge reibungslos weiterlaufen und verhindert negative Auswirkungen auf Ihr Team. Egal, ob Sie erst seit kurzer Zeit Strategien zur Desaster-Rettung entwickeln und implementieren, oder ihre aktuelle Strategie aufwerten möchten, Data Center ist die einzige Deployment-Methode, die eine von Atlassian unterstützte Lösung enthält, um Sie so schnell wie möglich wieder auf die Beine zu bekommen.

5) Confluence ist auf den Kunden ausgerichtet

Wenn Confluence als kundenorientierte Anwendung eingesetzt wird, ist es dringend notwendig, dass die Software reibungslos läuft. Die meisten Teams verstehen, welchen Mehrwert das richtige Tool für ihre Arbeit bietet, egal wie hoch die Kosten sind, wenn Confluence also für kundenorientierte Dokumentationen verwendet werden soll, gibt es keinen Platz für Fehler. Nehmen wir beispielsweise an, dass ein Unternehmen Confluence verwendet, um Hilfe- oder How-To-Artikel für seine Kunden bereitzustellen. Sollte Confluence aus irgendeinem Grund offline oder nicht erreichbar sein, haben Sie nicht nur frustrierte Kunden, sondern auch Kunden, die keinen Zugriff auf Dokumentationen haben, mit denen sich ihre Probleme lösen ließen.

Hat Ihr Unternehmen den Wendepunkt bereits erreicht?

Von Server zu Data Center zu wechseln, kann eine schwierige Entscheidung sein, aber sollte einer dieser Punkte auf Ihr Unternehmen zutreffen, ist es vielleicht der richtige Zeitpunkt, um Data Center ins Gespräch zu bringen. Kontaktieren Sie uns, das Team von Braintime hilft Ihnen gerne!

Das Scaled Agile Framework (SAFe) wurde für die Herausforderungen von mittelgroßen bis zu den größten Organisationen der Welt geschaffen. Solche Programme beinhalten mehrere agile Teams mit 50 bis 100 Menschen, die teilweise sogar hunderte bis tausende Beteiligte haben.

Reichen Scrum und Kanban aus?

Was aber ist mit kleineren Organisationen, mit einer handvoll Entwicklerteams? Wird SAFe dort benötigt? Reichen Scrum und Kanban gerade so aus? Wie immer laut die Antwort: Es kommt darauf an. In diesem Artikel möchten wir beleuchten, wie sich Praktiken von SAFe auch in kleineren Teams einsetzen lassen, so dass Ihre Teams mit Ihrer Organisation wachsen können.

Falls ein reines Softwareteam in kürzeren Releasezyklen arbeitet, liegt es auf der Hand Kanban oder Scrum zu wählen. Während die gesamte Bandbreite an SAFe-Praktiken sicher nicht sinnvoll ist, können auch kleine Entwicklerteams von den Vorteilen des Scaled Agile Frameworks profitieren. Jedoch nur wenn  mindestens eine oder mehr der folgenden Voraussetzungen erfüllt sind:

Es handelt sich um ein strategisches Softwareprodukt mit langer Lebensdauer

Umso länger die Lebensdauer eines Softwareproduktes ist, umso wichtiger ist es, die Entwicklung der Software eng mit der Strategie des Unternehmens zu verzahnen. Scrum bietet nur wenig Unterstützung für die Verknüpfung von Geschäfts- und Entwicklungszielen über einzelne Sprints hinaus.

Abhängigkeiten zu mehreren Nicht-Softwareteams

Es ist gängige Praxis, dass Unternehmen ein relativ kleines Software-Team besitzen, welches Lösungen für die anderen Teams zwecks Integration entwickelt. Beispielsweise finden sich Softwareteams in der Situation wieder, dass sie Teil eines Dienstleistungs- oder Hardwareunternehmens mit einem stattlichen Produktportfolio sind, aber lediglich einer geringen Anzahl an Software-Assets. Software-Unternehmen, deren Produkt stark auf die Bedürfnisse der einzelnen Kunden angepasst wird, stehen vor einem ähnlichen Problem: Alle beteiligten Teams müssen sich untereinander austauschen und auf Prioritäten und Zielsetzungen festlegen.

Bedarf für langfristige Investitionen wie DevOps besteht

Fokussiert man sich darauf, Sprint für Sprint das nächste Set an umgesetzten Userstories auszuliefern, ist das Ergebnis ein tolles Produkt. Aber was ist mit dem Skills des Teams? Die Investition in DevOps ist sicher eine lohnende Investition für höhere Qualität und eine schnellere Marktreife. Aber zu einem richtigen DevOps-Team wird man nicht über Nacht. Es werden sorgfältige Planung und Umsetzung gebraucht, wie bei jedem Projekt. Die in der Entwicklung eingesetzten Technologien zu ändern oder die Software-Architektur zu modernisieren sind ähnliche langfristige Investitionen, die richtig große Projekte sind.

Voraussichtliche Skalierung von klein auf mittelgroß

Falls ein Startup (ein neues Unternehmen oder interne Organisationseinheit) großes Potenzial für Wachstum hat, ist es durchaus sinnvoll auf schnelle Skalierung vorbereitet zu sein und agile Methoden dort einzusetzen, wo sie gebraucht werden. Falls aber die wichtigsten agilen Fertigkeiten nicht von Grund auf aufgebaut werden, wird skalieren schwierig, schmerzhaft und herausfordernd.

Die sechs SAFe-Praktiken für kleine Teams

Es besteht natürlich die Möglichkeit, die folgenden vier Themen mit Scrum oder Kanban zu lösen, aber die Erfahrung hat gezeigt, dass die Anwendung der folgenden sechs SAFe-Praktiken dazu führen, viel effektiver mit diesen Problemen umzugehen.

1. Strategische Themes

Kleine und große Unternehmen benötigen eine Strategie um erfolgreich zu sein. Es ist ein kritischer Erfolgsfaktor zu verstehen, wie die Produkte eines Unternehmens Mehrwert generieren. Wie diese Produkte beim Kunden Prozesse beeinflussen und welche konkreten Vorteile sie erbringen. Produktqualität und User-Experience sind beide wichtig für langanhaltenden Erfolg. Ein Softwareteam benötigt zusätzlich zur Produktstrategie einen Plan, wie die eigenen Entwicklungsfähigkeiten geschärft werden können, um sich kontinuierlich zu verbessern, produktiver zu werden und konkurrenzfähig zu bleiben.

Das Scaled Agile Framework bietet zwar nicht direkt die Werkzeuge um diese Pläne und Strategien zu entwerfen, aber beinhaltet sogenannte Strategic Themes. Das sind Geschäftsziele, die das Portfolio eines Teams mit der Unternehmensstrategie verknüpfen.

Strategische Themes wurden bereits erfolgreich während der Sprint- (bzw. Iterations-) Planung eingesetzt, um sicherzustellen, dass Teams an den strategisch richtigen Aufgaben arbeiten. Manche Werkzeuge wie zum Beispiel Visual Studio Team Services (VSTS) ermöglichen es, die Aufgaben eines Teams mit einem Theme zu taggen, was dabei hilft, den Backlog mit der Strategie abzugleichen. Falls eine Strategie existiert, ist der zusätzliche Aufwand, um Strategic Themes zu bestimmen  vernachlässigbar gering.

2. Programm-Epics

Typischerweise behandeln Scrum-Teams Epics als sehr große User Stories, die sich nicht innerhalb von einem Sprint abhandeln lassen. SAFe definiert Epics als “Vorhaben, die so schwerwiegend sind, dass sie eine Analyse über einen leichtgewichtigen Business-Case und eine Freigabe für Budget benötigen, um umgesetzt werden zu können”. Die Anforderung, einen Business-Case vorzubereiten ist nicht das Besondere an dieser Stelle, sondern viel mehr die Herausforderung sicherzustellen, dass ein Epic zum einen realisierbar bleibt und zum anderen signifikanten Mehrwert generiert.

SAFe besitzt eine umfangreiche Hierarchie an Epics, um richtig skalieren zu können: Portfolio-Epics, Value Stream-Epics und Programm-Epics. Portfolio- und Value Stream-Epics sind für kleinere Entwicklungsvorhaben nicht relevant. Programm-Epics sind dafür umso wichtiger. Wenn ein Team an einem zu einem strategischen Theme verknüpften Programm-Epic arbeitet, dann schöpft das Team Mehrwert für etwas, das genau an der Strategie und den Wertvorstellungen des Unternehmens ausgerichtet ist.

Epics sind für kleine Teams nützlich, denn diese beschreiben Schlüsselvorhaben, die gerade im Gange sind und entweder von Beteiligten oder dem Team selbst definiert wurden. Software-Teams sollten zusätzlich zu Business-Epics auch Enabler-Epics im Backlog haben, um die Architektur oder DevOps-Fähigkeiten zu verbessern.

Da signifikante Vorhaben auch signifikante Investments von Menschen benötigen, wird die Definition eines leichtgewichtigen Business Cases für jedes Epic empfohlen, bevor über Freigabe oder Absage entschieden wird. Ein solcher Prozess ist gerade dann nützlich, wenn das Team mehrere Stakeholder bedienen muss und jedes Vorhaben im Sinne der jeweiligen Priorität und Kapazität betrachtet werden muss, um entsprechende Kompromisse zu verstehen und schließen zu können.

3. Program Kanban

Das Scaled Agile Framework setzt auf Kanban um Initiatives (Vorhaben) auf Portfolio-, Value Stream- und Program-Ebene zu verwalten. Die Programm-Ebene ist für ein kleines Team ausreichend. Besonders nützlich wird diese Ebene, falls das Team mehrere Stakeholder zu bedienen hat, die jeweils eigene Epics zur Umsetzung anbieten.

Das Program Kanban des Scaled Agile Frameworks stellt einen einfachen und transparenten Prozess zur Erfassung, Analyse, Freigabe und Nachverfolgung von Epics zur Verfügung.

Abgeschlossene Epics sind durch folgende Zustände gewandert: Funnel, Review, Analysis, Backlog, Implementing und schlussendlich Done. Ein komplexer Ablauf. Für ein kleines Team ist der Prozess der Analyse von Epics sehr einfach. Trotzdem sollten diese logischen Schritte berücksichtigt werden. So weiß der Product Owner, dass das Team für den nächsten Releasezyklus den bestmöglichen Geschäftswert generieren kann. Die Schlüsselvorhaben als Epics im Program Kanban zu verwalten benötigt wenig Aufwand aber gibt volle Transparenz für die Prioritäten des Teams auf Programm und Portfolio-Ebene.

4. Features

Features sind nicht wirklich Teil der Definition von Scrum, sondern lediglich Aufgaben im Produkt-Backlog. Viele Scrum-Teams übernehmen User Stories aus eXtreme Programming (XP) und titulieren große User Stories als Epics und bündeln verwandte Stories als Themes.

Das Scaled Agile Framework definiert ein Feature als einen Dienst des Systems, der ein bestimmtes oder mehrere Bedürfnisse des Nutzers bedient. Features übertreffen Epics und sind über ihre Vorteile und Akzeptanzkriterien definiert. Features sind genau das, wonach sie klingen: Diejenigen Charakteristiken, die die Kernfunktionalität des vorgeschlagenen Produktes ausmachen. Den Fortschritt und die Planung des Teams an Kunden, abhängige Projekte oder das Management  nur über User Stories zu kommunizieren kann mitunter schwierig sein. Features, wie definiert von SAFe, schaffen hier Abhilfe. Der Umfang von Features ist passend und verständlich – im Gegensatz zu User Stories, die oft zu klein und fragmentiert sind.

Was Features so nützlich macht: Sie sind passend für PIs gehalten. So werden Features zu konkreten Deliverables, die eine klare und deutliche Kommunikation mit Stakeholdern ermöglicht.

5. Planung von PIs

Klassische Scrum-Teams arbeiten in zyklischen Sprints. Meist dauern diese zwei Wochen an und innerhalb dieses Rahmens findet die Planung und Umsetzung von Arbeit statt. Öfter als gewünscht können Scrum Teams aber lediglich wirkliche Transparenz zur geplanten Arbeit nur für den nächsten Sprint bieten. Zusätzlich vielleicht den Backlog, der eine grobe Übersicht dazu gibt, in welcher Reihenfolge User Stories vermutlich implementiert werden. Es wird auf allerlei Variationen von PowerPoint- bzw. Excel-basierten Roadmaps gesetzt, um den Bedarf an Projektplanung, die über den nächsten Sprint hinausgeht zu befriedigen.

Backlog-Werkzeuge können dabei helfen, Stories für künftige Sprints zu planen und basierend auf der Velocity des Teams und der Anordnung im Backlog Vorhersagen zu treffen.

Ein Program Increment (PI) im Scaled Agile Framework bedeutet: ein auf Kadenzen basierender Intervall, der zum Entwickeln und Validieren eines inkrementellen Schrittes in der Erschaffung eines Systems genutzt wird, um Mehrwert fürs Geschäft zu generieren und Feedback zu erhalten. Die Dauer eines PIs beträgt in der Regel acht bis zwölf Wochen bzw. vier bis sechs Sprints.

Ähnlich der Planung von Sprints in Scrum bietet SAFe mit dem PI Planning eine Möglichkeit diese besonders großen Iterationen zu planen. SAFe-PI Planning lässt sich eins zu eins auch für kleine Teams anwenden. Man plant für acht bis zwölf Wochen. Dieser Zyklus ist kurz genug, um sinnvoll planen zu können und lang genug, um dem Team zu ermöglichen etwas von Mehrwert zu erschaffen: potenziell veröffentlichbare Features. Die PI-Planung ist sinnvoll verbrachte Zeit für alle Teilnehmer. Das Team bekommt ein Update fürs große Ganze von der Business-Seite inklusive Vision und Prioritäten und entwickelt einen agilen Plan. Die Stakeholder können bei der Planung direkt mitwirken. Stakeholder bekommen auch einen Überblick über die für ein PI geplante Arbeit der einzelnen Teams. Für ein kleines Team kann die PI-Planung zu einem langen Arbeitstag komprimiert werden, damit die investierte Zeit mit den Benefits in Einklang bleibt.

6. Innovation und Iterationsplanung

Thomas Edison hat seinen Ansatz für Innovation mit “einem Prozent Inspiration und 99 Prozent Durchhalten” beschrieben. Anders gesagt: Innovation benötigt nicht nur kreative Köpfe, sondern auch viel harte Arbeit. In der nie aufhörenden, kontinuierlichen Entwicklung von Produkten steckt immer das Risiko, dass ein Team ohne Pause Sprint für Sprint arbeitet und am Ende erschöpft und ausgebrannt ist. Sprints können hektisch werden und für kleine Teams wird es schwierig an den Aufgaben mit niedriger Priorität zu arbeiten, die viel Potenzial für Innovation bergen.

Auch das Scaled Agile Framework bietet keine magischen Lösungen, die es Entwicklern ermöglicht, viel freie Zeit für Innovationen zu haben.  Am Ende eines jedes Program Increments gibt es eine IP Iteration (Innovation & Planning-Iteration). In diesem Sprint werden keine Stories geplant, sondern Zeit für Dinge geschaffen wie die finale Integration von Systemen, Tests oder Performance- und Security-Tuning. Hier wird ebenfalls die Retrospektive auf Programmebene gehalten, bekannt als I&A (Inspect & Adapt). Während der I&A-Phase werden die Resultate eines PIs den Stakeholdern demonstriert, mit Problem-Solving Workshop und Retrospektive im Anschluss. Während einer IP-Iteration wird auch das nächste PI geplant.

Wie der Name aber bereits sagt, ist das auch die Zeit für Innovation. In dieser Zeit können Hackathon durchgeführt oder Innovationen umgesetzt bzw. Verbesserungen an der Infrastruktur, dem Code oder der Architektur vorgenommen werden. Und zu guter letzt hat das Team eine Pause vom hektischen Software-Entwicklungsalltag. Ein Teil dieser Pause kann auch für die persönliche Weiterentwicklung bzw. Schaffung neuer Kompetenzen genutzt werden.

Zusammenfassung

Scrum und Kanban sind für sich natürlich ausreichend für kleine Teams. Trotzdem gibt es vier Umstände, für die ausgewählte SAFe-Praktiken zusammen mit Scrum und Kanban effektiver sein können:

• Wenn es sich um strategische Softwareprodukte mit langer Lebensdauer handelt
• Wenn Abhängigkeiten mit mehreren Nicht-Software-Teams vorhanden sind
• Wenn der Bedarf für langfristige Investitionen wie DevOps besteht
• Wenn eine voraussichtliche Skalierung von klein auf mittelgroß ansteht

All diese Umstände lassen sich natürlich auch nur mit Scrum oder Kanban regeln, aber die Erfahrung hat gezeigt, dass die folgenden SAFe-Praktiken ein effektiveres Handeln ermöglichen:

1. Strategische Themes fassen die strategischen Prioritäten des Portfolios zusammen und helfen Teams dabei, sich an der Geschäftsstrategie auszurichten
2. Program Epics definieren die wertschöpfenden Vorhaben, worauf sich ein Team konzentrieren und wonach es den Backlog sortieren sollte
3. Program Kanban zeigt die Prioritäten und den Status von Epics für Stakeholder auf
4. Features sind detaillierter als Epics und ermöglichen eine effektive Kommunikation zwischen Team und Stakeholdern. Features sind genau auf die Länge von Program Increments (PI) ausgelegt.
5. PI Planning findet regelmäßig statt und ermöglicht es, ein gemeinsames Verständnis für die Prioritäten und Ziele für die nächsten acht bis zwölf Wochen zu erreichen
6. Die Innovation & Planning (IP)-Iteration am Ende eines jeden PIs ermöglicht dem Team eine wohlverdiente Pause vom Day-To-Day zu nehmen und Zeit mit der Findung von Innovationen und der Bildung neuen Skills zu verbringen.

Wir hoffen, dieser kurze Überblick konnte Ihnen das Scaled Agile Framework auch für kleine Teams schmackhaft machen. Wenn Sie weitere Informationen wünschen, wenden Sie sich einfach an unser Team.

Atlassian hat mit Bitbucket Server und Bitbucket Data Center 5.2 eine neue Version der fortschrittlichen Enterprise Git Hosting-Lösung veröffentlicht.

Das Herzstück des Entwicklungsprozesses eines jeden Teams ist die Versionskontrolle. Die gewählten Versionskontrollwerkzeuge und -technologien schreiben nicht nur vor, wie das Team interagiert – es kann auch davon abhalten den Arbeitsprozess zu verbessern. Beispielsweise ist es besonders frustrierend für Teams, wenn sie DevOps-Praktiken adaptieren möchten, die organisatorischen Richtlinien aber die Auswahl an Werkzeugen drastisch einschränken. Anforderungen wie Nachvollziehbarkeit, zentral verwaltete Workflows und Zugriffsstrukturen sorgen dafür, dass die meisten Tools herausfallen. Meist werden eigene Lösungen mit der heißen Nadel gestrickt oder veraltete Entwicklungsvorgehen beibehalten, nur um Compliance-Richtlinien zu erfüllen.

Bitbucket Server & Data Center vereinen das beste aus beiden Welten. Git-basiertes Repository-management mit Fokus auf Geschwindigkeit, Zusammenarbeit und Qualität gepaart mit der Sicherheit, Nachverfolgbarkeit und Skalierbarkeit um alle Compliance-Anforderungen zu erfüllen. Mit Version 5.2 führt Atlassian mit der Administration auf Projektebene ein neues Tool für die Erfüllung von regulatorischen Richtlinien ein, das ohne konstante Überwachung von Administratoren funktioniert.

Administration auf Projektebene

Bitbucket Server ist wie geschaffen für professionelle Softwareteams, da es im Vergleich zu anderen Git Management-Werkzeugen viel mehr Möglichkeiten bietet, Workflows anzupassen und abzusichern. Für jede Art von Repository können Administratoren das Branching-Modell, die Merge-Strategie für Pull Requests, die Voraussetzung dass alle Commits GPG-signiert sein müssen, eingeschränkter Zugriff auf Zweige und mehr festgelegt werden. All diese Optionen helfen dabei, regulatorische Anforderungen / Compliance zu erfüllen ohne dass sich das Team eben darum sorgen muss.

Bisher mussten Hooks, Zugriffsrechte für Zweige bzw. Branching-Modell und Pull Requests Merge-Checks für jedes Repository beim Erstellen konfiguriert werden. Das führt bei Organisationen in denen Teams hunderte oder gar tausende Repositories anlegen unweigerlich zu vergeudeter Zeit und potenziellen Sicherheitsproblemen, falls Adminrechte an Personen gegeben werden, die gar keinen administrativen Zugang benötigen.

Mit der Einführung der Administration auf Projektebene mit Bitbucket Server und Data Center 5.2 können diese Einstellungen jetzt alle auf einmal für ein Projekt gesetzt werden.

Die Administration auf Projektebene funktioniert ganz ähnlich wie Repository-Einstellungen. Benutzer, die das Recht zur Administration auf Projektebene haben können die Einstellungen für ein Projekt anpassen – und diese werden prompt für alle Repositories innerhalb des Projektes übernommen.

Alle neu erstellen Repositories erben die Einstellungen von der Projektebene. Falls ein Repository jedoch spezielle Anforderungen hat, kann der Repo-Administrator selbstverständlich die spezifischen Einstellungen setzen und so die Projekt-Konfiguration überschreiben. Atlassian hat weitere Informationen inklusive detaillierter Bebilderung in den Release Notes festgehalten.

Push Proxy für Smart Mirrors

Dank Smart Mirrors in Bitbucket Data Center können global verteilt arbeitende Teams Pull-Operationen in Umgebungen mit hoher Latenz und geringer Bandbreite signifikant beschleunigen. Die auf den Lesezugriff beschränkten Kopien von Repositories werden aktuell gehalten und erben alle Regeln und Zugriffsrechte von Master-Server. Bisher mussten beim Einsatz von Smart Mirrors Continuous Integration-Server und Entwickler jeweils zwei unterschiedliche URLs verwalten – eine für Fetch-Operationen von Mirror und die andere für Pushes zum Hauptserver. Mit Bitbucket Data Center 5.2 führt Atlassian sogenanntes Push Proxying für Smart Mirrors ein. Beide Operationen (Push und Fetch) werden in einer einzigen SSH bzw. HTTP-URL abgebildet und damit der Entwickleralltag ein bisschen erleichtert.

Compliance und DevOps vereint

DevOps in Unternehmen einführen und gleichzeitig ein sicheres, nachverfolgbares und skalierbares Entwicklungsumfeld zu schaffen ist möglich. Das gewählte Tooling sollte positive Veränderungen fördern und nicht verhindern. Mit Bitbucket Server 5.2 können Teams das Beste aus DevOps-Praktiken adaptieren und trotzdem voll den organisatorischen Richtlinien und Compliance-Anforderungen entsprechen. Für weitere Informationen kommen Sie einfach auf uns zu.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da.

• Weitere Information zu DevOps & Enterprise erhalten Sie auf den Braintime-Seiten zu Continuous Delivery.
• Sie interessieren sich für eine Demo oder Lizenz von Atlassian-Produkten? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt

Bei großen und komplexen Projekten ist das Anfangen häufig einer der schwierigsten Aspekte. Die Tools von Atlassian kommen tagtäglich für komplexe Projekte, Cross-Product-Integrationen bis hin zu Projekten mit strengen Deadlines oder verteilten Teammitgliedern zum Einsatz. Je größer und dynamischer ein Projekt ist, desto eher wird es Stress und Unentschlossenheit verursachen.

Bevor man auf ein Set an Werkzeugen setzt oder Frameworks wie Scrum, Kanban oder gar SAFe einsetzt lohnt es sich, erst einmal die folgenden Regeln zu beachten.

Fangen Sie mit dem Gesamtbild an

Die meisten Leute stürzen sich kopfüber ins Abenteuer, ohne sich zuvor einige ernste Gedanken über das große Ganze zu machen. Gewinnen Sie also zunächst ein wenig Abstand. Was ist das Hauptziel, welches Sie mit diesem Projekt erreichen möchten? Welches Ergebnis wird dieses Projekt liefern? Welche Probleme oder Chancen werden adressiert? Und wie wird der Erfolg gemessen?

Bilden Sie ein Team

Jedes große Projekt erfordert ein großartiges Team. Stellen Sie sich folgende Frage: Wer ist sonst noch für die Realisierung dieses Projekts verantwortlich? Und wer wird eine neue Rolle übernehmen müssen? Es ist von Vorteil, Mitglieder Ihres Unternehmens hinzuzufügen, die schon einmal Teil eines größeren Projekts waren, da sie mithilfe ihrer Erfahrung neue Herausforderungen erkennen und bekannte Herausforderungen meistern können.

Definieren Sie ein gemeinsames Ziel

Bevor Sie damit anfangen die Rollen und Aufgaben zu verteilen, ist es wichtig, dass Sie mit Ihrem Team kommunizieren und ein gemeinsames Ziel definieren, mit dem sich alle Beteiligten identifizieren können. Hören Sie auf jedes einzelne Teammitglied, um sicherzustellen, dass das Ziel klar definiert ist, es mit der Gesamtsituation sowie den Unternehmenszielen übereinstimmt und gleichzeitig herausfordernd, aber auch erreichbar ist. Sie können ihr gemeinsames Ziel auch in mehrere, individuelle oder abteilungsspezifische Ziele unterteilen, aber sorgen Sie dafür, dass Ihre Teammitglieder nicht das Endziel aus den Augen verlieren.

Berücksichtigen Sie die Rollen und Aufgaben

Teams leisten die beste Arbeit, wenn jeder seine Rolle versteht, jeder seine Stärken ausspielen und anderen Teammitgliedern helfen kann. Jetzt da Sie Ihr Team zusammengestellt und die Rollen sowie Aufgaben vergeben haben, ist es wichtig, dass Sie erkennen, wer mit der Arbeit vertraut ist oder von ihr betroffen sein wird. Wer sind die Stakeholder? Wessen Stimme hat bei diesem Projekt Gewicht?

Die Ziele aufteilen und den Umfang definieren

Beginnen Sie damit, Ihr Gesamtziel in kleinere, greifbarere Ziele zu unterteilen und entscheiden Sie, wer für welche Abschnitte des Projekts verantwortlich sein wird, basierend auf den vordefinierten Rollen und Aufgaben. Indem Sie ihr Endziel aufspalten, wird Ihr Projekt überschaubarer, Ihr Team wird weniger Stress empfinden und jeder kann sich besser auf die bevorstehenden Aufgaben konzentrieren. Investieren Sie ausreichend viel Zeit in diesen Schritt. Definieren Sie Ihre größeren Ziele, Aufgaben und Deadlines. Wenn Sie hier nicht genau nachdenken, werden Sie sich im Laufe des Projekts nur noch mehr Herausforderungen gegenüber sehen.

Um sicherzustellen, dass Ihr Projekt nach Plan verläuft, ist es hilfreich, einen Projektzeitstrahl mit Meilensteinen zu erstellen. Projektmeilensteine können Ihnen und Ihrem Team dabei helfen, sich besser auf die einzelnen Aufgaben zu konzentrieren.

Machen Sie sich das Leben einfacher, indem Sie Tools zur Zusammenarbeit nutzen

Wir sind uns bestimmt alle einig, dass es bei komplexen Projekten sehr schwierig ist, organisiert zu bleiben, während man mit den verschiedenen Teammitgliedern zusammenarbeitet. Ein Abbruch der Kommunikation kann teuer werden.
Zum Glück gibt es eine Reihe von web-basierten Projektmanagement-Softwares, die für Ihr Unternehmen extrem hilfreich sein könnten. Diese Systeme ermöglichen es Ihrem gesamten Team, Projekte und Rollen sofort und von überall aus zu betrachten, zu erstellen, zu ändern und zu aktualisieren. In der sich ständig verändernden Geschäftswelt von heute sind Übersichtlichkeit, Zusammenarbeit und Transparenz wichtiger als je zuvor. Jedes Team, das ernsthaft Overhead minimieren, großartige Arbeit abliefern und eine nahtlose Zusammenarbeit genießen möchte, sollte web-basiertes Projektmanagement in Betracht ziehen.

Kreieren Sie eine positive Arbeitsatmosphäre für Ihr Team

Es ist kein Geheimnis, dass die besten Ergebnisse dann erbracht werden, wenn die Mitglieder eines Teams sich gegenseitig voll vertrauen, sie komplett transparent und offen miteinander sind und positive Zusammenarbeit zur Bewältigung von Aufgaben nutzen. Die Arbeitsumgebung hat stets Auswirkungen auf das Verhalten einer Person. Schaffen Sie eine positive und motivierende Unternehmensatmosphäre, in der Ihre Teammitglieder ihr volles Potential ausschöpfen können. Wenn Ihre Teammitglieder wissen, dass die Leute, die sie respektieren und schätzen, sich auf sie verlassen, sorgt das in fast allen Fällen für bessere Ergebnisse. Motivieren Sie also alle Mitglieder Ihres Teams dazu, die zwar hochgesteckten, aber machbaren Ziele erreichen zu wollen.

Werfen Sie einen Blick auf den Team Health-Monitor von Atlassian, um die Verfassung Ihres Teams zu ermitteln:

Passen Sie sich an (immer und immer wieder)

Je größer Ihr Projekt ist, desto wahrscheinlicher ist das Auftreten von neuen und komplexen Herausforderungen. Als Teamleader müssen Sie trotz aller Widrigkeiten stets Belastbarkeit und Selbstvertrauen zeigen. Sie müssen sich schnell und mit einem sicheren Auftreten an die neuen Herausforderungen anpassen. Seien Sie bestimmt, was Ihre Ziele angeht, aber flexibel, wenn es um die Herangehensweise geht. Anstatt den Plan als das große Ziel Ihres Projekts anzusehen, sollten Sie sich auf das Gesamtbild konzentrieren und verstehen, dass sich vielleicht ein besserer Weg auftun könnte.

Komplexe Projekte sind keine leichte Aufgabe, aber wenn Sie diese Projektmanagement-Tipps im Hinterkopf behalten, werden sie auf jeden Fall einfacher.

Scaled Agile Framework: Agil und Skalierbar von Anfang an

Vielleicht sind Sie in einer Organisation tätig, die kleinere agile Einheiten für die Innovation schafft, aber noch an der Transformation für die Agilität im Großen arbeitet. Auch hier haben wir einige Tipps für Sie zusammengestellt.

Werfen Sie einen Blick auf die Best Practices für SAFe in kleineren Teams und bleiben Sie innovativ.

Um herauszufinden, was leistungsstarke IT-Teams antreibt, ist Atlassian eine Partnerschaft mit dem HDI (Help Desk Institute) eingegangen, dem führenden Verband für technischen Support. Bei den angestellten Nachforschungen handelte es sich aber um mehr als nur Fragen zu den Technologien, die von den befragten Teams genutzt werden.

Die Rolle der IT-Branche verändert sich – und das zum Besseren. Aufgrund von Automatisierung können immer mehr Aufgaben von einem Bot durchgeführt werden, einfache Dinge, wie das Zurücksetzen eines Passworts, bis hin zu komplexeren Aufgaben, wie das Berechnen der benötigten Rechenkapazität zu Spitzenzeiten. Schätzungen von McKinsey & Company zufolge, könnten in Amerika innerhalb der nächsten 20 Jahre bis zu 45% aller Jobs aus bestimmten Kategorien automatisiert werden. Dadurch würden Löhne in Höhe von 2 Trillionen USD verloren gehen.

Gleichzeitig hat die Cloud die IT-Abteilung in ihrer Rolle als Bereitsteller von Software abgelöst. Während viele IT-Teams diese Entwicklung als Bedrohung sehen, glauben wir, dass es eine große Chance darstellt. Befreit von traditionellen und trivialen Aufgaben, kann die IT-Abteilung mehr Zeit damit verbringen, ihren Kollegen dabei zu helfen, Technologie erfolgreicher für ihre alltäglichen Aufgaben einzusetzen. Die IT wird damit eher zum Torwächter und weniger zum Feuerwehrmann.

Atlassian hat knapp 200 IT-Teams befragt, um mehr über die von ihnen genutzten Technologien, Vorgänge und Gewohnheiten zu erfahren. Es wurde gefragt, wie sehr sie sich selbst in Einklang mit ihren Business-Teams sehen und für wie ausgereift sie ihre Prozesse halten. Teams, die in diesen Kompetenzen gut abschnitten, wurden als leistungsstarke Teams eingestuft.

Die 5 wichtigsten Dinge, die leistungsstarke Teams gemeinsam haben:

1. Business-Teams haben Priorität
2. Technologien werden gemeistert
3. Es wird in Geschwindigkeit investiert
4. Kunden werden zur Priorität erklärt
5. Aktives Handeln

Sehen wir uns einige dieser Punkte genauer an! Detailliertere Ergebnisse finden Sie in dieser Infografik.

Business geht vor

Um zu verstehen, ob IT-Teams mit den Business-Teams im Einklang sind, fragte Atlassian beispielsweise, wie Projekte priorisiert werden, ob die beiden Teams gemeinsame Ziele besitzen und woran der Erfolg gemessen wird.

IT-Teams, die sich in Sachen Prozessausgereiftheit gut bewertet haben, hatten doppelt so oft Ziele, welche auf Geschäftsergebnisse wie beispielsweise den Gewinn ausgerichtet waren und teilten sich achtmal so häufig Ziele mit den Business-Teams. Das zeigt, dass Teams mit ausgereiften Prozessen in den meisten Fällen sehr eng mit den Business-Teams zusammenarbeiten.

Wir sind sogar der Meinung, dass dies in Zukunft die wichtigste Fähigkeit für IT-Teams darstellen wird. Unsere These lautet, dass die erfolgreichsten IT-Experten Meister der Zusammenarbeit sind und genauso eifrig neue Businessstrategien lernen werden, wie neue Technologien oder ITIL.

Die Technologie meistern

Dieser Punkt klingt sehr offensichtlich und in gewisser Hinsicht liegt die Schönheit dieses Tipps in seiner Einfachheit. Im Herzen ein Technologieguru zu sein und innerhalb des Unternehmens Änderungen in Sachen Technologien zu erwirken, erfordert unterschiedliche Skillsets und besonders Letzteres trennt bei IT-Teams die Spreu vom Weizen.

Atlassian fand heraus, dass Teams, die eng mit Business-Teams zusammenarbeiten, doppelt so häufig einen Plan für digitale Veränderungen haben und 46% dieser Unternehmen erhalten einen besseren ROI im Bereich Technologie. Solche Teams investieren zudem wesentlich häufiger in fortschrittliche Technologien wie beispielsweise Machine Learning, prädiktive Analysen, und Tools, welche die Kundenerfahrung verbessern. Dank dieser IT-Teams können Angestellte die neusten Kollaborations-, Mobile- und Produktivitätstools nutzen, wovon wiederum das gesamte Unternehmen profitiert.

Außerdem investieren sie in Tools, die sie selbst nutzen. So verwendenn sie beispielsweise doppelt so oft ITSM-Tools, die nicht älter als 2 Jahre sind.

In Geschwindigkeit investieren

Leistungsstarke IT-Teams, die mit der Business-Abteilung zusammenarbeiten und über ausgereifte Prozesse verfügen, sorgen sich auch um die Arbeitsgeschwindigkeit. Diese Teams verwenden mit einer 18% höheren Wahrscheinlichkeit agile Prinzipien für die Planung ihrer Arbeit und praktizieren mit einer 15% höheren Wahrscheinlichkeit DevOps. Interessanterweise ist die einzige Kategorie, in der diese Teams Defizite haben, ITIL (diese sind jedoch geringer als bei ihren Team-Peers, die weniger businessorientiert sind). Man könnte deshalb behaupten, dass diese Teams sich weniger um die Prozesse sondern mehr um die Ergebnisse sorgen.
Aktives Handeln

Gute Absichten helfen nichts, wenn das IT-Team keine Zeit für andere Dinge als den alltäglichen Arbeitsaufwand hat. Mehr Mitarbeiter einzustellen ist dabei nicht der einzige Weg, um für mehr Zeit zu sorgen. Sie müssen Vorfälle abfangen, bevor sie sich schneeballartig verschlimmern und aktiv an der Lösung von grundlegenden Problemen arbeiten. Businessorientierte Teams haben 2,5-mal häufiger einen Problemmanagementplan und haben im Laufe der letzten zwei Jahre die Automatisierung von Aufgaben vorangetrieben. Vermeiden Sie es also, „Whack-a-Mole“ mit Ihren Problemen zu spielen und verbringen Sie nicht den ganzen Tag mit trivialen Aufgaben, damit auch Ihr Team zu einem leistungsstarken Team werden kann.

Was kann Ihr Team unternehmen, um hier die Nase vorne zu haben? Hier sind unsere Empfehlungen:

Wie ein Team zum Top-Performing Team wird:

Wir wissen, dass jedes Team unterschiedlich ist und diese Reise auf seine eigene Art und Weise angehen muss. Sehen Sie sich die komplette Infografik an, um zusätzliche Verhaltensweisen und Charakteristiken von leistungsstarken Teams kennenzulernen.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da.

• Weitere Information zu DevOps & Enterprise erhalten Sie auf den Braintime-Seiten zu Continuous Delivery.
• Sie interessieren sich für eine Demo oder Lizenz von Atlassian-Produkten? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt

Atlassian hat eine neue Version des Continuous Integration- und Continuous Delivery-Werkzeugs Bamboo freigegeben. Hauptaugenmerk dieser Version liegt bei der Verbesserung von den jüngst vorgestellten Bamboo Specs.

Verbesserte Bamboo Specs für Build Plans

Atlassian hat Bamboo Specs kürzlich eingeführt. Specs erlauben es, Build und Deployment-Pläne in Bamboo als Code zu definieren. Bamboo Specs hilft Nutzern der Software dabei, Pläne für Builds einfacher zu verwalten und Teile von Plänen für andere wiederzuverwenden. Administratoren in Enterprise-Umgebungen können nun viel effektiver skalieren, indem Konfigurationsoptionen für eine ganze Anzahl von Plänen via Code geändert werden können. Moderne Continuous-Integration-Workflows sind so im Enterprise-Kontext möglich.

Bamboo 6.1 bringt eine Vielzahl von Verbesserungen zu Bamboo Specs mit und macht Configuration as Code so einfach wie nie:

• Plan-Berechtigungen lassen sich verwalten. Damit lässt sich bestimmen, welche Nutzer Zugriff auf welche Funktionen eines Build Plans haben
• Benachrichtigungen über Buildergebnisse lassen sich im Code festlegen, sodass Sie sofort über Resultate im Bilde sind
• Diverse Plugins für Zusatzfunktionen wie Build-Expiry (ablaufende Builds) lassen sich konfigurieren
• Abhängigkeiten zwischen Plänen sind konfigurierbar

All diese Änderungen ermöglichen es, mehr und mehr Konfigurationselemente als Code abzulegen – was Sie wieder ein Schritt näher zur Infrastructure as Code bringt.

Bamboo Specs für Deployments und mehr

Deployment-Projekte in Bamboo sind Container für das Softwareprojekt, welches veröffentlicht werden soll. Sie bündeln Releases, die innerhalb eines Plans gebaut und getestet wurden und die Umgebungen, in welche diese Releases veröffentlicht werden sollen. Mit Bamboo 6.1 können Deployment-Projekte und deren automatische Auslösung mit Bamboo Specs direkt als Code definiert werden. Atlassian stellt eine umfangreiche Dokumentation rund um Bamboo Specs zur Verfügung.

Neben Bamboo Specs wurden ebenfalls weitere Verbesserungen mit Bamboo 6.1 ausgeliefert. Die Integration von Bamboo und Bitbucket Server wurde durch diverse Geschwindigkeitsverbesserungen und eine neue Benachrichtigung zu Builds, die gerade ausgeführt werden, verbessert. Damit bleiben Entwickler und Build-Engineers informiert und können sich besser auf die jeweiligen Aufgaben konzentrieren. Weiter wurde die Unterstützung für Git Large File Storage (Git LFS) verbessert sowie native Unterstützung für xCode bzw. Fastlane für iOS, OSX und Android-Entwickler bereitgestellt.

Atlassian hat mit Confluence 6.3 eine neue Version der beliebten Enterprise Wiki-Software veröffentlicht. Klarer Fokus der vorliegenden Version sind verbesserte Stabilität und kleine Tweaks beim Benutzerkomfort.

Verbesserungen bei der Stabilität

Wenn Confluence ein geschäftskritisches Werkzeug in Ihrem Unternehmen wird, sind Verlässlichkeit und Stabilität Grundvoraussetzung. Atlassian hat sich über die letzten Releases hinweg bemüht, Confluence stabiler und zuverlässiger zu machen. Hier ist eine Aufzählung der Highlights:

Limitierung der gleichzeitigen Bearbeiter

Um Einbußen bei der der Performance vorzubeugen, wurde die maximale Anzahl von gleichzeitigen Bearbeitern einer Seite auf zwölf beschränkt. Dies bedeutet im Klartext: Wenn bereits zwölf Nutzer die Seite bearbeiten, müssen weitere Bearbeiter zuerst warten, bis einer der aktiven Nutzer den Editor verlässt, um die Seite bearbeiten zu können.

Performance-Optimierung bei Indizierung von Anhängen

Wird eine Datei in Confluence hochgeladen, werden die textuellen Inhalte extrahiert und indiziert, damit Nutzer nach den Inhalten einer Datei und nicht nur dem Dateinamen suchen können. Dieser Vorgang benötigt relativ viel Arbeitsspeicher und hat bei einigen Kunden zu Out-Of-Memory-Problemen geführt. Das vorliegende Release 6.3 von Confluence Server und Data Center verbessert die Performance und bringt zusätzliche Mechanismen mit sich, um Out-Of-Memory-Fehler zu verhindern. Eine kurze Übersicht:

• Falls die hochgeladene Datei größer als 100 MB ist, wird Confluence den Inhalt der Datei nicht extrahieren und indizieren, sondern nur den Dateinamen speichern
• Falls die hochgeladene Datei als Word, Excel, PDF oder Text vorliegt, wird Confluence die Datei bis zu einem spezifischen Limit extrahieren und indizieren
• Ist der Text aus einer Datei extrahierte Text größer als 1 MB, werden die Inhalte zwar durchsuchbar aber nicht als Exzerpte in den Suchergebnissen auftauchen

Atlassian stellt in der Dokumentation umfangreiche Guides zum Thema Attachment-Größe bereit. Die Änderungen stellen einen großen Vorteil für Nutzer dar, von daher haben die Australier diese Limits auch in Confluence 6.2.3 aktiviert.

Mehr unterstützte Datenbanken

Mit Confluence 6.3 werden auch mehr Datenbanken unterstützt. So werden Postgres 9.6, MySQL 5.7 sowie die neusten JDBC-Treiber für MySQL, PostgreSQL und Oracle unterstützt.

In Bearbeitung befindliche Elemente leichter auffinden

Es ist nun noch einfacher, Ihre sich in Bearbeitung befindlichen Elemente aufzufinden. Sie können Ihre Arbeit fertigstellen und weitermachen. Die zuletzt bearbeiteten Elemente finden Sie im Profil-Menü (1) sowie im Dashboard (2). Dies ist besonders nützlich, falls Ihre Confluence-Instanz als Startseite eine Confluence-Page anstelle des Dashboards besitzt.

Unterstützung für weitere Sprachen

Confluence unterstützt von nun an drei weitere Sprachen out of the box: Estnisch, Isländisch und Slowenisch. Damit unterstützt Confluence 6.3 ganze 16 Sprachen bei Installation – ohne zusätzliche Sprachpakete zu benötigen.

Atlassian hat die Identity Management-Lösung Crowd in einer Data Center-Variante verfügbar gemacht. Seit 2007 hilft Crowd Atlassian-Kunden dabei, die Anforderungen fürs Identity Management bei selbst gehosteten Lösungen zu erfüllen. Umso mehr unterschiedliche Atlassian-Produkte bei Kunden im Einsatz waren, umso mehr stieg der Bedarf an einem einfachen Weg zur Userverwaltung und dem Berechtigungsmanagement für mehrere Nutzerverzeichnisse an einem einzigen Ort. Mit Crowd sind Sie in der Lage eine beliebige Kombination von Verzeichnissen in einer Anwendung zu verwalten, womit Sie in der Lage sind Nutzer und Gruppen unabhängig Ihrer Hauptverzeichnisse zu verwalten.

Nutzer in vielen Anwendungen zu verwalten ist hinreichend kompliziert. Sie müssen alle Verzeichnisse integrieren und zentral verwalten. Sie müssen ebenfalls unterschiedlichen Nutzergruppen Zugang zu unterschiedlichen Anwendungen geben. Crowd erlaubt es Ihnen, Nutzer zentral zu verwalten ohne die Vertraulichkeit Ihrer Daten zu verletzen. Neben der Arbeitserleichterung für Administratoren macht Crowd das Leben Ihres Teams leichter. Mit Single Sign-On sind Teams dazu in der Lage, in eine Applikation einzuloggen und danach auf eine weitere zu wechseln ohne Nutzernamen und Passwort erneut eingeben zu müssen.

Crowd Data Center: Neu im Team

Atlassian Crowd ist für viele Unternehmen zu einem kritischen Werkzeug geworden. Es stellt eine Single-Source-Of-Truth für Nutzer und Gruppen dar und unterstützt eine große Auswahl an Authentifizierungsmechanismen. Falls Crowd ausfälllt, sind Teams nicht mehr dazu in der Lage auf die Werkzeuge, die sie für die tagtägliche Arbeit benötigen, zuzugreifen.

Atlassian hat offiziell Crowd Data Center angekündigt, welches die Data Center-Familie um hochverfügbares Enterprise Identity Management bereichert.

Geschaffen für Zuverlässigkeit

Crowd Data Center ermöglicht Zuverlässigkeit auf einem ganz neuen Level. Mit Crowd Data Center wirken sich unerwartete Ausfälle nicht länger auf die Produktivität und Performance ihrer Teams aus. Um noch mehr Uptime zu garantieren, können Sie auch mehrere Failover-Verzeichnisse festlegen, um die Auswirkungen im Falle eines Ausfalls eines externen Verzeichnisses zu minimieren und sicherstellen, dass sich Ihre Nutzer zu jeder Zeit einloggen können.

Dank Crowd Data Center können Sie ganz einfach einen Knoten hinzufügen (oder entfernen) um die Last von vermehrten Authentifizierungsanfragen zu minimieren und Cluster-Monitoring einsetzen, um ein Auge auf den Zustand Ihres Clusters zu haben.

Integration mit bestehender Infrastruktur (sogar Microsoft Azure AD)

Neben Hochverfügbarkeit liefert Crowd Data Center nativen Support für Microsoft Azure Active Directory. Lösungen im Rahmen von VPC (Virtual Private Clouds) werden immer gängiger. Aus diesem Grund setzen viele Server- und Data Center-Kunden von Atlassian auf diese Deployment-Optionen und wünschen sich zusätzliche Unterstützung. Mit dieser neuen Integration können Sie Azure Active Directory mit allen Vorteilen nutzen. Zum Beispiel hilft inkrementelle Sychronisation dabei, Zeit und Ressourcen zu sparen.

Atlassian kündigt für die Zukunft viele weitere spannende Features an, die Identity Management im Enterprise leichter und schneller machen.

Atlassian und das Team hinter Portfolio für JIRA hat die Veröffentlichung von Portfolio für JIRA 2.4 angekündigt.

Die neue Version enthält die folgenden Verbesserungen:

• Verbesserungen für Programme
• Die Möglichkeit, Konflikte zu lösen, während an parallelen Sprints gearbeitet
• Zeitzonenkonfigurationen für Pläne
• Zusätzliche JQL-Operatoren für Parent-Link- und Team-Felder

Atlassian hat zudem einige Verbesserungen vorgenommen und Fehler behoben, die unten aufgelistet sind.

Verbesserungen für Programme

Seit dem Beta-Programm hat Atlassian die Programmansicht ständig verbessert.

Bessere Filter für die Zeitplanansicht

Haben Sie mehrere Pläne in Ihrem Programm? Kein Problem! Sie können sich ab sofort mehrere Pläne in der Zeitplanansicht Ihres Programm ansehen – oder mithilfe eines Filters nur das anzeigen lassen, was Sie gerade sehen möchten.

Programmkonfigurationen sind jetzt verfügbar

Zuvor erhielten Programme lediglich die Berechtigungen des Plans, in dem sie sich befanden. Nun können Sie je nach Bedarf bestimmte Berechtigungen zu Ihren Programmen hinzufügen.

Atlassian erleichtert außerdem die Auswahl der Pläne, die Sie in Ihrem Programm sehen möchten:

Keine Konflikte mehr in parallelen Sprints

Portfolio für JIRA 2.4 verbessert außerdem die Art und Weise, auf die Portfolio für JIRA die Arbeit mehrerer Teams in parallelen Sprints handhabt.

Wenn es nun zu Überschneidungen zwischen parallelen Sprints kommt, können Sie sie auf folgende Weise ganz einfach lösen:

• Die Sprints den entsprechenden Teams zuweisen
  

• Oder zukünftige Sprints den entsprechenden Teams zuweisen
  

Alles in derselben Zeitzone und am selben Ort

Portfolio für JIRA bietet nun die Möglichkeit, die Zeitzone Ihres Plans zu konfigurieren – alle relevanten Sprint-Termine werden mit allen Ihren Projekten in JIRA Software und mit Ihren Portfolio-Plänen synchronisiert:

Möchte jemand noch mehr JQL-Operatoren?

Atlassian hat neue JQL-Operatoren hinzugefügt, um JQL-Suchen für Parent- Links und Teams in Portfolio für JIRA besser zu verarbeiten:

• Für ‚Parent-Link‘-Customfelder: IS EMPTY und IS NOT EMPTY
• Für ‘Team’-Customfelder: !=, NOT IN, IS EMPTY, und IS NOT EMPTY

Kleinere Verbesserungen und gelöste Probleme

Atlassian hat bemerkt, dass in einigen seltenen Fällen nicht alle Issues in Portfolio für JIRA angezeigt wurden – dieser Fehler konnte eine Reihe von Gründen haben. Das Entwicklerteam hat dafür gesorgt, dass ab sofort alle Issues korrekt angezeigt werden, ganz egal welche JQL-Anfragen Sie verwenden.

Atlassian hat zudem den Rendervorgang für Pläne in Portfolio für JIRA beschleunigt.

Ein einzigartiger Teil des Service, den Atlassian seinen Kunden bietet, sind die vielfältigen Deployment-Optionen. Kunden können sich, je nach Anforderungen, zwischen Cloud, Server oder Data Center entscheiden. Das bietet den Kunden den großen Vorteil, dass ihre Teams unsere Tools unabhängig von Anforderungen an die Infrastruktur oder andere Vorlieben des Unternehmens nutzen können.

Ein nicht ganz so offensichtlicher Vorteil ist, dass die Teams entscheiden können, welche Features der Deployment-Optionen sie verwenden möchten und wann diese eingesetzt werden sollen.

In der Vergangenheit versuchte Atlassian, den Funktionsumfang der drei Deployment-Optionen möglichst identisch zu gestalten. Aber dank der Hilfe durch Kundenfeedback, wird Atlassian die einzelnen Optionen ab sofort an die Anforderungen der jeweiligen Kernanwender anpassen.

Bryan Rollins hat einige Informationen zusammengefasst, die Ihnen dabei helfen werden, die Prioritäten Atlassians bei der Entwicklung der Deployment-Optionen besser zu verstehen.

Unterschiedliche Deployment-Optionen für unterschiedliche Anforderungen

Zunächst einmal möchten wir Ihnen einen Überblick über alle Optionen geben und Ihnen erklären, welche Option für welche Kunden geeignet ist.

Server: Server ist Atlassians ursprüngliche Deployment-Option und ist für viele Kunden das erste Atlassian-Produkt. Der Kunde lädt die Software herunter und installiert sie auf einem einzelnen Server, der ihm gehört. Diese Lösung eignet sich gut für Teams aller Größen – aber besonders für Teams mit speziellen Anforderungen, da eine breite Palette von Add-Ons zur Verfügung steht, mit denen die Teams ihren Server anpassen und konfigurieren können.

Data Center: Viele Server-Kunden haben Atlassian darüber informiert, dass während geplanter oder ungeplanter Downtimes das gesamte Unternehmen zum Stillstand kommt, weil die Atlassian-Tools dann nicht mehr verfügbar sind. Aus diesem Grund wurde die Data-Center-Produktreihe eingeführt. Data Center läuft auf dem Datencenter des Kunden, oder bei einem Infrastructure-as-a-Service-Provider wie beispielsweise Amazon Web Services (AWS).

Der Fokus von Data Center liegt auf Verfügbarkeit, Skalierbarkeit, Performance und Kontrolle über die eigene Infrastruktur. Kunden, die Data Center nutzen, sind in der Regel größere Unternehmen, die häufig zahlreiche Standorte in aller Welt besitzen, und für die Verlässlichkeit, Stabilität und skalierbare Performance extrem wichtig sind.

Cloud: Ein immer größer werdender Teil unserer Kunden bevorzugt es, die Infrastruktur für Atlassian-Tools nicht mehr selbst zu verwalten (bzw. selbst zu warten oder zu aktualisieren). Viele Unternehmen nutzen deshalb für Ihre Anwendungen die Cloud: Sie wollen keine eigene Hardware besitzen oder die Infrastruktur selbst verwalten müssen. Cloud-Kunden bevorzugen ein Software-as-a-Service-Modell und ihnen gefällt es, dass sie stets die aktuellste Version aller Tools nutzen können.

Während alle Deployment-Optionen stetig an Popularität gewannen, stellte Atlassian fest, dass das Feedback der einzelnen Kundengruppen immer individueller wurde.

Server-Kunden wünschten sich beispielsweise einfachere Upgrades; eine Sache, die für Cloud-Kunden kein Problem darstellt. Data-Center-Kunden wollten die Latenzzeiten für ihre globalen Teams reduzieren, ein Problem, das die meisten Server-Kunden nicht haben. Cloud-Kunden wünschten sich dagegen die Integration anderer cloudbasierter Dienste wie PagerDuty oder Invision.

Atlassian reagiert auf dieses Feedback mit einer wichtigen Änderung: Wir werden nicht länger versuchen, dieselben Features für alle Deployment-Optionen anzubieten. Stattdessen wird die Priorität für die Verbesserungen der einzelnen Deployment-Optionen auf den Anforderungen der einzelnen Kundengruppen basieren.

Wie Atlassian Updates für die einzelnen Deployment-Optionen priorisieren wird

Endnutzer haben Atlassian mitgeteilt, dass sie überzeugende Features wie Kollaborative Echtzeit-Bearbeitung in Confluence und Code-Aware-Search in Bitbucket lieben. Aber manche Kunden müssen zusätzlich bestimmte Datenschutzrichtlinien einhalten. Kunden von Data Center haben dagegen Tausende von Nutzern, die von diesen Tools abhängig sind und einen großen Wert auf Skalierung und Kontrolle über ihre Infrastruktur legen.

Stellen Sie sich vor, Atlassian veröffentlicht einige Design-Updates oder ein neues Feature für Cloud-Nutzer und erleichtert Server-Admins zur selben Zeit die Versionsaktualisierung. Das neue Feature für Cloud-Nutzer würde für Server-Kunden erst zu einem späteren Zeitpunkt veröffentlicht werden. Backlogs für Kanban Boards in JIRA Software sind hierfür ein perfektes Beispiel: Zuerst wurde das Feature für die Cloud veröffentlicht und seit JIRA Software 7.4 ist es nun auch für Server verfügbar.

Manchmal fließen die Features auch in die entgegengesetzte Richtung. Beispielsweise beim Programm-Management in Portfolio für JIRA. Programm-Management ist in erster Linie ein Feature für Unternehmen, es war deshalb sinnvoll, dieses Feature zuerst für Server- und Data-Center-Kunden zu veröffentlichen (dort, wo sich die meisten Großkunden aufhalten), bevor es auch für die Cloud zugänglich gemacht wurde.

Features, die von Cloud-Only-Diensten oder -Technologien abhängen, sind nicht Teil der Server-Roadmap. Features, die nur für Server- oder Data-Center-Kunden wichtig sind, beispielsweise verbesserte Installer, sind dagegen kein Teil der Cloud-Roadmap.

Ihre Vorlieben, Ihre Prioritäten

Da Cloud, Server und Data Center nun nicht mehr im Gleichschritt entwickelt werden, kann Atlassian jede Option genau an Ihre Anforderungen anpassen. Wenn es um die Gestaltung der Roadmaps für die einzelnen Deployment-Optionen geht, vertraut Atlassian auf seine Unternehmenswerte, insbesondere die folgenden: „Entwicklung mit Herz und Verstand“ und „Der Kunde ist König“. Ganz egal wie Ihre Deployment-Vorlieben aussehen – Cloud, Server oder Data Center – jeden Tag nehmen wir Verbesserungen vor, die Ihre Prioritäten widerspiegeln. Atlassian unterstützt auch weiterhin die Möglichkeit, von einer Option zur anderen zu migrieren, wenn sich Ihre Anforderungen ändern sollten.

DevOps basiert auf der Kombination von drei Grundprinzipien, die sich auf Ihren Erfolg auswirken (auch: Die Drei Wege des DevOps): Flow, Feedback und Experimente.

Auf Ihrem Weg mit DevOps wirken sich diese drei Prinzipien auf die Art und Weise wie Sie über Arbeit denken, mit Ihrem (erweiterten) Team interagieren und welche Praktiken Sie umsetzen. Arbeiten alle drei Elemente zusammen, erschaffen Ihre Entwicklungs- und IT Betriebs-Teams schneller hochqualitative Software, mit weniger Stress und geringerem Risiko. Bei jeder DevOps-Transformation müssen sich Teams darüber Gedanken machen, wie sie zusammenarbeiten. Die Teamkultur muss eine Umgebung schaffen, in der alle drei Grundprinzipien gedeihen können. Nur so können die unterstützenden Prozesse, Werkzeuge und Technologien die neue Art und Weise der Zusammenarbeit verstärken.

Zum Thema Werkzeuge für Entwickler: Hier helfen Atlassian Bitbucket Server & Data Center bei allen drei Prinzipien (Flow, Feedback und Experimente). Heute soll es aber vor allem um ein Kernelement gehen: Die Integration von JIRA Software und Bitbucket Server und Data Center. Mit Bitbucket Server & Data Center Version 5.3 ist es möglich, Issues in JIRA Software aus Pull Requests in Bitbucket heraus zu erstellen.

Die Auswirkungen auf den Flow

Sicherzustellen, dass die aktuelle Arbeit für alle Beteiligten durch den gesamten Entwicklungsprozess hindurch nachverfolgbar festgehalten wird, ist ohne das richtige Werkzeug ein fehleranfälliger und zeitraubender Prozess. Die Anforderungen an die Informationen können sehr eng abgesteckt sein, so möchte zum Beispiel ein Team Lead den Entwicklungsfortschritt eines einzelnen Vorgangs, Commits oder Code Reviews einsehen. Oder aber die Anforderungen können sehr breit gefächert sein, wie ein Team aus dem IT Betrieb, welches die Release Readiness über Projekte oder Geschäftsbereiche hinweg im Auge behalten möchte. Egal wie die Eingrenzung ausfällt, mit JIRA Software und Bitbucket sind Sie dazu in der Lage, die Sichtbarkeit von Arbeit durch den gesamten Entwicklungsprozess hindurch sicherzustellen. Geplante Arbeit wird mit Änderungen am Code, Builds und Deployments verknüpft. Bitbucket Commits, Zweige und Pull Requests lassen sich In JIRA Software anzeigen:

Sie können mehr und mehr Zeit sparen, indem Sie bestimmte Integrationen an Ihre Arbeitsweise anpassen. Abhängig von der Art und Weise, wie Ihr Team arbeitet, können Sie den Status von Vorgängen in JIRA manuell über Pull Requests oder direkt über Git Commit-Nachrichten verändern. Wenn beispielsweise ein Pull Request erstellt wird, kann ein JIRA-Vorgang automatisch von „In Progress“ auf „In Review“ geschoben werden. Kurzum: Sich ständig wiederholende, manuelle Aufgaben werden automatisiert, was die Konsistenz erhöht, Frustrationen verringert und Verzögerungen vermeidet.

Mit Bitbucket Server 5.3 Vorgänge aus Pull Requests heraus erstellen

Natürlich ist es toll, dazu in der Lage zu sein, eine Idee von der initialen Erstellung des Vorgangs bis hin zur Veröffentlichung in Produktion genau nach der Arbeitsweise der involvierten Teams zu verfolgen. Dennoch gibt es während der Entwicklung Probleme, die als separate Vorgänge wieder in den Kreislauf einlaufen. Ein Beispiel dafür sind Code Reviews, d.h. Pull Requests in Bitbucket.

Oft stellen Teams während eines Reviews fest, dass irgendetwas nicht so ganz stimmig ist – aber die Umsetzung der Verbesserung passt nicht zum eigentlichen Pull Requests. Vielleicht ist eine neue Möglichkeit fürs Refactoring aufgetreten, oder eine lang vergessene Aufgabe wurde wieder ins Gedächtnis gerufen – was im System fürs Issue-Tracking festgehalten werden sollte, sodass es nicht wieder vergessen oder ignoriert wird. So müssen Entwickler jedes Mal nach JIRA Software wechseln, ihre Arbeit unterbrechen und einen neuen Vorgang für später anlegen und den Link zum Vorgang in einen Kommentar zum Pull Request kopieren, damit die Überlegung für andere sichtbar wird.

Mit Bitbucket Server 5.3 wird der Flow besser aufrecht erhalten, indem es von nun an möglich ist, Vorgänge in JIRA Software direkt aus einem Pull Request heraus in Bitbucket zu erstellen. Wenn Ihnen also das nächste Mal etwas auffällt, was unbedingt festgehalten werden muss – sparen Sie sich den Wechsel nach JIRA Software und erstellen Sie den Vorgang direkt aus Bitbucket heraus.

Die Integration handhabt die ganze Arbeit für Sie. Sie müssen lediglich den JIRA Vorgang erstellen-Knopf im Kommentar drücken, die Felder ausfüllen und zurück zum Review gehen.

Die richtigen Werkzeuge Machen den Unterschied

Die Werkzeuge, die Sie zur Unterstützung für Ihren Weg zu DevOps auswählen sorgen nicht dafür, dass das Unternehmen automatisch zu einem Vorreiter für DevOps wird, macht aber den Übergang von kein DevOps hin zu DevOps wesentlich einfacher. Am Ende sollte die Source Code-Verwaltung die Art und Weise, wie Sie Aufgaben anlegen und verfolgen unterstützen. Teams bleiben im Flow, wenn sie neue Aufgaben schnell erfassen und ablegen können. Wählt man Bitbucket Server und JIRA Software als Werkzeuge, bekommt man hier schon wesentliche Funktionalitäten out-of-the box geliefert.

Bitbucket Server & Data Center 5.3 verändern und erleichtern dank der tiefgreifenden Integrationen Ihren Arbeitsalltag. Kommen Sie dazu einfach auf uns zu.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da.

• Weitere Information zu DevOps & Enterprise erhalten Sie auf den Braintime-Seiten zu Continuous Delivery.
• Sie interessieren sich für eine Demo oder Lizenz von Atlassian-Produkten? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt

Regulatorische Compliance ist in etwa so aufregend wie eine Wurzelbehandlung. Die gute Nachricht ist aber, dass es nicht annähernd so schmerzhaft sein muss.

Mittlerweile haben Sie höchstwahrscheinlich schon einmal was von DevOps gehört. Vielleicht stimmen Sie sogar dem Argument zu, dass DevOps dabei helfen kann, Compliance-Standards einzuhalten. Nicht nur, weil Automatisierung ein integraler Bestandteil von DevOps ist, sondern weil es gleichzeitig ein guter Weg ist, um sicherzustellen, dass Entwicklungs- und Deployment-Pratiken verlässlich, wiederholbar und nachvollziehbar sind. Nicht zu vergessen, dass Automatisierung den gesamten Prozess beschleunigt, wodurch Sie genauso schnell arbeiten können wie Ihre Mitbewerber (oder sogar schneller). Außerdem legt DevOps den Fokus auf eine transparente Unternehmenskultur, was sich besonders bei Audits auszahlt.

So etwas lässt sich nicht über Nacht erreichen, aber in vier – nicht unbedingt einfachen, aber absolut machbaren – Schritten können auch Sie es schaffen.

Schritt 1: Identifizieren und dokumentieren Sie alle Richtlinien, von denen Ihr Team betroffen ist

Dieser Schritt ist so selbstverständlich, dass er leicht zu übersehen ist. Sorgen Sie dafür, dass Ihre Teammitglieder und Stakeholder genau wissen, welche Vorschriften Sie einhalten müssen, wie Sie sie einhalten werden und wo alle relevanten Informationen nachgeschlagen werden können (für den unwahrscheinlichen Fall, dass sie nicht über ein fotografisches Gedächtnis verfügen). Um die „Dokumentenversionshölle“ (übrigens auch ein Fachbegriff) zu vermeiden, sollten Sie alles auf Wiki-Seiten dokumentieren und Links zu diesen Seiten auf allen Teamportalen, Dashboards, etc. platzieren. Besonders praktisch ist, wenn Sie bestimmte Personen als „Beobachter“ eintragen, damit diese im Falle eines Updates direkt benachrichtigt werden.

Schritt 2: Erstellen Sie Ihr Automations-Backlog

Sobald alle Beteiligten verstanden haben, welche Dinge wichtig sind und weshalb, können Sie die Grundlage für Automatisierung kreiren, die Ihnen die Compliance erleichtern wird. Beginnen Sie mit repetitiven Aufgaben, die sich gut automatisieren lassen.

Hierzu gehören typischerweise:

• Pull-Requests – Obwohl Pullanfragen stets einer sorgfältigen Überprüfung durch einen Mitarbeiter unterliegen sollten, können Sie die mühsamen Bestandteile der Anfragen automatisieren. Zum Beispiel könnten Sie dafür sorgen, dass immer mindestens zwei Prüfer die Pullanfrage bestätigen müssen und dass es keine fehlgeschlagenen Builds oder Testläufe geben darf, die im Zusammenhang mit dem jeweiligen Commit stehen.
• Codeabdeckung – Jedes gute CI/CD-Tool kann so konfiguriert werden, dass Builds als fehlgeschlagen markiert werden, wenn die Testabdeckung unter einem bestimmten Schwellenwert liegt.
• Erstellen Sie Verknüpfungen – Stellen Sie sicher, dass Änderungen am Code, Code-Reviews, Build-Ergebnisse, Deploys und Issues alle miteinander verknüpft sind. (Damit meine ich, dass Sie mit nur einem Mausklick von einer Sache zur anderen springen können). Das macht die alltägliche Arbeit und auch Audits wesentlich einfacher.
• Berechtigungen – Sicherheit…ein schwieriges Thema. Aber Sie können Ihren Repository-Manager so konfigurieren, dass nur bestimmte Leute Änderungen an bestimmten Repos und/oder Branches vornehmen können – außerdem können Sie einstellen, dass niemand Änderungen direkt in der Produktion vornehmen kann.
  • Hinweis: Alle Repos und Branches sollten nur mit Lesezugriff zugänglich sein. Der Grund: DevOps. Und weil diese Art von Transparenz einfach praktischer ist.
• Audit-Trails – Schützen Sie sowohl Ihren Verstand als auch den Regenwald, indem Sie Build-, Test- und Deployment-Resultate automatisch protokollieren lassen. Schließen Sie dann den Kreis, indem Sie Commits, Reviews und Issues wie oben erwähnt miteinander verknüpfen.
• Failover und Wiederherstellung – Infolge eines fehlgeschlagenen Deployments automatisch einen Rollback durchführen zu lassen, ist wesentlich sicherer als ihn manuell durchzuführen. Außerdem ist es nachvollziehbarer und schneller, was Ihnen wiederum dabei helfen wird, SLAs (Service Level Agreements) einzuhalten.

Sorgen Sie dafür, dass eine Handvoll dieser Tipps in jede Iteration eingebaut wird. Und reflektieren Sie regelmäßig: „Sind unsere Zugriffskontrollen für Branches effektiv oder übertrieben?“ „Hat unsere Code-Abdeckung die Auditoren zufrieden gestellt?“. Der Trick ist es, Ihre Obligationen zu erfüllen, ohne sich dabei selbst im Weg zu stehen. Auch hier müssen Sie hin und wieder versuchen, das berühmte Kamel durchs Nadelöhr zu treiben.

Schritt 3: Sorgen Sie für mehr Kultur

Um ehrlich zu sein, sollte dieser Schritt parallel zu den Schritten 1 und 2 stattfinden, denn in der Welt von DevOps ist Unternehmenskultur immer eine Priorität. (Aber „immer“ würde unsere schön durchnummerierte Liste durcheinander bringen).

Wenn Ihr Team unter schlechter Kommunikation, ständigen Schuldzuweisungen und/oder unklaren Rollen und Verantwortungen leidet, wird vereinzelte Automatisierung allein nicht ausreichen. Organisieren Sie ein Meeting mit Ihrem Team, identifizieren Sie die Probleme und finden Sie gemeinsam Wege, um diese zu lösen. Klingt zwar nicht gerade einfach, aber keine Angst: Das Atlassian Team Playbook kann Ihnen weiterhelfen.

Teams, die genau wissen wo das Problem liegt, können sich direkt die Sammlung von Plays ansehen und nach Problemen filtern. Leiden Sie unter „Kommunikationsabbrüchen“? Oder vielleicht am „Mangel-an-Leadership-Syndrom“? Das Team Playbook wird Ihnen eine Reihe von hilfreichen Techniken vorschlagen, mit denen Sie Ihr Team wieder auf die Beine helfen können.

Vergessen Sie nicht, dass die Plays keine zusätzliche Arbeit darstellen. Sie sind lediglich unterschiedliche (und effektive) Wege, um die Arbeit anzugehen, die Sie bereits erledigen müssen.

In vielen Fällen kennen dysfunktionale Teams die Gründe für Ihre Probleme nicht. In solchen Situationen kommt der Team Health Monitor zum Einsatz. So hat Ihr Team die Chance, sich mit leistungsstarken Teams und deren Attributen zu vergleichen und herauszufinden, was verbessert werden kann. Sie erhalten zusätzlich Vorschläge für Plays, die Ihnen bei der Lösung Ihrer Probleme helfen können.

Praktischerweise enthält das Team Playbook einen “Spielplan“, speziell für den Aufbau einer DevOps-Unternehmenskultur – darunter befinden sich beliebte Plays wie “Pre-mortem” oder “Rules of Engagement“. Spielpläne sind eine nützliche Abkürzung, aber Sie sollten trotzdem den Team Health Monitor nutzen, um die Performance Ihres Teams zu überprüfen. Das meine ich ernst.

Vergessen Sie außerdem nicht, Ihre Siege zu feiern! Selbst ein kurzes High Five bei einem Standup für Dinge, die trivial erscheinen (die Codeabdeckung ist um 20 Prozent gestiegen – Super!“) wirkt Wunder, was die Aufrechterhaltung der Motivation und Teammoral angeht.

Schritt 4: Verbessern Sie kontinuierlich Ihren Entwicklungs-Workflow

Nun da Sie sich auf dem Weg in Richtung guter Teamgesundheit befinden, ist es Zeit, an Ihrem Dev-Workflow zu arbeiten. Verschaffen Sie sich einen Überblick und suchen Sie nach leicht erzielbaren Erfolgen, mit denen Sie anfangen können. Eine häufige DevOps-Praktik ist beispielsweise die Einführung eines Feature-Branching-Workflows mithilfe von Git oder Mercurial.

All die unordentliche Arbeit in einem isolierten Feature-Branch aufzubewahren, bis sie sich als produktionsreif herausgestellt hat, wird mit fast absoluter Sicherheit dafür sorgen, dass Sie keinen „Oh Mist!“-Moment erleben werden – Beispielsweise, wenn Sie feststellen, dass Sie eine Deobfuscation aller Kundendaten in Ihren Produktionslogs durchgeführt haben. Außerdem können Sie die oben erwähnten automatisierten Berechtigungen nutzen, um den Fluss von Veränderungen von Branch zu Branch und Umgebung zu Umgebung besser zu kontrollieren.

Überprüfen Sie, ob Sie über die nötige Code-Abdeckung verfügen und ob sie dort vorhanden ist, wo sie benötigt wird. „Spezifikation nach Beispiel“ funktioniert hier besonders gut. Arbeiten Sie mit Ihrem Compliance Lead zusammen, um zu verstehen wie ein Compliance-Verstoß aussehen würde („wie würde sich der Verstoß in den Logs manifestieren?“). Schreiben Sie anschließend Tests, die den Build fehlschlagen lassen, sobald diese Bedingungen erkannt werden.

Wenn Sie über umfangreiche Auto-Tests verfügen, haben Sie die Möglichkeit, Builds automatisch in die nächsthöhere Umgebung weiterleiten zu lassen, je nachdem unter welchen Regulationen Sie arbeiten. Automatisierte Deployments sind Ihr Freund. Sie sind verlässlich und nachvollziehbar – Traits-Auditoren lieben das.

Welcher Overhead würde sich mithilfe von Automatisierung noch eliminieren lassen? Wenn Sie beispielsweise JIRA Software verwenden, um Ihre Arbeit zu protokollieren, könnten Sie es mit Bitbucket integrieren, um von den „Smart Commits“ zu profitieren. Diese leiten relevante Issues automatisch in den nächsten Workflow-Schritt weiter und Sie sparen sich dadurch den Weg zurück zum Agile-Board. Oder Sie können Ihren Repository-Manager mit Ihrem CI/CD-Tool integrieren, um automatisch einen Build auszulösen, wenn eine Pullanfrage erstellt wird.

Es ist ein langer Weg und kein Schalter, der sich umlegen lässt

Tut Ihnen schon der Kopf weh? Machen Sie sich keinen Stress. Die einzelnen Punkte nach und nach abzuarbeiten und zu iterieren macht den Übergang hinsichtlich der Logistik wesentlich machbarer. Erinnern Sie sich noch an Maria? Kontinuierliche Verbesserung ist genau das, was ihrem Team wieder auf die Beine geholfen hat. Ich würde lügen, wenn ich Ihnen jetzt erzählen würde, dass es einfach für sie war. Aber ihr Team hat es geschafft und jetzt läuft bei ihr alles rund.

Was den technischen Aspekt angeht, sollten Sie es in Betracht ziehen, zu einem  Git-Repository-Management-Tool wie beispielsweise Bitbucket Server oder Bitbucket Data Center zu wechseln. Teams, die in regulierten Branches arbeiten, profitieren von Bitbuckets Workflow-Verbesserungen (wie die Notwendigkeit, dass „grüne Builds“ oder mehrere bestätigte Code-Reviews vorliegen müssen), Adminkontrolle auf Projektebene und granulare Berechtigungsoptionen.

Wenn Sie bereits Bitbucket Server/Data Center nutzen und Ihre CI-Praktik ausbauen möchten, sollten Sie einen Blick auf Bamboo werfen. Es verfügt über ein Set von Compliance-relevanten Features wie beispielsweise Projektorganisation, Berechtigungen und eine tiefgreifende Integration von Bitbucket Server und JIRA Software.

Atlassian hat mit Confluence 6.4 eine neue Version der beliebten Enterprise Wiki Software veröffentlicht. Die aktuelle Version erleichtert den Zugriff auf Entwürfe und bringt viele kleinere Verbesserungen mit sich.

Erleichterter Zugriff auf Entwürfe

Häufig steht man vor dem Problem, an einer neuen Confluence-Seite zu arbeiten – aber noch nicht bereit dafür zu sein, den “Veröffentlichen”-Knopf zu drücken. Diese noch nicht veröffentlichten Seiten heißen in Confluence Entwürfe (Drafts). Bisher war es relativ schwierig, seine Entwürfe wieder aufzufinden. Mit Confluence 6.4 erleichtert Atlassian es ungemein, auf Entwürfe zuzugreifen. Von nun an kann man ganz einfach auf dem Dashboard unter Recently worked on die Entwürfe finden, die man zuletzt erstellt bzw. bearbeitet hat. So müssen Sie nicht länger die Entwürfe in Ihrem Profil suchen oder das Browsertab offen halten, um später an begonnenen Seiten weiterzuarbeiten.

Unfertige Änderungen besser im Blick behalten

Enwürfe sind das eine – allzuoft beginnt man damit, eine bestehende Seite zu überarbeiten, aber kommt nie dazu die Änderungen auch tatsächlich zu veröffentlichen. Solche Änderungen liegen unfertig und vergessen herum. Mit Confluence 6.4 ist dies nicht mehr der Fall: Eine nützliche Markierung (Unpublished changes) zeigt in der Liste der zuletzt bearbeiteten Elemente und auf der eigentlichen Seite an sich an, ob es noch ausstehende Änderungen gibt. So sehen Sie auf einen Blick, ob es noch etwas zu tun gibt:

Und selbstverständlich sehen nur Beteiligte, die an den noch nicht veröffentlichten Veränderungen beteiligt waren diese Markierung. Reguläre Besucher der Seiten bekommen nichts von den ausstehenden Änderungen mit. Dank Recently Worked On und Markierungen behalten Sie die ausstehende Arbeit noch besser im Blick.

Seitenhistorie mit mehr Informationen

Die Seitenhistorie zeigt nun den Namen und Avatar der Personen an, die eine Version bearbeitet haben:

Performance Testing Framework für alle

Das Performance Testing Framework erlaubt es nun die Testfälle in eigenen Umgebungen auszuführen. Zuvor lief das Performance Testing Framework lediglich in AWS-Umgebungen. Mittels des Frameworks ist es möglich eine Instanz von Confluence Data Center hochzufahren und reproduzierbare Workloads zu simulieren. Es ist auch möglich, verschiedene Versionen von Confluence zu testen oder unterschiedliche Cluster-Konfigurationen zu prüfen und Durchsatz, Antwortzeiten und andere elementare Statistiken Seite an Seite zu prüfen.

Quellen & Links

• Confluence Release Notes

Weitere Fragen?

Dann sind wir als Atlassian Platinum Partner für Sie da. Tragen Sie jetzt alle noch offen gebliebenen Fragen und Wünsche zum Thema Confluence an uns heran. Wir freuen uns darauf, gemeinsam mit Ihnen herauszufinden, wie Sie die Werkzeuge von Atlassian optimal nutzen können.

• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.
• Sie haben Interesse an einer Demo von Confluence -Produkten, wollen mehr über das Thema erfahren oder ein individuelles Angebot für das Plugin erhalten? Wenden Sie sich dafür über das Kontaktformular an uns.

Kontakt

Transparenz ist für ein Unternehmen mit agiler Kultur von höchster Priorität. Integrität innerhalb und zwischen den Teams ist ein essentieller Teil des Erfolgs Ihrer Teams und Ihres Unternehmens. Laut einer Umfrage von TinyPulse, einem B2B-SaaS-Umfrageunternehmen, ist Transparenz zudem der wichtigste Faktor, der zur Zufriedenheit Ihrer Angestellten beiträgt.

Transparenz bei der Arbeit und Transparenz innerhalb eines Unternehmens bedeutet, dass die Kommunikation mit Ihren Teammitgliedern stets offen und ehrlich abläuft und eine Unternehmenskultur fördert, in der Informationen frei zwischen Mitarbeitern und Teams fließen kann. Obwohl Transparenz häufig nur mit vagen Aussagen beschrieben wird, sind ihre Vorteile durchaus greifbar. Hier sind fünf einfache Wege, mit deren Hilfe Sie in Ihrem Unternehmen für mehr Transparenz sorgen können.

1. Seien Sie ehrlich

Denken Sie an die unterstützende Ehrlichkeit, die Sie von einem Mentor erwarten würden. Ohne Bedenken Feedback geben und erhalten zu können, ist ein wichtiges Kennzeichen für Transparenz. Offene Kommunikation schafft Vertrauen, sorgt für Innovation und kreiert ein gesundes Arbeitsumfeld.

Indem Sie wichtige Informationen mit Ihren Kollegen teilen, kreieren zudem eine positive und produktive Plattform für Zusammenarbeit. Wenn Sie Ihren Teammitgliedern dagegen wichtige Informationen vorenthalten, kann das den Projekten Ihres Teams schaden und das Vertrauen zwischen den Teammitgliedern zerstören. Wenn jeder weiß, was in seinem Team passiert und weshalb, werden Sie feststellen, wie viel größer das Engagement bei der Arbeit ist und wie Probleme auf kreativere Art und Weise und in exakter Übereinstimmung mit Ihren Anforderungen, gelöst werden.

Ein exzellentes Beispiel für radikale Transparenz ist Buffer, ein Unternehmen, das seinen Nutzern dabei hilft, ihr Publikum auf deren Socialmedia-Seiten zu vergrößern. Buffer entschied sich dazu, die Gehälter seiner Angestellten zu veröffentlichen. Daraufhin vergrößerte sich das Vertrauen zwischen den Teammitgliedern bei Buffer drastisch und das Unternehmen sorgte so für eine gesündere und nachhaltigere Arbeitsatmosphäre. Transparenz in Sachen Gehalt half dem Unternehmen sogar bei der Rekrutierung neuer Mitarbeiter. Nachdem Buffer seine Gehälter und Gehaltsformeln Ende 2013 veröffentlichte, stieg die Anzahl der Bewerber im darauffolgenden Monat um 230%.

2. Teilen Sie Ihre Ergebnisse mit anderen

Einer der besten Wege, um Transparenz zu schaffen und für mehr Motivation zu sorgen, ist es, Erfolge, Niederlagen und Herausforderungen mit anderen zu teilen. Die Erfolge zu teilen ist der einfachste Teil. Schwieriger ist es dagegen, zuzugeben, dass manche Dinge nicht nach Plan gelaufen sind; dies erhöht jedoch das Vertrauen und den Zusammenhalt Ihrer Teams.

Jeff Bezos, CEO von Amazon, weiß Niederlagen sehr zu schätzen. In einem Brief an seine Aktionäre, den er kürzlich verfasste, schrieb er folgendes: „Um etwas zu erfinden, muss man experimentieren – wenn man aber bereits im Voraus weiß, dass der Versuch gelingen wird, handelt es sich gar nicht um ein Experiment. Die meisten größeren Unternehmen streben nach Innovation, sind aber nicht dazu bereit, die Reihe von fehlgeschlagenen Experimenten zu erleiden, die zum Erreichen dieses Ziels erforderlich ist.

3. Abbau von Silos

Einer McKinsey-Studie zufolge, glauben fast 80% aller Vorstandsmitglieder, dass Kommunikation ein entscheidender Faktor für Wachstum ist, aber nur ein Viertel hatte das Gefühl, dass ihr Unternehmen gute Kommunikation betreibt. Tägliche Standups abzuhalten ist ein guter Anfang, aber für eine absolut transparente Unternehmenskultur sollten Sie sicherstellen, dass alle notwendigen Informationen für alle Ihre Abteilungen frei zur Verfügung stehen.

Transparenz zu einer Priorität zu erklären, macht es wesentlich einfacher, Bürokratie und ein politisches Arbeitsumfeld zu vermeiden. Geschäftsführer können zudem eine Strategie der „offenen Tür“ einführen, „Town Hall Meetings“ organisieren oder sogar das Büro neu arrangieren. Sie könnten eine offene Raumaufteilung einführen, in der Wände als Whiteboards genutzt werden können. Vergessen Sie außerdem nicht, Orte zu schaffen, an denen Ihre Teams Freundschaften schließen und gegenseitiges Vertrauen aufbauen können.

4. Stellen Sie Leute ein, denen Transparenz wichtig ist

Am Ende nützt keiner Ihrer Versuche etwas, wenn Ihren Mitarbeitern Transparenz nicht genauso wichtig ist wie Ihnen. Es gibt daher keinen besseren Weg, um für eine transparente Unternehmenskultur zu sorgen, als Leute einzustellen, die Transparenz zu schätzen wissen.

Die gute Nachricht ist, dass 87% aller Leute für ein transparentes Unternehmen arbeiten möchten. Wenn Sie also Transparenz zu einem Bestandteil Ihres Bewerbungsprozesses und der Bewerbungsgespräche machen, werden Sie mit Sicherheit das Interesse vieler großartiger Kandidaten wecken.

Bei Atlassian diskutieren wir unsere Unternehmenswerte in Sachen Transparenz während der Bewerbungsgespräche und fragen unsere Kandidaten anschließend was ihre Einstellung zu diesem Thema ist.

5. Entscheiden Sie sich für Tools, die Transparenz fördern

Wie viele Stunden haben Sie schon damit verschwendet, in einer E-Mail nach einem Dokument zu suchen, den Zugriff auf eine Datei zu erfragen oder mehrere Versionen eines Entwurfs zu bearbeiten (und diese hoffentlich nicht zu verlieren)? Im Durchschnitt verbringt jeder Angestellte 20% der Woche damit, nach internen Informationen zu suchen und Kollegen um Hilfe zu fragen. Das ist eine riesige Zeitverschwendung! Jeder in Ihrem Unternehmen muss genau wissen, wo sich alle relevanten Informationen finden lassen, wer die richtige Kontaktperson ist und wie sich Probleme am schnellsten lösen lassen.

Tools, die den Informationsfluss fördern und organisieren, können Barrieren eliminieren, die sonst den Fluss von Informationen innerhalb eines Unternehmens stören würden. Sie sollten nach etwas suchen, das Sie mit Ihrem Team, Ihrer Abteilung und dem gesamten Unternehmen teilen können – am besten schnell. Sie sollten über einen Ort verfügen, an dem sich Teammitglieder gegenseitig Feedback und Hilfe geben können. All das sollte zudem online verfügbar sein, damit alle Beteiligten stets die aktuellsten Informationen zur Hand haben.

Für Mercy Ships, einer internationalen Non-Profit-Organisation, die das weltweit größte Hospitalschiff besitzt, ist Confluence „die Schlüsselkomponente zur Expansion des Unternehmens“ geworden. Der Grund: Sie konnten Ihre Teams aus aller Welt miteinander verknüpfen und „Transparenz in verschiedene Aspekte des Unternehmens schaffen“. Confluence half dabei, die Support-Büros aus aller Welt mit den Teams an Bord des Schiffes zu verbinden.

Transparenz heißt sinnvolle Arbeit

Kann Transparenz beeinflussen, was unter dem Strich herauskommt?

Kurz gesagt: Ja. Aber es geht um mehr als nur den finanziellen Profit. Transparenz ermöglicht es jedem Ihrer Angestellten, sich als Teil einer wichtigen Sache zu fühlen. Es geht darum, Vertrauen zu schaffen und darum, Ihren Teammitgliedern dabei zu helfen, bedeutungsvolle Arbeit zu verrichten, welche einen spürbaren Unterschied macht.
Denn genau das sollte sie sein.

Dieser Artikel basiert auf einem Beitrag von Atlassian-Mitarbeitern und wurde zuerst im Atlassian-Blog veröffentlicht.

Das Atlassian JIRA Software-Team hat die Veröffentlichung von JIRA Software 7.5 bekannt gegeben. Das Entwickler-Team hat wieder eng mit den Produktmanagern, der Forschung und Designern zusammengearbeitet, um ein Produkt von Mehrwert für den Kunden zu schaffen. Highlights der vorliegenden Version sind ein verbesserter Kanban-Backlog, flexiblere Sprints und die Möglichkeit Vorgänge im Backlog aufzuteilen.
Atlassian hat selbstverständlich noch mehr Neuerungen und zahlreiche parat, diese beleuchten wir weiter unten im Artikel. JIRA Software wird so laut Atlassian zu einer immer besseren und runderen Erfahrung für die breite Kundenbasis.

Ein Kanban-Backlog mit einer Brise Scrum

Atlassian hat zwei neue Panels im Backlog implementiert, die dabei helfen sollen, den Backlog aufzuräumen und künftige Arbeit besser zu planen. Epic- und Versions-Panels sind nach dem Upgrade aktiviert und können im Kanban backlog entsprechend ausgeklappt oder versteckt werden. Diese Panels gruppieren alle Versionen und Epics und ermöglichen es so, diese als schnelle Filter zu nutzen, um durch die zusammengehörigen Vorgänge zu navigieren. So sehen schnell, was erledigt werden muss. Um die Panels zu sehen, wechseln Sie einfach in Ihren Kanban-Backlog:

Drag & drop

Sie können Ihre Vorgänge ganz einfach auf Epics ziehen, um diese mit dem entsprechenden Epic zu verknüpfen. Falsches Epic gewählt? Kein Problem, einfach den Vorgang auf ein anderes ziehen, um den JIRA-Vorgang schnell einem anderen Epic zuzuweisen. Es gibt eine zusätzliche Kategorie für nicht zugewiesene Vorgänge, sodass nichts verloren gehen kann.

Epics als Karten

Diese Änderung beinflusst auch die Art und Weise wie Epics auf Ihrem Board dargestellt werden. Alle Epics werden im Epic-Panel angezeigt. So sehen Sie diese nicht wie die anderen Vorgänge als Karten. Falls Sie sich nicht so recht daran gewöhnen können, kann der Board-Admin das Epics-Panel in den Einstellungen deaktivieren.

Ziele setzen

Es ist wichtig, dass Sie und Ihr Team dasselbe Ziel vor Augen haben, wenn es um Aufgaben geht, die erledigt werden müssen. Mit JIRA Software 7.5 können Sie ein Ziel für jeden Sprint angeben, um Ihr Team fokussiert zu halten. Performance verbessern, Bugs fixen oder nach den Sternen greifen? All dies ist möglich. Egal welches Ziel Sie wählen, es wird unter dem Sprintnamen im Backlog, auf Ihrem Board und in Reports angezeigt.

Um ein Ziel zu einem Sprint hinzuzufügen, wechseln Sie in Ihrem Scrum backlog und wählen Sie > Add Sprint Goal aus.

Umbenennen und Löschen von Sprints

Atlassian hat sich mit JIRA Software 7.5 auch darum bemüht, die Verwaltung von Sprints zu erleichtern. Egal ob es sich um einen Tippfehler, Änderung des Scopes oder einen Anflug von Kreativität handelt – Sie können von nun an die Namen von Sprints anpassen bzw. Sprints komplett löschen. Dieses Feature ist besonders nützlich für Benutzer, die mehrere Beispielsprints zwecks Evaluation von JIRA Software angelegt haben. Anstatt diese Sprints in Ihrem Projekt zu behalten, was eventuell Ihre Reports oder künftige Planung beeinflussen könnte, löschen Sie diese einfach.

Falls Sie den Sprint noch nicht gestartet haben, können Sie diesen im Scrum backlog via > Delete sprint einfach löschen. Bei bereits abgeschlossenen Sprints können Sie diese entweder umbenennen oder löschen indem Sie > Delete sprint oder > Edit sprint auswählen. Ein gelöschter Sprint ist permanent entfernt.

Verbleibende Zeit anzeigen

Natürlich ist ein entspannter Gang durch das Büro und die eigenen Teammitglieder nach ihrer Arbeit zu fragen ein wichtiger Aspekt des Netzwerkens und Team-Buildings. Trotzdem hat sich Atlassian dazu entschieden, den Arbeitsalltag zu erleichtern, indem sich jetzt ganz leicht anzeigen lässt, wieviel Zeit in einem Sprint verbleibt.

Zusätzlich zur Anzeige des Workloads nach Bearbeiter können Sie sich auch die für den Workload benötigte Zeit anzeigen lassen. So ist es einfach zu sehen, ob Sie einen zusätzlichen Bug in einen Sprint quetschen können oder doch noch mehr Ressourcen brauchen.
Um die verbleibende Zeit zu sehen, wechseln Sie zum Scrum-Backlog und klicken auf … neben den Avataren unter dem Sprintnamen.

Weitere Verbesserungen

Atlassian hat auch weitere Verbesserungen bereitgestellt, darunter:

• Es gibt nun Events die bei Erstellung und dem Löschen von Issue Links emittiert werden. Sie können diese nutzen, wenn Sie Plugins oder Webhooks erstellen, um Veränderungen an Issue-Links festzustellen
• Code, überall Code: Atlassian hat Syntax-Highlighting für mehr als 25 Sprachen hinzugefügt, darunter C++, Python, Ruby und mehr
• Vorgänge lassen sich jetzt in mehrere Vorgänge zerteilen, was sich ganz einfach über Split Issue bewerkstelligen lässt
• Zehn neue Sprachen werden unterstützt, darunter Tscheschisch, Dänisch, Rumänisch und Schwedisch.

Quelle: Atlassian Confluence – JIRA Software Release Notes

Atlassian hat mit Stride ein neues cloudbasiertes Werkzeug zur Teamkommunikation angekündigt, welches Teams dabei unterstützen soll, weniger zu besprechen und mehr zu erledigen. Die Frage die man sich als Atlassian-Kunde stellt: Wie ordnet sich Stride in die Familie der bestehenden Kommunikationslösungen ein und wie steht es in Zukunft um HipChat?

Atlassian erklärt: Auch wenn Stride ein neues Cloud-Produkt darstellt, wird HipChat Data Center die selbst gehostete Lösung der Wahl für Enterprise-Kunden bleiben, die eine skalierbare Lösung für streng regulierte Industriezweige (z.B. Finanz- und Gesundheitswesen) mit hohen Anforderungen an Compliance und Sicherheit suchen. Atlassian versichert, die Investitionen in HipChat Data Center weiter zu verstärken und auf Wachstum im Bereich der Fortune 500-Unternehmen zu setzen.

Zusätzlich zu den üblichen Verbesserungen im Bereich Skalierbarkeit, Hochverfügbarkeit und verbesserter Nutzererfahrung für Administratoren basiert HipChat Data Center wie die anderen Data Center-Produkte auf einer neuen Architektur. Dies war nur der erste Schritt von Atlassian, HipChat zu einer einfach zu installierenden Applikation zu machen. Atlassian stellt in einem Beitrag die in Zukunft zu erwartenden Verbesserungen und Änderungen vor, die die zukunftsweisend für moderne Messaging-Lösungen sein sollen:

Blick in die Zukunft: Neue Applikationen

In den kommenden Monaten wird Atlassian neue HipChat Data Center-Applikationen für Windows, Mac, iOS und Android veröffentlichen. Diese basieren auf den neusten Technologien und bietet verbesserte Stabilität und Zuverlässigkeit vor allem unter Windows. Diese lassen sich bereits jetzt in einem Beta-Programm ausprobieren.

Diese neuen Anwendungen ermöglichen es, neue Video- und Screensharing-Funktionen zu nutzen. Atlassian nennt dieses Feature-Set Meetings und liefert dieses mit einem verbesserten UI aus. Meetings beinhaltet dieselben Video und Screensharing-Funktionen wie der derzeitige HipChat-Client mit der zusätzlichen Möglichkeit, Fernsteuerung, Anrufe nach außen und Nur-Audio Gespräche zu nutzen sowie eine Chrome-Erweiterung für Kalendereinträge.

Und das Wichtigste: Verbesserte Benachrichtigungen. Künftig werden deutliche Markierungen die verpassten Nachrichten in Abwesenheit hervorheben. Jeder Raum und jede 1:1-Konversation an denen Sie teilnehmen werden hervorgehoben, wenn es dort ungelesene Nachrichten gibt und der Zeitstempel der letzte Nachricht und Mentions wird angezeigt. Dies ist auch konsistent über alle Geräte und Browser hinweg. Atlassian verspricht diese Änderungen für später in diesem Jahr.

Atlassian hält auch ein Webinar im Oktober, in welchem Sie mehr über die Verbesserungen und Zukunft von HipChat Data Center erfahren können. Die Australier werden bald dazu einladen. Weiter stellt Atlassian auch einen FAQ zu Stride und HipChat Data Center zur Verfügung. Falls Sie noch auf HipChat Server setzen, sollten Sie bald auf HipChat Data Center upgraden und von verbesserter Skalierung, Verfügbarkeit und Kontrolle profitieren. Als Atlassian Platinum Solution Partner bietet Braintime Ihnen den perfekten Ansprechpartner – kontaktieren Sie uns dazu einfach.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Partner für Sie da.

• Weitere Information erhalten Sie auf den Braintime-Seiten zu HipChat.
• Sie interessieren sich für eine Demo oder Lizenz von Atlassian-Produkten? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt

Das Team von Atlassian JIRA Service Desk hat die beliebte Helpdesk-Lösung in Version 3.8 freigegeben. Kurz zuvor wurde Version 3.7 veröffentlicht; diese Änderungen betrachten wir ebenfalls in diesem Artikel.

Atlassian hat viele Bugs behoben, kleinere Details ausgebügelt und die gesamte Nutzererfahrung in JIRA Service Desk verbessert. Wesentliche Neuerungen sind vorgefertigte Antworten und die Möglichkeit, SLAs von existierenden Projekten zu importieren. Damit sparen Sie beim Erstellen von Projekten Zeit, da Sie nicht SLAs erneut anlegen müssen.

Vorgefertigte Antworten

Arbeitet Ihr Team an einem Service Desk-Projekt, welches ständig viele ähnlich geartete oder vielleicht sogar genau die gleichen Antworten benötigt? Der Wunsch danach, Antworten auf Anfragen einfach wiederverwenden zu können ist in so einem Fall entsprechend groß. Atlassian hat eine Lösung für dieses Problem in Form von vorgefertigten Antworten.

Vorgefertigte Antworten ermöglichen es Ihnen, wiederverwendbare Antworten direkt aus dem Issue-Screen heraus zu erstellen, bearbeiten, zu verwalten und zu verwenden. Alle Agenten innerhalb eines Projekten haben Zugriff auf die gespeicherten vorgefertigten Antworten, sodass Ihre Kollegen Zugriff auf die von Ihnen erstellten Antworten haben, genau wie Sie auf die Ihrer Kollegen.

Beispiele für vorgefertigte Antworten:

• Die Nachfrage eines Kunden nach mehr Informationen
• Eine kurze Nachricht darüber, dass die Anfrage in Arbeit ist und mit einer Antwort in 24 Stunden zu rechnen ist
• Eine ausführliche Antwort, die den Kunden darum bittet, die Nutzungsbedingungen zu akzeptieren bevor die Anfrage weiter bearbeitet werden kann.

Sie können Ihre vorgefertigten Antworten ganz einfach verwalten und Nutzungsstatistiken abrufen und können so sehen, welche der Antworten beliebt sind und welche vielleicht mehr Aufmerksamkeit benötigen.

Endlich sind die Tage extern gepflegter Dokumente mit Textschnipseln vorbei, die in Antworten auf Anfragen in JIRA kopiert werden müssen. Dank vorgefertigten Antworten können Sie Textbausteine ganz einfach in JIRA Service Desk innerhalb einer Issue einfügen.

Import existierender SLAs

Manchmal möchte man ein neues Projekt anlegen, welches auf einem bereits existierenden Projekt aufbaut. Sie konnten bisher zwar die bestehende Konfiguration eines Projekts wiederverwenden, aber nicht die bereits definierten SLAs. Mit JIRA Service Desk 3.8 ist dies nun auch möglich, indem Sie existierende SLAs direkt in das neue Projekt importieren können.

Um dies zu bewerkstelligen, wechseln Sie einfach in die Projekteinstellungen, das SLA-Menü und wählen Sie Import SLA configuration.

Ereignisse für Issue-Links

Es gibt nun Events die bei Erstellung und dem Löschen von Issue Links emittiert werden. Sie können diese nutzen, wenn Sie Plugins oder Webhooks erstellen, um Veränderungen an Issue-Links festzustellen.

Syntax Highlighting für weitere Sprachen

Atlassian hat Syntax-Highlighting für mehr als 25 Sprachen hinzugefügt, darunter C++, Python, Ruby und mehr. Das Syntax-Highlighting funktioniert in allen Textfeldern.

Jedes gute agile Team muss wissen: Läuft alles nach Plan? Und wenn nicht, warum? Deshalb hat Atlassian für Portfolio for JIRA Server einen neuen Abhängigkeitsbericht implementiert, der Ihnen auf einen Blick die Abhängigkeiten zwischen verschiedenen Teams und Projekten zeigen kann. Der Bericht wird Ihnen dabei helfen, mögliche Projektverzögerungen zu vermeiden und sorgt dafür, dass Sie einzelne Issue-Links nicht nach Updates zu abhängigen Work-Items durchsuchen müssen.

Neben dem neuen Abhängigkeitsbericht hat Atlassian ein weiteres Feature veröffentlicht, mit dem sich Zeitplan-Faktoren für individuelle Issues hervorheben lassen. Lesen Sie weiter, um mehr über diese neuen Features zu erfahren. Außerdem erfahren Sie hier wie Sie mithilfe dieser Features agile Praktiken über Softwareteams hinweg skalieren können.

Abhängigkeitsverhältnisse zwischen Arbeitspaketen in JIRA Software visualisieren

Eine Schlüsselkomponente von skalierter Agilität ist die Fähigkeit, alle Teammitglieder auf dem Laufenden zu halten. Last-Minute-Überraschungen passieren selbst den Besten unter uns, aber sie sollten auf keinen Fall die Norm sein. Damit Teams ihre Releasetermine nicht verpassen, muss jemand einen Einblick in den Status und den Fortschritt der agilen Entwicklung und der Abhängigkeiten zwischen den verschiedenen Teams und Projekten haben.

Ganz egal, ob diese Person ein Produktmanager, Programmmanager oder Projektmanager ist, ohne Portfolio for JIRA müsste man bei der Nachverfolgung von Abhängigkeiten viel Zeit mit Herumfragen verbringen und auf Links zwischen JIRA-Software-Issues vertrauen. Dieser zeitaufwändige und manuelle Prozess schafft viel Platz für Fehler, denn Sie müssen sich bei Ihrem Risikomanagement auf Ihr Gedächtnis und Mundpropaganda verlassen. Was Sie eigentlich benötigen, ist ein Weg um alle Abhängigkeiten für ein kommendes Release auf einen Blick betrachten zu können. Und genau das bietet Ihnen der neue Abhängigkeitsbericht in Portfolio für JIRA: Er stellt Abhängigkeitsverhältnisse zwischen Work-Items in JIRA Software und Oberflächenabhängigkeiten in einem einzelnen Bericht dar:

Indem es Anwendern von JIRA Software und Portfolio für JIRA ermöglicht wird, Abhängigkeiten zwischen mehreren Teams und Projekten zu überwachen und zu filtern, können die Verantwortlichen mit minimalem Aufwand die Übersicht behalten, managen und kommunizieren. Dank der Klarheit, die dieser Bericht schafft, müssen Sie sich nicht länger fragen, ob ein Release rechtzeitig fertig werden kann. Gleichzeitig können unsere Kunden sehen, was besser überwacht und gemanagt werden muss, damit das Projekt erfolgreich abläuft.

Genau deshalb ist Risikomanagement so wichtig. Für agile Teams bedeutet Risikomanagement aktives statt reaktives Handeln. Aus diesem Grund können Sie den Abhängigkeitsbericht filtern und so die jeweiligen Blockaden entdecken, die einer Deadline gegenüberstehen. Auf diese Weise können Sie aktiv etwas gegen diese Blockaden unternehmen und Risiken vermeiden.

Herausfinden, wie Work-Items in Pläne für Portfolio für JIRA eingeplant sind

Für den Fall, dass Sie nicht mit dem Algorithmus von Portfolio für JIRA vertraut sind: Portfolio für JIRA ruft Daten aus JIRA Software ab und erstellt automatisch eine Roadmap basierend auf verschiedenen Faktoren wie Issue-Rang, Kapazität, Abhängigkeiten, Release-Aufträgen und vielem mehr. Außerdem wird basierend auf den aufgelisteten Variablen automatisch ein Zeitplan für alle Issues erstellt.

Um zu verstehen wie diese Dinge eingeplant werden und was passiert, wenn Sie eine Issue auf ein anderes Datum verlegen möchten, bietet Portfolio für JIRA nun neue Zeitplan-Informationen für Issues, dank denen Sie alle Planungsfaktoren hervorheben lassen können, die eine Issue betreffen.

Dieses Feature erleichtert es Ihnen, den Plan auf einer Metadaten-Ebene zu verstehen. Nehmen wir an, dass Sie alle relevanten Daten für Ihre Issues eingespeichert und einen Plan erstellt haben. Der Zeitplan sieht aber anders aus als der, den Sie eigentlich erwartet hatten (z.B. Eine Issue ist viel später eingeplant als gedacht).

Nun können Sie sich die Planungsfaktoren für diese Issue ansehen und herausfinden, welche Variablen die Planung dieser Issue betreffen und wie Sie die Issue auf ein früheres Datum verlegen können. Möglicherweise erhalten Sie den Vorschlag, die Issue um einen Sprint zu verschieben oder eine Abhängigkeit zu entfernen. Außerdem kann dieser Diagnoseprozess Kunden dabei helfen, mit all den Variablen vertraut zu werden, die bei der Verwendung von Portfolio für JIRA wichtig sind. Zudem ist diese Funktion hilfreich für Teams, die üben wollen wie agile Softwareentwicklung im großen Stil funktioniert. Um einen möglichst akkuraten Zeitplan zu erhalten, müssen Sie besser inspizieren, anpassen und planen. In der agilen Softwareentwicklung bedeutet das: Schätzungen vornehmen, die Velocity nachverfolgen, konsequentes Backlog-Grooming betreiben und für offene Kommunikation zwischen den verschiedenen Teams sorgen.

Inspizieren, adaptieren und planen Sie mit Portfolio für JIRA

Dank der erhöhten Transparenz können größere Unternehmen besser kommunizieren, iterieren und kontinuierlich wertvolle Softwarelösungen an ihre Kunden liefern. Portfolio für JIRA verleiht JIRA Software mehr Transparenz und gibt den Leuten, die für die Durchführung von Projekten verantwortlich sind, einen besseren Überblick über den Status und Fortschritt der agilen Softwareentwicklung. Die nahtlose Integration sorgt dafür, dass Teams genau sehen können wie sie ihre Praktiken iterieren, anpassen und verbessern können.

Weitere Fragen?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da. Tragen Sie jetzt alle noch offen gebliebenen Fragen und Wünsche zum Thema der neuen JIRA-Produktfamilie an uns heran. Wir freuen uns darauf, gemeinsam mit Ihnen herauszufinden, wie Sie die Werkzeuge von Atlassian optimal nutzen können.

• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.
• Sie haben Interesse an einer Demo von JIRA-Produkten, wollen mehr über das Thema erfahren oder ein individuelles Angebot erhalten? Wenden Sie sich dafür über das Kontaktformular an uns.

Kontakt

Atlassian hat die Continuous Integration- und Continuous Delivery-Lösung Bamboo Server in Version 6.2 veröffentlicht. Hauptaugenmerk dieser Version liegt auf der Verbesserung der neuen Bamboo Specs und Enterprise DevOps.

Aber: Was bedeutet Enterprise DevOps überhaupt? DevOps in sehr großen oder sehr streng regulierten Organisationen umzusetzen ist eine Herausforderung. Wie schafft man es, die Entwicklungs- und Betriebsteam so produktiv wie möglich zu machen? Wie lässt sich der Arbeitsfluss optimieren und wie lassen sich Sicherheit und Skalierbarkeit sicherstellen= Dies ist nur mit den passenden Softwarewerkzeugen möglich!

Bamboo 6.2 kommt mit einer Vielzahl neuer Features, die skaliertes DevOps im Großen möglich machen. Verbesserter Arbeitsfluss und erhöhte Produktivität, Skalierbarkeit um Continuous Integration der gesamten Organisation zur Verfügung zu stellen – all das macht Bamboo 6.2 möglich.

DevOps skalieren mit Bamboo

Die Praktiken von DevOps aus dem Konzeptionellen ins Praktische zu überführen ist für sich genommen schon schwierig genug. Nimmt man jetzt noch die Herausforderungen dazu, die große Unternehmen bei der flächendeckenden Einführung von DevOps zu bewältigen haben, gilt es einen ganzen Berg zu überwinden. Klar lässt sich mit Bitbucket Server die Ecke Versionskontrolle abhaken – aber was ist mit der Buildpipeline, Continuous Integration und Continuous Delivery?

Was tun, wenn Ihre Entwicklungsteams mehr Buildartefakte erzeugen als Ihre CI/CD-Lösung verwalten kann? Oder so viele parallele Builds laufen, dass Sie stets am Rande Ihrer Kapazität sind?Oder Sie so viele Buildpläne zu verwalten haben, dass die Berechtigungen zum Problem werden. Mit Bamboo 6.2 präsentiert Atlassian eine Antwort auf genau diese Fragen

Bamboo Specs für Bitbucket Server

Änderungen an Plänen lassen sich mit Bamboo Specs (Configuration as Code) schneller und im Bulk erledigen. Bamboo 6.2 liefert Bamboo Specs für Bitbucket Server aus und somit die Fähigkeit, ein Spec File in einem verlinkten Bitbucket Server Repository abzulegen.

Änderungen an in Bitbucket Server abgelegten Spec-Dateien werden automatisch an Ihre Bamboo Builds übertragen. So spart man Zeit, da Entwicklungspipeline und Codebasis gleichzeitig aktualisiert werden können. Man erhält beim Speichern von Specs in Git & Bitbucket die Vorteile einer Versionsverwaltung inklusive Code Reviews und der Möglichkeit, Änderungen jederzeit rückgängig zu machen. Das bedeutet: Buildpläne höherer Qualität und schnellere Änderungen.

Unterstützung von Smart Mirrors in Bamboo

Für verteilt arbeitende Teams sind Smart Mirrors eine große Zeitersparnis. Es lassen sich viele Stunden unproduktiver Zeit einsparen, wenn dank Smart Mirroring Repositories in geographischer Nähe zu den Teams geklont werden können. Diese Zeitoptimierung gibt es nun auch bei Builds. Dazu einfach einen Spiegelserver auswählen, wenn man in Bamboo ein integriertes Bitbucket-Repository auswählt und Bamboo kümmert sich um den Rest. Selbst bei Hosting in Co-Location-Infrastrukturen lässt sich so ein spürbarer Unterschied feststellen und Lastspitzen besser verteilen.

Berechtigungen auf Projektebene

Mit Bamboo 6.2 wird eine neue Rolle eingeführt: der Projektadministrator. Im Zuge dessen können Berechtigungen in Bamboo von nun an auch auf Projektebene angewandt werden.

Bamboo-Administratoren können so einige ihrer Verpflichtungen an diejenigen delegieren, die für die eigentlichen Projekte verantwortlich sind oder allgemeine Berechtigungen über mehrere Buildpläne hinweg setzen. Dies vereinfacht die Verwaltung von Bamboo-Instanzen mit sehr vielen Nutzern und kommt Organisationen mit strengen Richtlinien für Regulation und Sicherheit entgegen

Plan-Erstellen-Berechtigung

Die globale “Plan Erstellen”-Berechtigung heißt nun “Erstellen” und ermöglicht es, leere Projekte zu erstellen. Zusätzlich dazu lassen sich mittels der “Erstellen”-Berechtigung auf Projektebene neue Pläne erstellen, selbst wenn man die globale Erstellen-Berechtigung nicht besitzt.

Die bereits existierenden Berechtigungen auf Plan-Ebene (Anzeigen, Editieren, Bauen, Schließen, Administrieren) können von nun an auf Projektebene gesetzt werden und damit für alle Pläne eines Projektes übernommen werden. Sie können diese Berechtigungen selbstverständlich auf Plan-Ebene individuell anpassen.

Berechtigungen sind additiv

Sobald Berechtigungen auf einer Ebene gesetzt worden sind, werden diese auf die niedrigeren Ebenen vererbt. Sie können keine Berechtigungen auf einer niedrigeren Ebene überschreiben oder entfernen. Ein Beispiel: Besitzen Sie die “Erstellen”-Berechtigung auf globaler Ebene, können Sie auf allen Ebenen (Global, Projekt, Pläne ..) Pläne erstellen. Falls Sie die “Build”-Berechtigung auf der Ebene eines bestimmten Projektes besitzen, aber keine explizit für einen Plan innerhalb des Projektes, so sind Sie trotzdem dazu in der Lage, den Build dieses Planes anzustoßen.

Projektmenü

Das neue Projektmenü namens Projects listet alle verfügbaren Projekte mit ihren Kürzeln, Namen und Beschreibungen auf.

Diese Projektliste ist zusammen mit den Projektdetails für alle Nutzer zugänglich, die Zugriff auf Bamboo haben – auch anonyme Nutzer, wenn anonymer Zugriff aktiviert ist.

Skalieren im großen Stil

Bamboo 6.2 führt neue Artifact Handler und Proxies für das Bootstrapping von Agents ein. Beide Neuerungen dienen dazu, die Last eines Bamboo-Servers zu reduzieren und die Fähigkeit zur Skalierung zu erhöhen. Die neuen Optionen zur Ablage von Build-Artefakten sind Amazon S3 und NFS, womit sich das Archivieren von Binärdateien auf für die Datenablage spezialisierte Lösungen auslagern lässt. Ganz ähnlich agieren Agent Proxies, indem diese Abhängigkeiten eines Agents in einem Cache zur Verfügung stellen und somit schneller abrufbar machen.

Diese beiden neuen Features ermöglichen mehr Builds, gleichzeitige Prozesse und Code Releases. Atlassian hat es sich zur Mission gemacht, alle Organisationen jeglicher Größe in die Lage zu versetzen, auf moderne CI-Praktiken zu bauen. Die Vorteile von Tests und Automatisierung für Ihr Unternehmen lassen sich nicht verleugnen. Schnellere Releasezyklen, Code von höherer Qualität und Entwicklungsteams mit mehr Autonomie sind Gamechanger in Ihrem Business. Aus diesem Grund fokussiert sich Atlassian darauf, Bamboo skalierbar zu machen und wird dies auch weiter tun.

Lizenzen für 500 und 1000 Agents

Für die Kunden, die bereits an den Grenzen ihrer CI/CD-Server kratzen, kündigt Atlassian auch ein Preisupdate für neue 500- und 1000-Build Agent-Lizenzen in Bamboo an. Mit 1000 Build Agents reduziert sich die Warteschlangenlänge und mehr Prozesse können parallel ablaufen, was wiederum dafür sorgt, dass Sie mehr Code schneller ausliefern können. Atlassian verspricht, dass die neuen Lizenzstufen bald verfügbar sein werden.

Quellen & Links:

• Atlassian Bamboo 6.2 Release Notes
• Atlassian Blog

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Partner für Sie da.

• Weitere Information erhalten Sie auf den Braintime-Seiten zu Bamboo Server.
• Sie interessieren sich für eine Demo oder Lizenz von Bamboo? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt

Atlassian hat die Veröffentlichung von Bitbucket Server 5.4 bekannt gegeben. Fokus der vorliegenden Version ist die Optimierung des Arbeitsflusses.

Mit Webhooks Bitbucket in Ihre DevOps-Toolchain integrieren

Eines der drei Grundprinzipien von DevOps ist der Flow, ein Schlüsselelement um Entwicklungsrisiken zu minimieren und Releasezyklen zu verkürzen. Für den Flow zu optimieren bedeutet zu verstehen, wie sich Änderungen durch Systeme bewegen, wie Teams mit diesen Informationen umgehen und wie schnell Daten von A nach B gelangen können.

Hier denkt man vielleicht zuerst an eine Build Pipeline – wie Bamboo sie liefert – aber es geht um mehr, es geht um den gesamten Ablauf der Entwicklung. Durch Webhooks in Bitbucket Server 5.4 ist es noch einfacher, Werkzeuge von Drittanbietern zu integrieren, die Ihre DevOps-Toolchain bilden. Webhooks sind über das Bitbucket User Interface bis auf Repository-Ebene konfigurierbar. Falls Sie eine eigene Lösung für die Aufgabenverwaltung benutzen, können Webhooks für bestimmte Events ausgelöst werden.

Für die folgenden Events lassen sich Webhooks erstellen:

• Push in ein Repository
• Änderung an einem Repository
• Pull Request geöffnet, gemerged, abgelehnt oder gelöscht
• Pull request Status auf Approved, Unapproved oder Needs-Work gesetzt
• Kommentare zu Commits hinzugefügt, geändert oder gelöscht

Mit Webhooks lassen sich externe Werkzeuge mit Bitbucket Server integrieren. Gängige Szenarien dafür sind unter anderem:

• Ein Webhook, der ausgelöst wird, wenn ein Benutzer einen Commit in ein Repository pusht. Darüber kann z.B. ein Continuous Integration-Server über die Änderung informiert werden und einen Build auslösen
• Ein Webhook, der ausgelöst wird, wenn ein Benutzer Pull Requests erstellt. Darüber kann z.B. eine Benachrichtung in Ihrer bereits existierenden Kommunikationslösung ausgelöst werden

Atlassian stellt eine umfangreiche Dokumentation zu Webhooks zur Verfügung.

Die Mitarbeit an Repositories einfacher machen

Es ist mit Bitbucket Server 5.4 möglich, einem Repository eine Markdown-Datei mit Richtlinien für die Mitarbeit (Contribution guidelines) hinzuzufügen.

Diese Datei bzw. ein Link dorthin wird dann in den Dialogen zu Clone-Operationen sowie der Erstellung und Anzeige von Pull Requests angezeigt.

Unterstützung für GVFS in Bitbucket Server

Microsoft hat vor einiger Zeit ein neues Open Source-Projekt veröffentlicht, welches im Konzern intern zur Verbesserung der Produktivität im Umgang mit sehr großen monolithischen Codebases in Git entwickelt wurde. Das so entstandene GVFS (Git Virtual File System) virtualisiert das Dateisystem eines Git-Repositories auf Entwicklermaschinen unter Windows. Indem nur Dateien synchronisiert werden, auf die auch tatsächlich zugegriffen wird, lassen sich Rechenleistung, Speicherplatz und Bandbreite einsparen.

Atlassian hat dieselbe Problematik in der eigenen Entwicklungsabteilung beobachtet und die Ankündigung von GVFS hat schnell dafür gesorgt, dass der hauseigene Git-Client für den Desktop, SourceTree, GVFS unterstützt. SourceTree unterstützt das Git Virtual File System auf unterstützten Hosts wie z.B. Windows mit Visual Studio Team Services. Mit Bitbucket Server 5.4 hat Atlassian die Unterstützung von GVFS angekündigt – vorerst als experimentelles Addon. Das Addon für Bitbucket Server und Data Center stellt die serverseitige Unterstützung für GVFS zur Verfügung und erleichtert so den Umgang mit sehr großen Git-Repositories.

Das Addon ist im Atlassian Marketplace verfügbar.

Bitbucket Server & Data Center 5.4 verändern und erleichtern dank der tiefgreifenden Integrationen Ihren Arbeitsalltag. Kommen Sie dazu einfach auf uns zu.

Das interessiert Sie?

Dann sind wir als Atlassian Platinum Solution Partner Enterprise für Sie da.

• Weitere Information zu DevOps & Enterprise erhalten Sie auf den Braintime-Seiten zu Continuous Delivery.
• Sie interessieren sich für eine Demo oder Lizenz von Atlassian-Produkten? Dann kontaktieren Sie uns unverbindlich noch heute.
• Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.

Kontakt