Français
  • A propos du composant BSPK
  • ATL
  • BWEB
  • Historique des versions
  • FAQ

    • Construire une version

    L'écran de build compile votre application, la construit et prépare tout ce qu'une livraison doit contenir. Toutes les questions sont posées avant de commencer ; ensuite le build va jusqu'au bout sans interruption et journalise chaque étape. Vous pouvez donc le lancer et vous occuper d'autre chose.

    L'ouvrir

    Exécutez la méthode BSPK_BUILD. L'écran s'ouvre dans sa propre fenêtre.

    • Le projet doit être interprété : on ne compile pas une application déjà compilée. Que le composant, lui, soit compilé ne gêne pas.
    • L'écran détecte seul s'il construit votre application ou le composant.
    • Les réglages de build sont ceux de 4D (Développement > Construire l'application). Si votre projet n'en a pas encore, un fichier minimal est créé : relisez-le dans ce dialogue de 4D.
    • Le dossier de sortie est celui de ces réglages. S'il n'est pas défini, l'écran vous le demande ; le bouton Choisir… permet d'en changer.

    L'écran

    • La version, sous la forme v<4D>.<majeure>.<mineure> (par exemple v21R.16.3). Le premier segment suit la version de 4D. Les boutons +/− font monter la majeure (la mineure repart à 0) ou la mineure, jamais en dessous de la version trouvée à l'ouverture. Rien n'est écrit avant de cliquer sur Construire.
    • Créer les branches Git de version : proposé seulement si votre projet est dans un dépôt git, coché par défaut. Voir plus bas.
    • Produire l'archive ZIP : coché par défaut.
    • Notariser auprès d'Apple : sous macOS seulement.

    À l'ouverture, l'écran vérifie la version, le dossier de sortie et le dépôt git. Si la branche de la version est déjà prise, il fait monter la mineure jusqu'à la première libre et le signale en jaune.

    Les étapes

    1. Version : le nouveau numéro est écrit dans votre méthode BSPH_VERSION_UPDATES, sur les lignes $vl_DeliveryVersion:= (majeure) et $vl_InternalVersion:= (mineure). Tout ce qui suit sur ces lignes est remplacé : n'y mettez pas de commentaire.
    2. Instantané : l'instantané d'échange du contenu est rafraîchi (sur un poste de développement).
    3. Compilation, puis construction avec les réglages de 4D. En cas d'échec, le journal donne la cause probable.
    4. Copie des dossiers BWEB et Resources dans l'application construite. Les certificats SSL (cert.pem, key.pem) ne sont pas livrés.
    5. Contenu : le paquet de contenu de la version est déposé dans Resources/exchange/work/content-<version>/, pour être appliqué au démarrage de la version livrée (voir La réconciliation du contenu). Si ce paquet ne peut pas être produit, le build s'arrête : aucune livraison sans son contenu.
    6. Composant : il n'est pas embarqué dans l'application (voir ci-dessous).
    7. Nettoyage : APP_PARAMETERS, PREPROD_PARAMETERS et DEV_PARAMETERS* sont retirés ; WEB_PARAMETERS est conservé. Voir Les fichiers de paramètres.
    8. Archive : un zip <Application>_<version>.zip, à côté de l'application, qui contient l'application, l'outil de mise à jour et ses lanceurs (MISE-A-JOUR.cmd, UPDATE.cmd, et leurs équivalents macOS), et un fichier LISEZ-MOI.
    9. Git, si la case est cochée.

    Ces étapes valent pour l'application monoposte (Compiled Database) et pour le serveur (Client Server executable). Pendant le build, la tâche planifiée qui tient l'instantané à jour est suspendue.

    Le composant dans la version livrée

    • Si votre projet déclare le composant comme dépendance GitHub (voir Installer BWEB), rien à faire : 4D le télécharge au premier démarrage de la version livrée.
    • Sinon, le build prépare un dossier composant/ et un fichier environment4d.json qui y renvoie : déposez-y le composant à la main, sous le nom indiqué dans le LISEZMOI. Sans lui, l'application ne démarre pas.

    Git

    • Les modifications en attente dans votre dépôt sont toutes ajoutées (git add .) et commitées sous le message « version <v> » sur la branche courante.
    • Une branche <v> est créée et poussée, puis le dépôt revient sur la branche de départ.
    • L'application compilée est poussée sur une branche <v>C du même dépôt distant. Il faut donc un dépôt distant ; si le dossier de sortie est lui-même dans un dépôt git, rien n'est poussé.
    • En cas d'échec, les boutons Réessayer Git et Ouvrir un terminal apparaissent. Un dossier synchronisé (Dropbox, OneDrive) peut verrouiller .git : le journal le signale.

    Sous macOS

    Le build produit aussi une image disque et, si la case est cochée, la signe et la fait notariser par Apple. Prérequis : les outils Xcode en ligne de commande, un certificat de signature déclaré dans les réglages de build, et un profil de trousseau nommé notary_cred portant vos identifiants Apple. La notarisation peut prendre plusieurs minutes.

    La chaîne macOS n'a pas encore été validée pour une application hôte : testez-la avant de l'utiliser pour une livraison.

    Bon à savoir

    • La version livrée n'a ni fichier de paramètres ni certificat : au premier démarrage d'un nouveau serveur, 4D demande APP_PARAMETERS, et les certificats se posent à la main.
    • Seules l'application monoposte et l'application serveur sont préparées ; l'application cliente et l'« application finale » de 4D ne le sont pas.

    Voir aussi