ZetaPush Next Open Specification

Ce projet contient l'ensemble des ressources relatives à la prochaine version majeure de ZetaPush (aka Celtia)

Sommaire

• Objectifs
• Vocabulaire
• Schéma de principe
• Developer Experience
• Profils identifiés
• Roadmap
• Je veux du concret : Tutoriel

Objectifs

Objectifs de ZetaPush Celtia

Chez ZetaPush, nous sommes convaincus que le développement logiciel est actuellement trop coûteux et trop long. Les développeurs perdent trop de temps sur des problématiques techniques n'ayant aucune plus-value pour le client final (initialisation du poste de travail, installation, mise en production...). Nous sommes également convaincus que la réussite d'un projet est extrêmement liée à l'ergonomie de l'application (autrement dit, l'utilisateur est au centre de toutes les décisions).

ZetaPush souhaite donc offrir une expérience de développement agréable et efficace pour une productivité accrue. Nous souhaitons que les développeurs se concentrent sur le code utile. Nous souhaitons également que les développeurs se focalisent sur la partie visible de l'iceberg (l'interface utilisateur - UI) dans le but de répondre efficacement aux besoins grandissants d'ergonomie.

Objectifs de ce repository

Ce repository GitHub trace nos réflexions, idées et propositions. Nous utilisons ce repository pour communiquer sur nos avancées. Ce repository est aussi la base pour que nos utilisateurs (vous) puissent aussi contribuer en terme de réflexion, d'idées et de propositions. Ce repository est ouvert à tous ceux qui partagent les mêmes convictions que nous.

Vocabulaire

