Wie die Arbeit in Ihr Repository gelangt.

Jede Anfrage wird zu einem eingestuften Ticket

Ein Entwickler macht aus Ihrer Anfrage Tickets, eines pro Funktion, und stuft jedes ein: klein, mittel oder groß. Sie geben jedes Ticket in dieser Größe in Ihrem Kundenportal, dem Front Desk, frei. Vor Ihrer Freigabe wird an nichts gearbeitet, und ein Ticket, dessen Größe sich ändert, braucht erneut Ihre Freigabe.

Jede Funktion wird gebaut. Manchmal stoßen wir bei der Arbeit an einem Ticket auf ein Problem in seiner Spezifikation: einen Fall, den niemand beschrieben hat, zwei Regeln, die sich widersprechen, eine Entscheidung, die nur Sie treffen können. Dann schließen wir dieses Ticket mit Begründung und eröffnen ein neues mit der korrigierten Spezifikation; der Entwickler stuft es erneut ein, und Sie geben es frei, bevor die Arbeit beginnt. Ein geschlossenes Ticket verbraucht keine Credits.

Wo die Arbeit stattfindet

Die Arbeit an einem Ticket läuft in zwei Phasen ab.

1. Der Build. Unsere KI-Produktionslinie schreibt die Funktion, ihre Tests und ihre Dokumentation und führt die Tests aus, die sie betreffen. Das läuft auf unserer Infrastruktur bei Amazon Web Services.
2. Das Gate. Auf unseren eigenen Rechnern in Thailand wird zuerst Ihr aktueller Main-Branch in die Arbeit gemergt. Dann wird Ihre ganze App gebaut, und ihre gesamte Testsuite läuft, alte und neue Tests, auf diesem gemergten Stand.

Nur bei grünem Gate geht es weiter. Was am Gate rot wird, erreicht Ihr Repository nie.

So sieht es aus, während es läuft

Das ist das Dashboard unserer Produktionslinie, an einem Beispielprojekt. Jedes Ticket zeigt seine Größe und seine Credits, wo es steht – Build, Merge Ihres Main-Branch, Gate, geliefert – und was es zuletzt getan hat. Darunter: das Ticket, das auf Ihre Entscheidung wartet, die gelieferten mit ihren Pull Requests und eines, das geschlossen und dann neu spezifiziert wurde.

Wie es in Ihr Repository gelangt

Jedes gelieferte Ticket ist ein Pull Request in Ihren Integrations-Branch. Sobald das Gate grün ist, trägt der Pull Request einen Status-Check namens forge/verify, und er wird mit einem Merge-Commit gemergt.

• Kein Force-Push, kein direkter Commit auf Ihren Main-Branch.
• Kein Administrator-Override und kein automatischer Merge: Jeder Merge läuft über Ihre Branch Protection.
• Hat Ihre App noch keine Tests, ergänzen die ersten Tickets sie, eingestuft und bepreist wie jede andere Funktion.

Ihre Branch Protection ist maßgeblich

Wir bitten um eine Einstellung auf Ihrem Main-Branch: einen erforderlichen Status-Check, forge/verify, wobei der Branch vor dem Merge auf dem neuesten Stand sein muss, auch für Administratoren durchgesetzt.

Wir lesen Ihre Branch Protection unmittelbar vor jedem Merge erneut aus. Hat sie sich geändert, mergen wir nicht.

Was Ihnen jede Lieferung sagt

Jedes Ticket hat im Front Desk einen Lieferbericht:

• der Pull Request, mit Link;
• was geprüft wurde: der Build und die vollständige Testsuite, auf dem gemergten Stand;
• was sich geändert hat: Zeilen an Code, an Tests und an Dokumentation;
• die Credits, die es verbraucht hat.

Ein geschlossenes Ticket zeigt stattdessen seine Begründung und verbraucht keine Credits. Ein täglicher Bericht fasst zusammen, was sich bewegt hat.

Neue App oder bestehende App

Neue App. Das Repository liegt bei uns, solange die App entsteht, und wird dann mit seiner vollständigen Historie an Sie übertragen.

Bestehende App. Wir arbeiten direkt in Ihrem Repository, über Pull Requests, nach den Regeln oben. Der Code bleibt schlichter Standardcode, den jeder Entwickler übernehmen kann.

Fragen

Schreiben Sie an sales@hikaro-studio.com oder erzählen Sie uns von Ihrer App: Der Entwickler, der sie planen würde, antwortet innerhalb eines Arbeitstages.