Individuelle Apps · Atlassian Cloud · auf Forge gebaut
Zwei Situationen führen hierher. Eine Migration von Server oder Data Center hat einen Teil, der nicht mitkommt — ein hauseigenes Plugin, ScriptRunner-Skripte in Groovy, eine Marketplace-App, deren Cloud-Edition weniger kann. Oder ein Team, das schon in Atlassian Cloud arbeitet, braucht etwas, das keine Marketplace-App kann. In beiden Fällen bauen wir die Forge-App — oder sagen euch vor Beginn der Entwicklung, dass die Cloud es nicht kann.
Für Solution Partner und Migrationsteams. An diesen dreien bleibt ein Umzug öfter hängen als an den Daten.
Vor Jahren intern gebaut oder von einem Anbieter gekauft, der nie in die Cloud gegangen ist — eine Jira-Workflow-Erweiterung, ein Confluence-Makro, an dem der Prozess des Kunden hängt. Wir bauen als Forge-App nach, was die APIs von Atlassian Cloud zulassen, und sagen klar, welche Teile nicht.
Scripted Listener, Post-Functions und geplante Jobs rufen eine Java-API auf, die es in der Cloud nicht gibt. Manche lassen sich in die Cloud-Edition von ScriptRunner oder in Automation übernehmen — dann sagen wir das. Den Rest setzen wir mit Forge-Triggern, Workflow-Modulen und den REST-APIs neu um.
Die App gibt es in der Cloud, aber genau die Funktion, auf die sich der Kunde verlässt, ist nicht mitgekommen. Eine kleine Begleit-App kann diese Lücke schließen, statt den Umzug aufzuhalten.
Dafür braucht es keine Migration. Wenn die Arbeit in Jira oder Confluence Cloud stattfindet und eine App fehlt, ist es dieselbe Aufgabe.
Ein Vorgangs-Panel, ein eigenes Feld, eine Workflow-Prüfung, ein Dashboard-Gadget, ein Confluence-Makro — gebaut um die Arbeitsweise eures Teams, statt den Prozess an das anzupassen, was eine App zufällig bietet.
Nicht alles gehört auf den Marketplace. Wir bauen private Apps, die per Link auf eurer Instanz installiert werden — so, wie die Enterprise-Edition von Automation Map verteilt wird.
Jira oder Confluence verbunden mit einem eigenen System, ein Bericht, den die Standard-Gadgets nicht hergeben, Daten aus Assets dort, wo Menschen sie sehen müssen. Gebaut auf den APIs von Atlassian Cloud.
Die Apps unten sind unsere und heute auf dem Atlassian Marketplace — für Jira, für Jira Service Management und Feedback for Confluence. Eine individuelle App bekommt dieselbe Entwicklung.
Unsere individuellen Projekte unterliegen Geheimhaltungsvereinbarungen — deshalb stehen auf dieser Seite keine Kundennamen und keine Fallstudien. In einem Gespräch zeigen wir euch, wie ein vergleichbarer Fall angegangen wurde, ohne jemanden zu nennen. MOY Apps auf LinkedIn
Code, der im Prozess von Jira oder Confluence selbst lief, direkter Datenbankzugriff, tiefe Eingriffe in ihre eigenen Oberflächen — das bietet die Cloud nicht. Wir benennen diese Teile im Scoping, vor Beginn der Entwicklung.
Wenn Automation, die Cloud-Edition der App, die ihr schon nutzt, oder eine App auf dem Marketplace — unsere oder eine fremde — die Aufgabe erledigt, sagen wir das. Massenänderungen an Jira-Schemata, Rollen und Feldern etwa kann Bulker schon.
Für Jira, Jira Service Management und Confluence — keine neuen Server- oder Data-Center-Plugins. Forge ist Atlassians Plattform für Cloud-Apps und hält die Daten der App in der Atlassian-Instanz, auf der sie installiert ist.
Daten, Nutzer und Projekte umzuziehen bleibt beim Solution Partner, der sie führt. Wir übernehmen den Teil ohne Cloud-Gegenstück und fügen uns in euren Plan ein.
Ja. Eine Migration ist ein Grund für eine individuelle App, nicht der einzige. Wenn Jira oder Confluence Cloud etwas fehlt, das euer Team braucht, und keine Marketplace-App es bietet, beschreibt es — wir sagen euch, ob Forge es kann.
Mit beiden. Wo ein Solution Partner eine Migration führt, arbeiten wir nach seinem Plan und Zeitplan. Eine Organisation ohne Partner kann sich direkt an uns wenden.
Skript für Skript. Groovy gegen die Java-API von Server läuft in der Cloud nicht. Manche Skripte lassen sich für die Cloud-Edition von ScriptRunner umschreiben oder durch Automation ersetzen; die übrigen setzen wir als Forge-App neu um. Welches wohin gehört, steht im Scoping.
Selten vollständig. Cloud-Apps laufen außerhalb von Jira und Confluence und sprechen über deren APIs mit ihnen — alles, was darauf beruhte, im Produkt selbst zu laufen, muss neu entworfen werden. Oft lässt sich der Bedarf dahinter anders erfüllen; welcher Teil nicht geht, sagen wir vor der Entwicklung.
Das wird je Projekt vereinbart und im Umfang festgehalten: wem der Quellcode gehört, wer die App pflegt und was passiert, wenn Atlassian die Plattform ändert. Sagt uns, welche Regelung ihr braucht.
Das lässt sich einrichten. Wer dem Kunden gegenübersteht, wird je Projekt vereinbart und im Umfang festgehalten — wie Eigentum und Support.
Entweder ein Festpreis für das Projekt oder Abrechnung nach Aufwand, je nach Fall. Eine Preisliste gibt es nicht; das Angebot folgt auf das Scoping und gilt für genau diesen Umfang.
Im Forge Hosted Storage, innerhalb der Atlassian-Instanz, auf der die App installiert ist. Braucht ein Entwurf einen externen Dienst, steht das vor der Entwicklung im Umfang — weil es ändert, was eine Sicherheitsprüfung ansehen muss.
Zwei, drei Sätze reichen für den Anfang. Das Formular legt ein Ticket in unserem Service Desk an, und ein Mensch antwortet innerhalb eines Werktags.