Cette page a été traduite par l'API Cloud Translation.

Recommandations de mise à niveau

Cette page décrit les recommandations de mise à niveau vers de nouvelles versions à partir de Cortex Framework Data Foundation personnalisée. À chaque version, l'équipe Cortex s'engage à minimiser les perturbations tout en ajoutant de nouvelles fonctionnalités à Cortex Framework. Les nouvelles mises à jour donnent la priorité à la rétrocompatibilité. Toutefois, ce guide vous aide à minimiser les problèmes potentiels.

La fondation de données Cortex Framework fournit un ensemble de contenus et de modèles prédéfinis pour accélérer la valeur des données répliquées dans BigQuery. Les organisations adaptent ces modèles, modules, scripts SQL et Python, pipelines et autres contenus fournis en fonction de leurs besoins.

Composants principaux

Le contenu de la fondation de données Cortex Framework est conçu selon un principe d'ouverture. Les organisations peuvent utiliser les outils qui leur conviennent le mieux lorsqu'elles travaillent avec les modèles de données BigQuery fournis. La seule plate-forme sur laquelle la fondation est étroitement dépendante est BigQuery. Tous les autres outils peuvent être interchangeables si nécessaire:

Intégration des données:vous pouvez utiliser n'importe quel outil d'intégration interconnecté à BigQuery, à condition qu'il puisse répliquer des tables et des structures brutes. Par exemple, les tables brutes doivent ressembler au même schéma qu'elles ont été créées dans SAP (mêmes noms, champs et types de données). En outre, l'outil d'intégration doit pouvoir fournir des services de transformation de base, tels que la mise à jour des types de données cibles pour la compatibilité avec BigQuery, ainsi que l'ajout de champs supplémentaires tels qu'un code temporel ou un indicateur d'opérations pour mettre en évidence les enregistrements nouveaux et modifiés.
Traitement des données:les scripts de traitement de la capture de données modifiées (CDC, Change Data Capture) sont facultatifs. Ils permettent de travailler avec Cloud Composer (ou Apache Airflow). À l'inverse, les instructions SQL sont produites séparément des fichiers spécifiques à Airflow dans la mesure du possible, afin que les clients puissent utiliser les fichiers SQL distincts dans un autre outil si nécessaire.
Visualisation des données:bien que des modèles de tableau de bord Looker soient fournis et contiennent des visualisations et une logique minimale, la logique de base reste disponible dans la base de données de BigQuery par conception pour créer des visualisations avec l'outil de création de rapports de leur choix.

Principaux avantages

Cortex Framework Data Foundation est conçu pour s'adapter à divers besoins métier. Ses composants sont conçus avec flexibilité, ce qui permet aux organisations d'adapter la plate-forme à leurs besoins spécifiques et de bénéficier des avantages suivants:

Ouverture: s'intègre parfaitement à divers outils d'intégration, de traitement et de visualisation des données en plus de BigQuery.
Personnalisation:les organisations peuvent modifier et développer des composants prédéfinis tels que des vues SQL pour les adapter à leurs modèles de données et à leur logique métier.
Optimisation des performances:des techniques telles que le partitionnement, les vérifications de la qualité des données et le clustering peuvent être ajustées en fonction des charges de travail et des volumes de données individuels.
Rétrocompatibilité:Cortex s'efforce de maintenir la rétrocompatibilité dans les futures versions, ce qui réduit les perturbations pour les implémentations existantes. Pour en savoir plus sur les modifications de version, consultez les notes de version.
Contribution à la communauté:encourage le partage de connaissances et la collaboration entre les utilisateurs.

Mise à jour d'un processus

Les sections suivantes présentent une méthode permettant aux développeurs de mettre à jour leur code avec le dépôt Cortex Framework Data Foundation tout en conservant leurs personnalisations. Utilisation des scripts de déploiement pré-livrés dans les pipelines CI/CD. Toutefois, les organisations peuvent utiliser d'autres outils et méthodologies en fonction de leurs préférences, comme Dataform, ou les outils d'automatisation fournis par les différents hébergeurs Git, comme les actions GitHub.

Configurer le dépôt

Cette section présente une approche de configuration de votre dépôt. Avant de suivre ces étapes, nous vous recommandons de bien comprendre Git.