• ETQ : En tant que
• dev : Terme générique pour dire dev front / back ou fullstack
• ZP : ZetaPush
• credentials : Couple login/password du compte développeur
• cloud service : voir ci-dessous
• cloud function : voir ci-dessous
• custom cloud service : voir ci-dessous
• front : ensemble des fichiers statiques (html, js, css, images...) permettant de fournir une interface web
• worker : ensemble de custom cloud services
• organisation : regroupement logique de comptes développeur
• compte : compte développeur qui utilise la plateforme ZetaPush pour créer/gérer ses applications (s'authentifie en utilisant les credentials)
• application : conteneur logique (regroupant front(s) et worker(s)) qui peut avoir plusieurs environnements
• environnement : une configuration logique d'une application (exemple : "production", "pre-production", "dev")
• sandbox : terme hérité de la version précédente de ZetaPush et amené à disparaître (= un environnement d'une application pour une organisation donnée)
• CLI : outil en ligne de commande simplifiant l'utilisation de ZetaPush
• Plateforme : écosystème fourni par ZetaPush permettant d'héberger le front, le worker d'une application et d'intéragir avec les could services
• console : site web d'administration et de documentation (gestion du compte développeur, des applications, des cloud services, ...)

Services

Afin de bien comprendre les différents services que ZetaPush fournit, petite précision sur le nommage :

Nom	Description
Cloud service	Classe regroupant un ensemble de cloud functions du même domaine fournie par ZetaPush. Par exemple nous avons un cloud service pour le chat, un autre pour la gestion d'utilisateurs...
Cloud function	Méthode d'une classe. Cela correspond à une fonction appelable via un cloud service. Par exemple dans le cloud service de gestion des utilisateurs, nous avons les cloud functions suivantes : createUser() / createOrganization().
Custom cloud service	Correspond exactement à la même chose qu'un cloud service. La seule différence est que c'est le développeur qui l'a créé. Une fois déployé, le custom cloud service est appelable de la même manière qu'un cloud service. Il inclut lui aussi un ensemble de cloud functions que le développeur a défini lui même

À noter que par abus de langage, nous parlerons parfois seulement de service et de function suivant le contexte si cela ne porte pas à confusion.

Schémas de principe

ZetaPush propose un ensemble de cloud services dont l'objectif est de répondre aux usages standards/habituels. Ces services ont pour but de répondre à vos besoins pour la plupart des situations et donc de vous laissez vous concentrer sur la partie UI/UX (interface utilisateur/ergonomie) :

Fournir des services prêts à l'emploi ne suffisent pas toujours. Il existe deux formes de situations non couvertes :

• Vous souhaitez utiliser un cloud service mais celui-ci ne répond que partiellement à votre besoin
• Aucun des cloud services fournis par ZetaPush n'est adapté à l'un de vos besoins spécifiques

Dans le premier cas, nous offrons la possibilité de configurer ou d'étendre les cloud services existants pour les adapter à vos besoins. Dans le second cas, nous vous permettons de développer vos propres custom cloud services.

Au delà de la partie développement de votre application, ZetaPush se charge également de l'hébergement :

ZetaPush n'impose aucun pré-requis technique. Nous souhaitons que vous puissiez utiliser les technologies avec lesquelles vous êtes les plus à l'aise. De même, ZetaPush se refuse d'impacter vos processus de travail mais cherche au contraire à s'adapter à votre workflow de travail.

Parcours utilisateurs

Cette section a pour but de présenter l'ensemble des parcours utilisateurs envisagés dans le cadre de ZetaPush Celtia. Chaque partie correspond à un profil présenté ci-dessous.

Developer experience

: Je développe une application front avec ZetaPush sans custom cloud service

Mon objectif est de réaliser une application rapidement. Je ne veux pas m'occuper de la partie backend, je souhaite me concentrer sur l'IHM uniquement. Les services proposés par ZetaPush correspondent parfaitement aux besoins de mon application (ex: gestion des utilisateurs, stockage de données, chat, ...). Je ne souhaite pas m'occuper de la gestion de mon application en production. Une fois déployée, elle tourne et je ne m'en occupe plus.

• Démarrage
• Cycle de développement
  • Développement de fonctionnalité
  • Debug
  • Faire des tests
• Build
• Deploiement de l'application

: Je développe une application avec ZetaPush et des custom cloud services

Mon objectif est de réaliser une application rapidement. Certains services proposés par ZetaPush correspondent parfaitement aux besoins de mon application (ex: gestion des utilisateurs, stockage de données, chat, ...). Cependant, mon application nécessite une certaine logique métier. Je souhaite donc pouvoir développer rapidement mon code métier. Ce code métier ne peut pas être codé directement dans l'IHM car je souhaite réaliser une application Web, iOS et Android. Il faut donc que ce code métier soit mutualisé (ajout de custom cloud services). Je souhaite que mon code métier soit simple à réaliser et puisse s'appuyer sur les services proposés par ZetaPush (stockage par exemple). Je ne souhaite pas m'occuper de la gestion de mon application en production. Une fois déployée, elle tourne et je ne m'en occupe plus.

• Démarrage
• Cycle de développement
  • Développement de fonctionnalité
  • Debug
  • Faire des tests
• Build
• Deploiement de l'application

: Mon équipe développe une application front avec ZetaPush sans custom cloud service

Je travaille dans une entreprise et nous devons développer une application. L'application peut être développée from scratch mais le coût serait trop élevé. Nous souhaitons développer rapidement et nous concentrer sur l'IHM et ne pas perdre de temps sur la partie backend. Les services proposés par ZetaPush correspondent parfaitement aux besoins de cette application (ex: gestion des utilisateurs, stockage de données, chat, ...). Nous décidons donc d'utiliser ZetaPush pour gérer tout notre backend.

Je ne souhaite pas que ZetaPush nous impose une manière de travailler. Au contraire, je souhaite que ZetaPush s'inscrive dans notre processus de travail habituel : L'équipe de développement développe des fonctionnalités. Nous disposons d'une Intégration Continue pour builder et packager notre application. Ce livrable généré est ensuite transmis à l'équipe d'exploitation pour être déployée en recette, pré-production ou production. Une fois le déploiement de l'application effectué, c'est habituellement cette équipe d'exploitant qui gère la production (monitoring, mises à jour de sécurité, ...). L'équipe d'exploitation souhaite pouvoir connaître la santé de l'application et également avoir des métriques sur les services ZetaPush utilisés (nombre d'appels, nombre de OK, nombre de KO, temps de réponse, ...).

Après quelques mois, l'application tourne correctement. Nous souhaitons l'améliorer et corriger les quelques bugs restants. Une nouvelle équipe prend le relais. Cette nouvelle équipe de développement souhaite pouvoir rapidement remettre un environnement de développement en place. Pour déterminer l'origine de certains bugs, cette nouvelle équipe a besoin d'avoir accès aux logs de la production (les logs de l'IHM et les logs des services ZetaPush).

• Démarrage
• Cycle de développement
  • Développement de fonctionnalité
  • Debug
  • Faire des tests
• Build
• Deploiement de l'application
• Des membres de mon équipe gèrent la production
• Une nouvelle équipe reprend la suite du développement

: Mon équipe développe une application avec ZetaPush et des custom cloud services

Je travaille dans une entreprise et nous devons développer une application. L'application peut être développée from scratch mais le coût serait trop élevé. Nous souhaitons développer rapidement et nous concentrer sur l'IHM et ne pas perdre de temps sur la partie backend. Certains services proposés par ZetaPush correspondent parfaitement aux besoins de notre application (ex: gestion des utilisateurs, stockage de données, chat, ...). Cependant, notre application nécessite une certaine logique métier. Nous souhaitons donc pouvoir développer rapidement notre code métier. Ce code métier ne peut pas être codé directement dans l'IHM carnous souhaitons réaliser une application Web, iOS et Android. Il faut donc que ce code métier soit mutualisé. Nous souhaitons que notre code métier soit simple à réaliser et puisse s'appuyer sur les services proposés par ZetaPush (stockage par exemple). Nous décidons donc d'utiliser ZetaPush pour gérer tout notre backend.

Je ne souhaite pas que ZetaPush nous impose une manière de travailler. Au contraire, je souhaite que ZetaPush s'inscrive dans notre processus de travail habituel : L'équipe de développement développe des fonctionnalités. Nous disposons d'une Intégration Continue pour builder et packager notre application. Ce livrable généré est ensuite transmis à l'équipe d'exploitation pour être déployée en recette, pré-production ou production. Une fois le déploiement de l'application effectué, c'est habituellement cette équipe d'exploitant qui gère la production (monitoring, mises à jour de sécurité, ...). L'équipe d'exploitation souhaite pouvoir connaître la santé de l'application et également avoir des métriques sur les services ZetaPush utilisés (nombre d'appels, nombre de OK, nombre de KO, temps de réponse, ...). L'équipe d'exploitation souhaite aussi pouvoir monitorer et suivre le comportement du code métier (services custom développés). Il faut donc qu'ils puissent avoir accès aux métriques des services custom (nombre d'appels, nombre de OK, nombre de KO, temps de réponse, ...) ainsi qu'un accès aux logs produits par les services custom.

