Contrôle des versions pour les flux personnalisés¶
Openflow prend en charge les clients de registre, dont le client de registre GitHub, qui vous permet d’utiliser un référentiel Git pour stocker et versionner vos définitions de flux personnalisées. Cela permet de mettre en œuvre les pratiques courantes du cycle de vie du développement logiciel (SDLC), telles que la création de branches, les pull requests, la révision du code et la migration vers un environnement de production.
Un flux de travail commun est le suivant :
Maintien d’une branche
mainreprésentant vos définitions de flux de production.Création de branches de fonctionnalités pour les nouveaux développements.
Développement et validation des modifications sur le canevas Openflow.
Ouverture des pull requests, examen des différences de flux et fusion.
Conditions préalables¶
Un référentiel GitHub pour le stockage des définitions de flux.
Un jeton d’accès personnel GitHub avec accès au
repository.Un Openflow Runtime avec accès au canevas Openflow.
Privilèges de rôle Snowflake appropriés sur l’objet Runtime Integration.
Étape 1 : Créer un client de registre GitHub¶
Créez un référentiel dans GitHub pour stocker vos définitions de flux.
Générez un jeton d’accès personnel (PAT) dans GitHub avec des autorisations d’accès au référentiel.
Sur le canevas Openflow, accédez à Controller Settings et créez un nouveau client de registre.
Sélectionnez GitHub Registry Client comme type.
Configurez le client de registre avec :
Votre URL de référentiel GitHub.
Le propriétaire du référentiel GitHub.
Votre jeton d’accès personnel pour l’authentification.
Étape 2 : Créer et versionner un nouveau flux¶
Sur le canevas Openflow, créez un nouveau groupe de processus pour votre flux.
Créez votre flux : ajoutez des processeurs, configurez les connexions et configurez votre pipeline de données.
Faites un clic droit sur le groupe de processus et sélectionnez Start Version Control.
Choisissez le client de registre GitHub que vous avez configuré à l’étape 1.
Indiquez un nom de flux et un message de commit initial.
Après l’enregistrement, la définition du flux est validée dans votre référentiel GitHub. Vous pouvez vérifier en contrôlant le référentiel dans GitHub.
Étape 3 : Utiliser des branches pour gérer les modifications¶
Créer une branche de développement¶
Dans votre référentiel GitHub, créez une branche (par exemple, dev ou une branche de fonctionnalités comme feature/add-new-table).
Importer et développer sur la branche¶
Sur le canevas Openflow, importez le flux de du registre GitHub dans un nouveau groupe de processus en faisant glisser l’icône Import from Registry de la barre d’outils vers le canevas.
Lors de l’importation, sélectionnez la branche cible (par exemple,
dev) sur laquelle vous souhaitez travailler.Apportez vos modifications au flux à l’intérieur du groupe de processus.
Validez vos modifications dans Openflow. Ceci pousse la définition du flux mise à jour vers la branche sélectionnée dans GitHub.
Vérifier et fusionner via une pull request¶
Dans GitHub, ouvrez une pull request depuis votre branche de développement vers
main.Vérifiez les modifications. Utilisez l’action GitHub de différence de flux Snowflake (voir Étape 4) pour des différences lisibles par l’homme.
Fusionnez la pull request après son approbation.
De retour sur le canevas Openflow, mettez à jour le groupe de processus
mainpour extraire la dernière version de la branchemain.
Étape 4 : Configurer la différence de flux Snowflake (action GitHub)¶
La différence de flux Snowflake est une action GitHub qui rend les modifications de flux lisibles par l’homme en générant une différence visuelle des modifications de votre pipeline directement dans les conversations de pull request.
Configurer le fichier de workflow¶
Dans votre référentiel GitHub, créez le fichier
.github/workflows/flowdiff.yml.Copiez la configuration du workflow à partir du référentiel Différence de flux Snowflake (voir la section Utilisation dans README).
Validez et poussez le fichier de workflow.
Vérifier les modifications de flux¶
Lorsqu’une pull request est ouverte, l’action de différence de flux s’exécute automatiquement.
Accédez à l’onglet Conversations sur la pull request et attendez que l’analyse de la différence de flux s’affiche.
L’analyse montre une comparaison visuelle, lisible par l’homme, des changements de flux au lieu de différences JSON brutes.
Gérer les paramètres dans tous les environnements¶
Openflow utilise des paramètres pour gérer les valeurs spécifiques à l’environnement (par exemple, les chaînes de connexion, les identifiants de connexion, les noms de table) dans différents runtimes.
Gardez les concepts suivants à l’esprit :
Les paramètres sont regroupés dans un contexte de paramètres, qui a un mappage un-à-un avec un groupe de processus.
L’héritage du contexte des paramètres vous permet de définir des paramètres partagés dans un contexte parent et de remplacer des valeurs spécifiques dans des contextes enfants. Cela est utile pour promouvoir les flux entre les environnements de développement, de mise en zone de préparation et de production.
Les contextes de paramètres peuvent s’intégrer aux gestionnaires de secrets pour gérer en toute sécurité les identifiants de connexion sensibles sans les stocker dans la définition du flux.
Workflow SDLC recommandé¶
Environnement de développement : Les développeurs créent des branches de fonctionnalités, construisent ou modifient des flux, et valident les changements sur le canevas Openflow par rapport à leur branche de fonctionnalités.
Examen du code : Ouvrez une pull request dansGitHub. Utilisez la différence de flux Snowflake pour des examens plus lisibles.
Fusionner vers principal : Après approbation, fusionnez la pull request dans la branche
main.Promouvoir en production : Dans votre runtime de production, mettez à jour le groupe de processus pour extraire la dernière version de
main.Paramétrer : Utilisez des contextes de paramètres pour gérer la configuration spécifique à l’environnement sans modifier la définition du flux elle-même.