Agence logicielle · Delivery
Publication d'une app mobile sur les stores
Faites passer la mise à jour de l'app d'un client en revue des stores sans surprise de dernière minute. Le client fournit les éléments de la fiche et les accès à ses comptes via un lien public, et rien n'est soumis avant que le responsable technique approuve la version et que le client approuve les notes.
- Durée: 1 à 2 semaines
- Fréquence: Pour chaque publication sur les stores
- Étapes: 10 étapes
- Agents IA: 1 agent IA
- Approbations: 1 approbation
Plan gratuit, sans carte de crédit.
Ce que ce modèle change
Sans le modèle
L'app est sur le compte développeur de l'agence, et la transférer plus tard est pénible.
Captures, réponses de confidentialité et textes arrivent la veille de la soumission.
Un rejet n'apparaît que lorsque le client demande pourquoi la mise à jour n'est pas en ligne.
Les notes de version sont écrites à la hâte par la personne qui soumet.
Avec le modèle
Les comptes du client sont utilisés dès la première publication, avec votre équipe invitée.
Le client partage les éléments de la fiche et les réponses de confidentialité dès le début, via un seul lien.
Un rejet bloque l'exécution, avec son motif, jusqu'à la nouvelle soumission de la version corrigée.
Un agent IA les rédige, le responsable technique les corrige et le client les approuve.
Le modèle, étape par étape
Chaque étape indique qui la réalise : une personne de votre équipe, un agent IA ou le client via un lien public. Une approbation garde toutes les étapes suivantes verrouillées jusqu'à ce qu'elle soit donnée.
- Réalisé par votre équipe
- Réalisé par un agent IA
- Réalisé par le client, via un lien public
Démarre quand
Une version de l'app mobile d'un client est prête à publier. Le chef de projet lance une exécution avec le nom de l'app, la version et la date de publication prévue.
- 1
Planifier la publication et partager le lien
Jour 1Chef de projet · Équipe
Convenez de ce qui entre dans la version, renseignez les informations de publication et envoyez au client le lien public avec ce dont les stores ont besoin de sa part.
Checklist
- Contenu de la version convenu
- Lien public envoyé au client
Champs à remplir
- Nom de l'app (obligatoire)
- Version (obligatoire)
- Date de publication prévue (obligatoire)
- 2
Le client fournit les éléments des stores et les accès
Jours 1 à 3Product owner du client · Lien public
Via le lien public, le client confirme que l'app est publiée sous ses propres comptes développeur, y invite l'équipe et partage ce dont les fiches des stores ont besoin.
Checklist
- Équipe invitée sur le compte développeur Apple
- Équipe invitée sur la Google Play Console
- Questions de confidentialité et de sécurité des données traitées
Champs à remplir
- Fonctionnalités à mettre en avant (obligatoire)
- Lien vers la politique de confidentialité (obligatoire)
- E-mail du support (obligatoire)
- Lien vers les nouvelles captures
- 3
Construire la version candidate
Jours 2 à 5Développeur mobile · Équipe
Construisez la version candidate signée avec les bons numéros de version et de build, et distribuez-la sur les appareils de test.
Checklist
- Numéros de version et de build réglés
- Signée avec les certificats du client
- Distribuée sur les appareils de test
Champs à remplir
- Numéro de build (obligatoire)
- Lien vers la version de test (obligatoire)
- 4
Tester sur de vrais appareils
Masqué sur le lien publicJours 4 à 7Ingénieur QA · Équipe
Testez la version candidate sur les appareils et versions de système pris en charge, y compris la mise à jour depuis la version en ligne aujourd'hui.
Checklist
- Testée sur le système le plus ancien pris en charge
- Mise à jour depuis la version en ligne testée
- Règles des stores vérifiées
- Aucun plantage au démarrage
Champs à remplir
- Lien vers le rapport de test (obligatoire)
- Problèmes connus
- 5
Rédiger les notes de version pour les stores
Jour 7Rédacteur de notes pour les stores · Agent IA
Le rédacteur de notes pour les stores rédige les notes de version des deux stores à partir des fonctionnalités que le client veut mettre en avant et des problèmes connus, dans les limites de longueur de ses instructions.
Champs à remplir
- Brouillon des notes de version (obligatoire)
Contrôle humain: Le responsable technique corrige les notes et approuve la version à l'étape 6.
- 6
Approuver la version pour la soumission
Jour 8Responsable technique · Équipe
Lisez le rapport de test et les problèmes connus, corrigez les notes de version, approuvez la version et envoyez les notes définitives au client par e-mail.
Checklist
- Rapport de test lu
- Notes de version corrigées
- Le numéro de build correspond à la version testée
Approbation: L'approbation du client et la soumission aux stores restent verrouillées jusqu'à ce que le responsable technique approuve la version.
- 7
Le client approuve les notes et la date
Jours 8 à 9Product owner du client · Lien public
Le client lit les notes de version envoyées par le responsable technique et enregistre via le lien public sa décision et la date à laquelle la version peut passer en ligne.
Champs à remplir
- Décision (obligatoire)
- Mise en ligne le (obligatoire)
- Modifications du texte
- 8
Soumettre à la revue des stores
Jour 9Développeur mobile · Équipe
Soumettez la version approuvée et ses notes aux deux stores, réglez la publication en manuel ou progressive et notez la date de soumission.
Checklist
- Soumise à l'App Store
- Soumise à Google Play
- Publication réglée en manuel ou progressive
Champs à remplir
- Soumise le (obligatoire)
- 9
Traiter le résultat de la revue
Jours 9 à 12Développeur mobile · Équipe
Enregistrez le résultat de chaque revue. Si un store rejette la version, marquez l'exécution comme bloquée, notez le motif et soumettez à nouveau après la correction.
Champs à remplir
- Résultat de la revue App Store (obligatoire)
- Résultat de la revue Google Play (obligatoire)
- Motif du rejet
- 10
Publier et vérifier que la version est en ligne
Semaine 2Chef de projet · Équipe
Publiez la version à la date convenue, vérifiez qu'elle s'installe depuis les deux stores et prévenez le client.
Checklist
- En ligne sur les deux stores
- S'installe et s'ouvre depuis le store
- Rapports de plantage vérifiés après la publication
- Client prévenu
Champs à remplir
- En ligne depuis le (obligatoire)
Terminé quand
La version est en ligne sur les deux stores, sous les comptes développeur du client, et la publication est enregistrée sur l'exécution.
Adaptez-le. Renommez les étapes, changez les responsables et ajoutez des points de checklist, des champs ou des approbations. Le modèle est un point de départ pour la façon de travailler de votre équipe.
Les agents IA de ce modèle
Un agent ne travaille que sur ses propres étapes, et une personne de votre équipe vérifie ce qu'il a fait. Tout ce qu'un agent écrit dans une application connectée attend une approbation, sauf si vous l'autorisez.
Rédacteur de notes pour les stores
Rédige les notes de version des deux stores à partir de ce qui a changé dans cette version.
Ce qu'il fait
- Lit les fonctionnalités que le client veut mettre en avant et les problèmes connus
- Rédige des notes de version courtes pour les utilisateurs
- Respecte les limites de longueur de ses instructions
- Termine son étape pour que le responsable technique puisse relire
Contrôle humain: Le responsable technique corrige les notes et approuve la version à l'étape 6.
Les questions auxquelles ce modèle répond
Publiez sous les comptes développeur du client avec votre équipe invitée, et ne soumettez qu'une version testée et approuvée. À l'étape 2, le client invite l'équipe et répond aux questions de confidentialité via le lien public, et à l'étape 8 le développeur mobile soumet la version approuvée.
Sur celui du client, pour qu'il garde l'app, ses notes et ses utilisateurs si vous vous séparez un jour. L'étape 2 demande au client de confirmer ses propres comptes et d'inviter votre équipe avant la première version destinée à la publication.
Testez sur le système d'exploitation le plus ancien que vous prenez en charge, testez la mise à jour depuis la version en ligne et vérifiez les règles des stores qui mènent aux rejets. L'étape 4 contient cette checklist pour l'ingénieur QA, avec un lien vers le rapport de test.
Notez le motif, corrigez et soumettez à nouveau, et prévenez le client au lieu de laisser la date glisser en silence. À l'étape 9, le développeur mobile marque l'exécution comme bloquée avec le motif du rejet jusqu'à la nouvelle soumission de la version corrigée.
Laissez l'IA rédiger les notes de version des deux stores à partir de ce qui a changé, et gardez l'approbation de la version dans votre équipe. Le rédacteur de notes pour les stores rédige le texte à l'étape 5, et l'étape 6 est un contrôle d'approbation où le responsable technique le corrige et approuve la version.
Soumettez tôt, réglez la publication en manuel ou progressive, et publiez à la date convenue avec le client. À l'étape 7 le client fixe la date, à l'étape 8 le développeur mobile soumet avec une publication manuelle ou progressive, et à l'étape 10 la version passe en ligne.
Exécutez ce workflow dans OKiDO
Configurez les étapes, les responsables et les approbations une fois, puis lancez une exécution pour chaque nouveau cas.