Après quelques mois, l'application tourne correctement. Nous souhaitons l'améliorer et corriger les quelques bugs restants. Une nouvelle équipe prend le relais. Cette nouvelle équipe de développement souhaite pouvoir rapidement remettre un environnement de développement en place. Pour déterminer l'origine de certains bugs, cette nouvelle équipe a besoin d'avoir accès aux logs de la production (les logs de l'IHM et les logs des services ZetaPush).

Une fois que les évolutions sont terminées, nous réutilisons notre Intégration Continue pour builder et packager notre application. L'équipe d'exploitant

• Démarrage
• Cycle de développement
  • Développement de fonctionnalité
  • Debug
  • Faire des tests
• Build
• Deploiement de l'application
• Des membres de mon équipe gèrent la production
• Une nouvelle équipe reprend la suite du développement

Profils identifiés

Ensemble des profils analysés dans le cadre de ZetaPush V3 avec leur nommage dans l'ensemble du projet.

Profil	Nommage	Description	Parcours correspondants
Développeur Front-End	dev front		Parcours 1 : Je développe une application front avec ZetaPush sans service custom Parcours 3 : Mon équipe développe une application front avec ZetaPush sans service custom
Développeur Back-End	dev back	TODO: souhaits et rôle d'un dev backend avec ZetaPush ?	Parcours 2 : Je développe une application avec ZetaPush et des services custom Parcours 4 : Mon équipe développe une application avec ZetaPush et des services custom
Développeur Full-Stack	dev fullstack		Parcours 1 : Je développe une application front avec ZetaPush sans service custom Parcours 2 : Je développe une application avec ZetaPush et des services custom Parcours 3 : Mon équipe développe une application front avec ZetaPush sans service custom Parcours 4 : Mon équipe développe une application avec ZetaPush et des services custom
Opérationnel / Administrateur système	ops	Gestion de la production : déploiement mise à jour monitoring/supervision/alerting
Chef de projet	CP	Visibilité sur l'application : risques (TODO: pouvoir rassurer un chef de projet sur le choix ZetaPush) coûts (TODO: savoir concrètement combien ZetaPush va lui coûter et combien il va économiser) planification/avancement du projet (TODO: lien avec ZetaPush ? Visibilité sur la roadmap ZetaPush ?) analytics (TODO: remonter des métriques pour que le chef de projet puisse savoir comment son application est utilisée : le nombre d'utilisateurs, parcours clients, ...) dashboard projet (TODO: vision complète)
Commercial	commercial	évaluation des risques (TODO: pouvoir rassurer un chef de projet sur le choix ZetaPush) évaluation des coûts (TODO: savoir concrètement combien ZetaPush va lui coûter et combien il va économiser)
CEO	CEO	évaluation des risques (TODO: pouvoir rassurer un chef de projet sur le choix ZetaPush) évaluation des coûts (TODO: savoir concrètement combien ZetaPush va lui coûter et combien il va économiser)
CTO	CTO	évaluation des services proposés (matching avec le besoin fonctionnel)
Client final d'une ESN	client	analytics (TODO: remonter des métriques pour que le chef de projet puisse savoir comment son application est utilisée : le nombre d'utilisateurs, parcours clients, ...) suivi de l'application en production monitoring