Fork du dépôt principal : créez un fork du dépôt de la fondation de données Cortex Framework. Le fork permet à ce dépôt de recevoir les mises à jour du dépôt Google Cloud et un dépôt distinct pour le dépôt principal de l'entreprise.
Créer un dépôt d'entreprise: créez un hôte Git pour le dépôt de votre entreprise (par exemple, Cloud Source). Créez un dépôt portant le même nom que votre dépôt dérivé sur le nouvel hôte.
Initialiser le dépôt de l'entreprise: copiez le code de votre dépôt dérivé dans le dépôt de l'entreprise que vous venez de créer. Ajoutez le dépôt d'origine du fork en tant que dépôt distant en amont avec la commande suivante, puis vérifiez que le dépôt distant a été ajouté. Cela permet d'établir une connexion entre le dépôt de votre entreprise et le dépôt d'origine.
```
git remote add google <<remote URL>>
git remote -v
git push --all google
```
Vérifier la configuration du dépôt: assurez-vous que le dépôt de votre entreprise contient le code et l'historique clonés. Vous devriez voir les deux télécommandes, l'origine et celle que vous avez ajoutée après avoir exécuté la commande:
```
git remote -v:
```
Vous disposez désormais du dépôt, le dépôt de l'entreprise, où les développeurs peuvent envoyer leurs modifications. Les développeurs peuvent désormais cloner et travailler dans les branches du nouveau dépôt.

Fusionner vos modifications avec une nouvelle version de Cortex

Cette section décrit le processus de fusion des modifications apportées au répertoire de l'entreprise et celles provenant du référentiel Google Cloud .

Mettre à jour les fourchettes: cliquez sur Synchroniser la fourchette pour mettre à jour les fourchettes de votre dépôt avec les modifications apportées au dépôt Google Cloud . Par exemple, les modifications suivantes sont apportées au dépôt de l'entreprise. D'autres modifications ont été apportées au dépôt Data Foundation par Google Cloud dans une nouvelle version.
- Création et utilisation d'une nouvelle vue en SQL
- Modifications apportées aux vues existantes
- Nous avons remplacé un script entièrement par notre propre logique.
La séquence de commandes suivante ajoute le dépôt de fourchette en tant que dépôt distant en amont pour extraire la version mise à jour à partir de GitHub et extrait sa branche principale en tant que GitHub-main. Ensuite, cet exemple extrait la branche principale du dépôt de l'entreprise dans Google Cloud Source et crée une branche de fusion appelée merging_br.
```
git remote add github <<github fork>>
git fetch github main
git checkout -b github-main github/main
git checkout  main
git checkout -b merging_br
```
Il existe plusieurs façons de créer ce flux. Le processus de fusion peut également se produire dans le fork sur GitHub, être remplacé par un rebasage au lieu d'une fusion, et la branche de fusion peut également être envoyée en tant que requête de fusion. Ces variations du processus dépendent des règles organisationnelles actuelles, de l'étendue des modifications et de la commodité.

Une fois cette configuration en place, vous pouvez comparer les modifications entrantes à vos modifications locales. Nous vous recommandons d'utiliser un outil dans un IDE graphique de votre choix pour voir les modifications et choisir ce qui sera fusionné. Par exemple, Visual Studio.

Il est recommandé de signaler les personnalisations à l'aide de commentaires qui se démarquent visuellement pour faciliter le processus de comparaison.
Démarrez le processus de fusion: utilisez la branche créée (dans cet exemple, la branche est appelée merging_br) pour converger toutes les modifications et supprimer les fichiers. Lorsque vous êtes prêt, vous pouvez fusionner cette branche dans la branche principale ou une autre branche du dépôt de votre entreprise pour créer une demande de fusion. À partir de cette branche de fusion qui a été extraite de la branche principale (git checkout merging_br) du dépôt de votre entreprise, fusionnez les modifications entrantes de la fourchette distante.
```
    ## git branch -a
    ## The command shows github-main which was created from the GitHub fork
    ## You are in merging_br

    git merge github-main

    ## If you don't want a list of the commits coming from GitHub in your history, use `--squash`
```
Cette commande génère une liste de conflits. Utilisez la comparaison graphique des IDE pour comprendre les modifications et choisissez entre actuel, entrant et les deux. C'est là que l'ajout d'un commentaire dans le code concernant les personnalisations s'avère utile. Vous pouvez choisir de supprimer complètement les modifications, de supprimer les fichiers que vous ne souhaitez pas fusionner du tout et d'ignorer les modifications apportées aux vues ou aux scripts que vous avez déjà personnalisés.
Fusionner les modifications: une fois que vous avez décidé des modifications à appliquer, vérifiez le résumé et effectuez un commit avec la commande:
```
    git status
    ## If something doesn't look right, you can use git rm or git restore accordingly
    git add --all #Or . or individual files
    git commit -m "Your commit message"
```
Si vous ne savez pas comment procéder à une étape, consultez Undoing basic things in Git (Annuler des actions de base dans Git).
Test et déploiement: jusqu'à présent, vous ne fusionnez que dans une branche "temporaire". À ce stade, nous vous recommandons d'exécuter un déploiement de test à partir des scripts cloudbuild\*.yaml pour vous assurer que tout s'exécute comme prévu. Les tests automatisés peuvent contribuer à simplifier ce processus. Une fois que cette branche de fusion semble correcte, vous pouvez effectuer un "checkout" de votre branche cible principale et y fusionner la branche merging_br.