Recommandations de mise à niveau

Cette page décrit les recommandations pour passer aux nouvelles versions à partir de la Data Foundation de Cortex Framework personnalisée. À chaque version, l'équipe Cortex s'engage à minimiser les perturbations lorsqu'elle ajoute de nouvelles fonctionnalités à Cortex Framework. Les nouvelles mises à jour donnent la priorité à la rétrocompatibilité. Toutefois, ce guide vous aidera à 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 valorisation des données répliquées dans BigQuery. Les organisations adaptent ces modèles, modules, scripts SQL et Python, pipelines et autres contenus fournis pour répondre à leurs besoins.

Composants principaux

Le contenu de la fondation de données Cortex Framework est conçu dans un esprit 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. BigQuery est la seule plate-forme dont la base dépend étroitement. Tous les autres outils peuvent être interchangés selon les besoins :

Intégration des données : tout outil d'intégration interconnecté à BigQuery peut être utilisé, à condition qu'il puisse répliquer les tables et structures brutes. Par exemple, les tables brutes doivent ressembler au schéma dans lequel elles ont été créées dans SAP (mêmes noms, champs et types de données). De plus, l'outil d'intégration doit être en mesure de 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 que l'indicateur d'horodatage ou d'opération pour mettre en évidence les enregistrements nouveaux et modifiés.
Traitement des données : les scripts de traitement Change Data Capture (CDC) fonctionnent avec Managed Service for Apache Airflow (ou Apache Airflow) et sont facultatifs. À 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 tableaux 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 reporting de leur choix.

Principaux avantages

Cortex Framework Data Foundation est conçu pour s'adapter à divers besoins commerciaux. Ses composants sont conçus pour être flexibles, 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 de manière fluide à divers outils d'intégration, de traitement et de visualisation des données au-delà de BigQuery.
Personnalisation : les organisations peuvent modifier et étendre les composants prédéfinis tels que les vues SQL pour qu'ils correspondent à leurs modèles de données et à leur logique métier.
Optimisation des performances : les 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 minimise les perturbations pour les implémentations existantes. Pour en savoir plus sur les modifications apportées aux versions, consultez les notes de version.
Contribution de la communauté : encourage le partage de connaissances et la collaboration entre les utilisateurs.

Mise à jour d'un processus

Les sections suivantes expliquent comment les développeurs peuvent maintenir leur code à jour avec le dépôt Cortex Framework Data Foundation tout en conservant leurs personnalisations. Utilisation des scripts de déploiement prédéfinis 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ôtes Git, comme les actions GitHub.

Configurer le dépôt

Cette section décrit une approche pour configurer votre dépôt. Avant de suivre ces étapes, nous vous recommandons de bien comprendre Git.

Forker le dépôt principal : créez un fork du dépôt Cortex Framework Data Foundation. La copie permet à ce dépôt de continuer à recevoir les mises à jour du dépôt Google Cloud et de créer 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 dupliqué sur le nouvel hôte.
Initialiser le dépôt de l'entreprise : copiez le code de votre dépôt dupliqué dans le dépôt de l'entreprise que vous venez de créer. Ajoutez le dépôt forké d'origine en tant que dépôt distant en amont à l'aide de la commande suivante, puis vérifiez que le dépôt distant a bien é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 dépôts distants, l'origine et celui que vous avez ajouté après avoir utilisé la commande :
```
git remote -v:
```
Vous disposez désormais du dépôt Company's repository, dans lequel les développeurs peuvent envoyer leurs modifications. Les développeurs peuvent désormais cloner des branches et travailler dans le nouveau dépôt.

Fusionner vos modifications avec une nouvelle version de Cortex

Cette section décrit le processus de fusion des modifications provenant du dépôt de l'entreprise et de celles provenant du dépôt Google Cloud .

Mettre à jour les forks : cliquez sur Synchroniser le fork pour mettre à jour les forks 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éé et intégré l'utilisation d'une nouvelle vue dans SQL ;
- Modification des vues existantes
- Remplacement complet d'un script par notre propre logique
La séquence de commandes suivante ajoute le dépôt du fork en tant que dépôt distant en amont pour extraire la version mise à jour de GitHub et extrait sa branche principale en tant que GitHub-main. Cet exemple extrait ensuite la branche principale du dépôt de l'entreprise dans Google Cloud Source et crée une branche pour la 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 rebase au lieu d'une fusion, et la branche de fusion peut également être envoyée en tant que demande de fusion. Ces variations du processus dépendent des règles organisationnelles actuelles, de l'ampleur 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 doit être fusionné. Par exemple, Visual Studio.

Il est recommandé de signaler les personnalisations à l'aide de commentaires visuellement distincts pour faciliter le processus de comparaison.
Démarrez le processus de fusion : utilisez la branche créée (dans cet exemple, la branche s'appelle merging_br) pour rassembler 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 extraite de la branche principale (git checkout merging_br) du dépôt de votre entreprise, fusionnez les modifications entrantes du fork distant.
```
    ## 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 des conflits. Utilisez la comparaison graphique de l'IDE pour comprendre les modifications et choisir entre actuel, entrant et les deux. C'est là qu'il est utile d'avoir un commentaire dans le code concernant les personnalisations. Choisissez de supprimer complètement les modifications, de supprimer les fichiers que vous ne souhaitez pas du tout fusionner 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écapitulatif et validez-les avec la commande suivante :
```
    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 avez des doutes sur une étape, consultez Annuler des actions de base dans Git.
Tester et déployer : pour l'instant, vous ne faites que fusionner dans une branche "temporaire". À ce stade, nous vous recommandons d'exécuter un déploiement test à partir des scripts cloudbuild\*.yaml pour vous assurer que tout s'exécute comme prévu. Les tests automatisés peuvent vous aider à simplifier ce processus. Une fois que cette branche de fusion vous semble correcte, vous pouvez extraire votre branche cible principale et y fusionner la branche merging_br.