Convention de nommage

Dans l'ensemble des spécifications de ce repository, nous allons parler des différentes conventions définies par ZetaPush. Voici la liste correspondante :

Nommage des dossiers dans l'architecture d'une application

Au sein d'une application ZetaPush Celtia, nous préconisons par soucis de bonnes pratiques, de séparer le code front du code back. Le code back étant les différents custom cloud services que vous allez créer pour étendre le fonctionnel de votre application.

Par défaut et par convention le code se trouvera dans 2 dossiers à la racine de l'application : front pour le code front et worker pour le code back.

Nous avons choisi de nommer le dossier du code back worker puisque ce n'est pas réellement du code back même si celui-ci se trouve côté serveur. En effet le worker est le code qui correspond à votre extension des cloud services ZetaPush (vos custom cloud services).

Roadmap

      

       Je développe une application front avec ZetaPush sans custom cloud service

            Démarrage

Hors scope dans 'celtia-alpha-1'

            Développement

Hors scope dans 'celtia-alpha-1'

            Debug

Hors scope dans 'celtia-alpha-1'

            Test

Hors scope dans 'celtia-alpha-1'

            Build

Hors scope dans 'celtia-alpha-1'

            Déploiement

• [P01-DEPLOY01] ETQ dev front je déploie mon application en production
  • Rédiger les specs
  • Implémenter la commande zeta push --front
  • Implémenter l'hébergement du front
  • Gérer les certificats HTTPs
  • Afficher l'URL de déploiement
  • Afficher la progression du déploiement du front
  • Documenter l'option --front (doc + CLI)

      

       Je développe une application avec ZetaPush et des custom cloud services

            Démarrage

• [P02-BOOT01] ETQ dev full-stack je créé une application sans CLI en utilisant mon compte ZetaPush
  • Rédiger les specs
  • Fournir un repository git avec les fichiers de base (README + hello-world)
  • Documenter la mise en place manuelle dans le README.md
  • Documenter la mise en place manuelle
• [P02-BOOT03] ETQ dev full-stack je créé une application avec la CLI
  • Rédiger les specs (renommer les paramètres)
  • Implémenter la commande npm init @zetapush
  • Implémenter l'option --developer-login
  • Implémenter l'option --developer-password
  • Implémenter l'option --platform-url
  • Documenter le démarrage (doc + registry npm)
  • Documenter l'option --developer-login
  • Documenter l'option --developer-password
  • Documenter l'option --platform-url
• [P02-BOOT04] ETQ dev full-stack je créé une application avec la CLI sans compte existant
  • Rédiger les specs
  • Créer le fichier .zetarc avec les variables à remplir (1h)
  • Documenter les variables ZP_DEVELOPER_LOGIN, ZP_DEVELOPER_PASSWORD, ZP_PLATFORM_URL (+documenter la surcharge : 4h)
• [P02-BOOT08] ETQ dev full-stack je créé une application sans CLI et sans compte ZetaPush
  • Rédiger les specs

            Développement

• [P02-DEV01] ETQ dev full-stack je développe et exécute mon code métier
  • Rédiger les specs
  • Renommer la commande zeta run -> zeta run --worker
  • Implémenter la commande zeta run --worker
  • Démarrer et configurer les cloud services demandés
  • Décrire zeta run --worker dans l'aide
  • Documenter la commande zeta run --worker
  • Documenter le développement d'un custom cloud service
  • Documenter l'appel d'un cloud service existant depuis un custom cloud service
  • Documenter l'appel d'un custom cloud service depuis mon front
  • Implémenter les custom cloud services multiple au sein d'un worker
• [P02-DEV07] ETQ dev full-stack je développe et exécute mon code métier sans compte ZetaPush
  • Rédiger les specs
  • zeta run --worker appelle automatiquement zeta register si besoin
  • Rédiger la section "démarrage" du tutoriel
• [P02-DEV09] ETQ dev full-stack je m'enregistre sur ZetaPush
  • Rédiger les specs
  • Implémenter la commande zeta register
  • Décrire zeta register dans l'aide
  • Documenter la commande zeta register
