Comment le travail arrive dans votre dépôt.

Chaque demande devient un ticket dimensionné

Un ingénieur transforme votre demande en tickets, un par fonctionnalité, et donne une taille à chacun : petite, moyenne ou grande. Vous validez chaque ticket, à cette taille, dans votre portail client, le Front Desk. Aucun travail ne commence avant votre validation, et un ticket dont la taille change doit être validé à nouveau.

Chaque fonctionnalité est développée. Il arrive qu’en travaillant sur un ticket, nous trouvions un problème dans sa spécification : un cas que personne n’a décrit, deux règles qui se contredisent, un choix qui ne revient qu’à vous. Nous fermons alors ce ticket avec la raison et en ouvrons un nouveau avec la spécification corrigée ; l’ingénieur lui donne à nouveau une taille et vous le validez avant que le travail commence. Un ticket fermé ne consomme aucun crédit.

Où le travail se fait

Le travail sur un ticket se déroule en deux phases.

1. La fabrication. Notre chaîne de production IA écrit la fonctionnalité, ses tests et sa documentation, et exécute les tests qui la concernent. Cette phase tourne sur notre infrastructure chez Amazon Web Services.
2. Le contrôle. Sur nos propres machines en Thaïlande, la dernière version de votre branche principale est d’abord fusionnée dans le travail. Ensuite, toute votre application est compilée et toute sa suite de tests s’exécute, anciens tests et nouveaux, sur cet arbre fusionné.

Seul un contrôle au vert va plus loin. Un contrôle au rouge n’atteint jamais votre dépôt.

À quoi cela ressemble pendant le travail

Voici le tableau de bord de notre chaîne de production, sur un projet d’exemple. Chaque ticket indique sa taille et ses crédits, où il en est — fabrication, fusion de votre branche principale, contrôle, livré — et sa dernière action. En dessous : le ticket qui attend votre décision, ceux qui ont été livrés avec leurs pull requests, et un ticket fermé, puis spécifié à nouveau.

Comment le travail entre dans votre dépôt

Chaque ticket livré est une pull request vers votre branche d’intégration. Une fois le contrôle au vert, la pull request porte un status check nommé forge/verify, et elle est fusionnée par un merge commit.

• Aucun force-push, aucun commit direct sur votre branche principale.
• Aucun contournement par un administrateur et aucune fusion automatique : chaque fusion passe par votre protection de branche.
• Si votre application n’a pas encore de tests, les premiers tickets les ajoutent, dimensionnés et tarifés comme n’importe quelle autre fonctionnalité.

Votre protection de branche fait loi

Nous demandons un réglage sur votre branche principale : un status check obligatoire, forge/verify, avec l’obligation que la branche soit à jour avant la fusion, appliquée aussi aux administrateurs.

Nous relisons votre protection de branche juste avant chaque fusion. Si elle a changé, nous ne fusionnons pas.

Ce que vous dit chaque livraison

Chaque ticket a une note de livraison dans le Front Desk :

• la pull request, avec un lien ;
• ce qui a été vérifié : la compilation et la suite de tests complète, sur l’arbre fusionné ;
• ce qui a changé : lignes de code, de tests et de documentation ;
• les crédits consommés.

Un ticket fermé affiche sa raison à la place, et ne consomme aucun crédit. Un rapport quotidien résume ce qui a bougé.

Nouvelle application ou application existante

Nouvelle application. Le dépôt reste chez nous pendant le développement de l’application, puis il vous est transféré avec tout son historique.

Application existante. Nous travaillons directement dans votre dépôt, par pull requests, selon les règles ci-dessus. Le code reste simple et standard, pour que n’importe quel développeur puisse le reprendre.

Des questions ?

Écrivez à sales@hikaro-studio.com, ou parlez-nous de votre application : l’ingénieur qui la cadrerait vous répond sous un jour ouvré.