zetapush / zetapush-next-open-specification

Open specification for Next ZetaPush version
0 stars 0 forks source link

Fonctionnel commande : zeta push #52

Closed damienld22 closed 6 years ago

damienld22 commented 6 years ago

Objectif

Le but de cette issue est de spécifier le fonctionnement de la commande zeta push. Le point de vue fonctionnel pour le développeur sera mis en avant mais différents éléments techniques seront présentés par moment pour s'assurer de la bonne compréhension de chacun.

But de la commande

Déploiement du code du développeur. À la fois le code front et le code back

Paramètres de la commande

La commande standard est : zeta push

Process de lecture de la configuration

Liste et nommage des données à rechercher :

Variables d'environnement à spécifier : #42

ZP_FRONT : Chemin du code front
ZP_BACK : Chemin du code back
ZP_LOGIN : Login du développeur de son compte ZetaPush
ZP_PASSWORD : Mot de passe du développeur de son compte ZetaPush
ZP_NAME : Nom de l'application (identification unique d'une application sur un compte défini)
ZP_URL : URL de l'API (Utile seulement en interne ZetaPush)

Lors d'un déploiement, la CLI cherche la configuration a utiliser (Configuration de compte ou configuration de l'application). Voici le processus (Chaque configuration trouvée écrase la donnée précédente) :

  1. Recherche dans les variables d'environnement
  2. Recherche dans le fichier .zetarc du HOME du développeur
  3. Recherche dans le fichier .zetarc du dossier courant de l'application
  4. Recherche dans le package.json en utilisant la syntaxe suivante :
{
    "zetapush": {
        "name" : "myApp",
        "url" : "http://hq.zpush.io:9080/zbo/pub/business/",
        "front" : "./front",
        "server" : "./server",
        "login" : "user@gmail.com",
        "password" : "password"
    },
}

Details

Sortie de la console

Dans un cas complet, voici la sortie de la console suite à un déploiement avec zeta push.

Deploying your application on production environment:
      ✓ Code uploaded
      | Publishing custom services on node 1   ██████░░░░░░
      - Publishing custom services on node 2   ████████░░░░
      / Publishing custom services on node 3   ██░░░░░░░░░░

Et lorsque tout est prêt :

Deploying your application on production environment:
      ✓ Code uploaded
      ✓ Custom services published on node 1
      ✓ Custom services published on node 2
      ✓ Custom services published on node 3

Your custom services are ready and accessible through ZetaPush and your application is available on : https://zetapush.apps.com/myApp/oidjhoh
aurelien-baudet commented 6 years ago

Je reprends ce qui avait été mis dans la #41 :


Voici une première proposition du fonctionnement de zeta push :

Pré-requis

Push sans distinction

zeta push

Push en déployant seulement le front

zeta push --front-only

Push en déployant seulement le code server

zeta push --server-only

Push en spécifiant les chemins de chaque partie

zeta push --front /path/to/front --back /path/to/back

Push en déployant seulement le front avec un path spécifié

zeta push --front-only /path/to/front

Push en déployant seulement le code server avec un path spécifié

zeta push --server-only /path/to/back

ghoullier commented 6 years ago

Questions

La proposition actuelle sur les paramètres de la CLI ne permet pas de deployer plusieurs front et plusieurs back. Est ce qu'on se limite à un pour le moment?

Ne serait-il pas plus simple de merger --front et --front-only ainsi que --server et --server-only? Si on met --front ça déploie le front, si on met --server ça déploie le server, si on met les 2 ça déploie les 2.

damienld22 commented 6 years ago

@ghoullier

Pour l'instant je pense qu'il faut se limiter au déploiement d'un seul front et d'un seul back.

Le fait de merger les 2 implique que dans le cas où nous voulons seulement forcer un path mais quand même publier le front et le back nous sommes obligé de faire :

zeta push --front ./static/front --back ./server

Alors que ne pas merger les deux paramètres nous permet d'écrire :

zeta push --front ./static/front

Je pense que chaque façon de faire a ses inconvénients, à voir ce qui est le plus courant

damienld22 commented 6 years ago

zeta push

Déploie le code du développeur sur la plateforme zetapush Fait un register si besoin

zeta push sans paramètre ET SANS fichier de conf déploiement les valeurs de convention

zeta push sans paramètre ET AVEC fichier de conf déploiement tout ce qui est configuré dans le fichier package.json/.zetarc

zeta push avec paramètre ne déploie que ce qui est indiqué via les paramètres