• [P02-DEV10] ETQ dev full-stack je développe et exécute mon code métier organisé par domaine
  • Rédiger les specs
  • Implémenter les custom cloud services multiples au sein d'un worker
  • Documenter le développement de custom cloud services multiples
  • Documenter l'utilisation de custom cloud services multiples

            Debug

Hors scope dans 'celtia-alpha-1'

            Test

Hors scope dans 'celtia-alpha-1'

            Build

Hors scope dans 'celtia-alpha-1'

            Déploiement

• [P02-DEPLOY01] ETQ dev full-stack je déploie mes services custom en production
  • Rédiger les specs
  • Implémenter zeta push --worker
  • Implémenter l'hébergement du worker
  • Afficher la progression du déploiement
  • Documenter l'option --worker
  • Documenter l'utilisation des custom cloud services nouvellement déployés
• [P02-DEPLOY02] ETQ dev full-stack je déploie mon application (front et service custom) en production
  • Rédiger les specs
  • Implémenter zeta push
  • Afficher la progression du déploiement
  • Documenter la commande zeta push
  • Rédiger la section "push" du tutoriel
• [P02-DEPLOY03] ETQ dev je suis aidé lorsque mon application (front et service custom) n'a pas pu être déployé en production
  • Rédiger les specs
  • Implémenter la remontée des informations d'erreur
  • Implémenter la remontée des informations du contexte (logs et autres)
  • Afficher les messages à l'utilisateur
  • Afficher un message d'aide à la résolution
  • Faire un Appendix des erreurs communes
• [P02-DEPLOY11] ETQ dev full-stack je suis aidé lorsque mon worker n'a pas démarré
  • Rédiger les specs
  • Catcher les erreurs de démarrage
  • Afficher un message d'aide à la résolution
  • Faire un Appendix des erreurs communes
• [P02-DEPLOY07] ETQ dev full-stack je déploie mon application (front et service custom) en production sans credentials à disposition
  • Rédiger les specs
  • zeta push appelle automatiquement zeta register si besoin
• [P02-DEPLOY09] ETQ dev full-stack je déploie mon application (front et service custom) en production avec la configuration en ligne de commande
  • Rédiger les specs
  • Implémenter l'option --developer-login
  • Implémenter l'option --developer-password
  • Implémenter l'option --platform-url
  • Implémenter l'option --app-name
  • Implémenter l'option --env-name
  • Documenter l'option --developer-login
  • Documenter l'option --developer-password
  • Documenter l'option --platform-url
  • Documenter l'option --app-name
  • Documenter l'option --env-name
• [P02-DEPLOY10] ETQ dev full-stack je déploie mon application (front et service custom) en production avec une arborescence custom
  • Rédiger les specs
  • Implémenter l'option --front=
  • Implémenter l'option --worker=
  • Documenter l'option --front=
  • Documenter l'option --worker=
• [TUTO] ETQ dev full-stack je suis le tutoriel de déploiement d'une application avec ZetaPush
  • Rédiger le tutoriel
  • Préparer l'application (fichiers statiques)
  • Tester sous Windows/Mac/Linux
  • Mettre le tutoriel en Intégration Continue
• [PLATEFORME] Ajouter un cluster ZetaPush pour la phase alpha
  • Installer les machines
  • Tester le tutoriel sur le cluster
  • Mettre la plateforme celtia en Déploiement Continu

      

Hors scope dans 'celtia-alpha-1'

      

Hors scope dans 'celtia-alpha-1'

---

      

       Je développe une application front avec ZetaPush sans custom cloud service

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

       Je développe une application avec ZetaPush et des custom cloud services

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

TODO

      

TODO

---

      

       Je développe une application front avec ZetaPush sans custom cloud service

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

       Je développe une application avec ZetaPush et des custom cloud services

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

TODO

      

TODO

---

      

       Je développe une application front avec ZetaPush sans custom cloud service

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

       Je développe une application avec ZetaPush et des custom cloud services

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

TODO

      

TODO

---

      

       Je développe une application front avec ZetaPush sans custom cloud service

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

       Je développe une application avec ZetaPush et des custom cloud services

            Démarrage

TODO

            Développement

TODO

            Debug

TODO

            Test

TODO

            Déploiement

TODO

      

TODO

      

TODO

Tutoriels

• Avengers Chat

Fichiers

Certains fichiers générés (par la CLI par exemple) ont toujours le même contenu. Afin d'éviter de se répéter certain de ces fichiers sont présent dans le sous dossier fichiers.