tag:linuxfr.org,2005:/tags/workflow/publicLinuxFr.org : les contenus étiquetés avec « workflow »2023-01-12T17:51:27+01:00/favicon.pngtag:linuxfr.org,2005:Diary/405382023-01-10T12:27:50+01:002023-01-10T12:27:50+01:00Pipedream : des workflows, des APIs et de la vitesseLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Bonjour Nal,</p>
<p>Aujourd'hui, je veux vous faire part d'une de mes découvertes : <a href="https://pipedream.com/">Pipedream</a>.<br>
En deux mots :</p>
<blockquote>
<p>Une plateforme de calcul sans serveur avec plus de 1000 intégrations d'applications open source. Pensez à AWS Lambda + Zapier, spécialement conçu (et gratuit) pour les développeurs.</p>
<p>Avec Pipedream, vous pouvez importer n'importe quel paquet dans une étape de code Python et créer des workflows sans serveur - pas besoin de mettre à jour un fichier requirements.txt ou de spécifier des paquets. C'est un moyen rapide d'exécuter du code Python déclenché par une requête HTTP, un timer ou un événement provenant d'un service cloud. </p>
</blockquote>
<h3 id="toc-comment-je-lai-découvert">Comment je l'ai découvert</h3>
<p>De la manière la plus improbable.<br>
J'avais publié quelques jours plus tôt mon premier package sur <a href="https://pypi.org/">Pypi</a>, quand j'ai reçu un email.<br>
Un mail de <a href="https://github.com/todsac">Tod Sacerdoti</a> me proposant un compte pro gratuit sur Pipedream (dont il est le fondateur) en qualité de mainteneur de mon package.<br>
Je vérifie qui il est, ce qu'il me propose. Tout semble net.<br>
Je réponds donc en acceptant sa proposition.<br>
Quelques jours plus tard, je reçois une réponse avec un code promo pour 6 mois Pro gratuit.<br>
Je crée un compte, n'active pas tout de suite mon code, mais commence à explorer.</p>
<h3 id="toc-les-apis">Les APIs</h3>
<p>Comme annoncé, un nombre incroyable d'APIs sont disponibles, comme GitHub, Twitter, Discord, Slack, Télégramme, Google, DeepL, Airtable, Zoom, etc.</p>
<p>Ces APIs peuvent servir à différents moments du workflow, et la connexion à un compte est très simple.</p>
<h3 id="toc-les-workflows">Les Workflows</h3>
<p>Un workflows "standard" est découpé en trois étapes :<br>
1. Un élément déclenche l'activation du workflow. Ce peut être un simple Cron, un mail, une requête HTTP, un message sur Twitter, une pull request sur GitHub, votre streamer préféré qui commence un live sur Twitch, et tant d'autres choses.<br>
1. Traitement des données : vous codez ce que vous voulez, dans le langage de votre choix, en prenant en compte des données de l'évènement déclencheur ou pas, en utilisant ou stockant des données dans une base de donnée (fournies avec le compte), en ajoutant des informations à un Google Sheet, etc.<br>
1. La réponse : une éventuelle réponse que retourne le workflow, un code 200, envoyer un mail, ou un message sur Slack, ou autre chose.</p>
<h3 id="toc-conclusion">Conclusion</h3>
<p>Une plate-forme très puissante, riche en possibilités, en dont les limites sont très, très difficiles à atteindre, même avec un compte gratuit.</p>
<p>Je déplore simplement un léger manque de documentation pour débutant, mais c'est là quelque chose d'aisément contournable, puisqu'on peut copier d'autre workflows, et que le constructeur de workflows nous guide pas à pas avec des exemples et des suggestions.</p>
<p>Sans aucune connaissance particulière, j'ai pu mettre en œuvre <a href="https://pipedream.com/@tod/github-profile-view-counter-p_G6CNmN/readme">un petit workflow</a> qui compte le nombre de vues sur <a href="https://github.com/alberic89">ma page de profil GitHub.</a></p>
<p>Mais les possibilités sont potentiellement infinies. Par exemple, publier automatiquement sur votre blog les annonces de release à partir des informations du dépôt git, ou vous envoyer une notification par mail chaque mois avec les statistiques de votre même site, et tant d'autres choses.</p>
<p>Pour plus d'information, visitez <a href="https://pipedream.com/">leur site</a> ou envoyez un mail à Tod Sacerdoti à tod AT pipedream.com, il lit et répond à tous les mails. Vous pouvez également envoyer vos impressions à feedback AT pipedream.com</p>
<div><a href="https://linuxfr.org/users/alberic89/journaux/pipedream-des-workflows-des-apis-et-de-la-vitesse.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/129945/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/alberic89/journaux/pipedream-des-workflows-des-apis-et-de-la-vitesse#comments">ouvrir dans le navigateur</a>
</p>
alberic89 🐧https://linuxfr.org/nodes/129945/comments.atomtag:linuxfr.org,2005:Diary/398242021-06-27T19:45:00+02:002021-06-28T07:43:52+02:00Footswitch: une extension pour faire de la retranscription (audio et vidéo) dans LibreOffice WriterLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p><a href="https://extensions.libreoffice.org/en/extensions/show/footswitch">Footswitch</a> est une extension pour LibreOffice Writer qui permet de piloter un lecteur multimédia pour faire de la retranscription, en utilisant soit une pédale de contrôle USB, des raccourcis clavier ou les boutons affichés sur le mini player.</p>
<p>Je viens de tomber dessus et c’est un truc que je désespérais un peu de trouver depuis que je me suis mis à travailler sur un paquet d’enregistrements audio et video pour des recherches. Du coup, je partage le lien sans attendre d’avoir un peu plus de recul.</p>
<p>J’ai pas de pédale, mais il marche franchement assez bien avec ses raccourcis clavier intégrés (Alt+1 = ouvrir le sélecteur de fichiers, Alt+2 = play/pause, etc. y a une doc fournie, et on peut les modifier) pour me faire envisager d’en acheter une…</p>
<p>L’avantage, enfin pour moi qui ne suis pas un transcripteur pro (c’est un job?), c’est de pouvoir contrôler la lecture du truc sans devoir sortir de Writer (et sans devoir retirer mes doigts du clavier). Quel gain de temps, surtout quand le clavier du PC n'a pas de boutons multimédia dédiés ou alors qu'ils ne sont pas supportés.</p>
<p>Si vous connaissez d’autres outils similaires (y compris pour Emacs, d’ailleurs ;)), n’hésitez pas à en parler ;)</p>
<div><a href="https://linuxfr.org/users/yal/journaux/footswitch-une-extension-pour-faire-de-la-retranscription-audio-et-video-dans-libreoffice-writer.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/124720/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/yal/journaux/footswitch-une-extension-pour-faire-de-la-retranscription-audio-et-video-dans-libreoffice-writer#comments">ouvrir dans le navigateur</a>
</p>
yalhttps://linuxfr.org/nodes/124720/comments.atomtag:linuxfr.org,2005:Diary/385252019-05-24T10:47:37+02:002019-05-24T10:47:37+02:00Gestion des tickets/workflowsLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>Je suis actuellement à la recherche d'un logiciel pour gérer les tickets/workflows (<a href="https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems">issue-tracking systems</a>). Typiquement pour gérer des demandes de changement, remonter des bogues, demande d'authorisation, gestion des risques, affectation de tâches, etc.: en gros tout ce qui demande le traitement et l'accord de plusieurs personnes successives.</p>
<p>J'ai l'impression que l'ont peut déjà établir 2 catégories de logiciels:<br>
1) ceux pour qui l'entreprise doit s'adapter au logiciel<br>
2) ceux pour qui le logiciel soit s'adapter à l'entreprise</p>
<p>Le première catégorie semble plutôt s'adresser aux "développeurs": il est recommandé de ne pas trop personnaliser les workflows standards pour conserver la simplicité (Trello par exemple).<br>
La seconde catégorie semble plutôt s'adresser aux "managers": ici l'outil doit se conformer aux (lourdes) procédures de l'entreprise, et on doit pouvoir personnaliser à volonté les workflows jusqu'à créer des workflows monstres, rempli d'intervenants à chaque étape (Jira par exemple).<br>
(bien entendu rien n'empêche une entreprise d'utiliser intelligement Jira pour conserver la simplicité ou de prendre un simple Trac et d'en faire un monstre)</p>
<p>J'ai un peu fouillé pour trouver un logiciel qui entre dans la seconde catégorie (personnalisation aisée de workflows, je sais c'est mal, merci de ne pas me juger) et je suis rentré un peu bredouille. Il y a bien a des solutions comme Jira ou ServiceNow, mais cela semble lourd et fermé.<br>
J'aurais aimé trouver quelque chose de plus ouvert à la communauté (idéalement open-source) et surtout plus sympathique d'un point de vue utilisateur (toutes les solutions que j'ai trouvées demandent l'intervention de l'administrateur IT pour ajouter/modifier des champs ou pour créer un nouveau workflow).<br>
En open-source, il semble que le temps s'est arrêté il y a quelques années et que l'on reste sur BugZilla, Trac ou Redmine (loin de moi l'idée de vouloir lancer un troll le vendredi…). J'ai bien vu Tuleap passer sur linuxfr, mais il semble que pas grand monde ne l'utilise.</p>
<p>Est-ce la grande expérience cumulée des lecteurs de linuxfr aurait un logiciel miracle à me recommander pour une gestion flexible des workflows ?</p>
<p>Note: je m'étais initialement tourné vers les <a href="https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems">issue-tracking systems</a> mais peut-être que les outils de <a href="https://fr.wikipedia.org/wiki/Business_Process_Management">Business Process Management</a> (Nintex par exemple) ou de <a href="https://en.wikipedia.org/wiki/Workflow_engine">Gestion de workflow</a> sont plus adaptés. J'avoue ne pas avoir bien compris la différence et chercher "BPM vs workflow" m'a encore plus embrouillé. De plus tout cela me semble encore bien plus fermé. Si quelqu'un a une expérience avec ce type de logiciel ?</p>
<div><a href="https://linuxfr.org/users/desktop-ready-0/journaux/gestion-des-tickets-workflows.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/117296/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/desktop-ready-0/journaux/gestion-des-tickets-workflows#comments">ouvrir dans le navigateur</a>
</p>
desktop.readyhttps://linuxfr.org/nodes/117296/comments.atomtag:linuxfr.org,2005:News/362452015-03-18T17:58:50+01:002015-03-18T17:58:50+01:00Publication d'evQueue sous licence libreLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>EvQueue est un ordonnanceur de tâches et un moteur de <em>queueing</em> libre. Il permet la planification de tâches simples mais aussi la gestion de <em>workflows</em>, enchaînements de briques logicielles de base dans un but plus avancé. La description des enchaînements de tâches est basée sur XML et XPath, reprenant ainsi des briques très standardisées pour la structure des <em>workflows</em>.</p>
<p>Le moteur d'evQueue est écrit en C++ en mode événementiel, il se démarque ainsi de certains ordonnanceurs par sa légèreté et sa rapidité. L'interface de pilotage Web est quant à elle développée en PHP. Elle permet le suivi des tâches et <em>workflows en cours</em>, la création de <em>workflow</em> notamment en mode graphique, et la planification de tâches.</p>
<p>En plus de l'interface de pilotage Web, evQueue propose une API réseau permettant son contrôle à distance (lancement de tâches, suivi des tâches en exécution…). L'exécution de traitements lourds est en effet une problématique récurrente des systèmes Web où les clients sont en mode asynchrone. L'utilisation d'evQueue résout cette problématique, assurant un suivi simple à mettre en place en AJAX côté utilisateur et une excellente visibilité pour les administrateurs systèmes.</p>
<p>Une documentation sur l'installation et l'utilisation d'evQueue, ainsi que des exemples de workflows sont disponibles sur le site d'evQueue.</p>
<p>EvQueue est développé et maintenu par l'équipe informatique de l'UFC-Que Choisir. Il est publié sous licence libre depuis mars 2015 (GPL 3). Il est utilisé pour les besoins informatiques de l'association depuis presque trois ans ; à ce jour, plus de quatre millions de workflows ont été lancés.</p></div><ul><li>lien nᵒ 1 : <a title="http://www.evqueue.net" hreflang="en" href="https://linuxfr.org/redirect/93435">Site officiel</a></li></ul><div></div><div><a href="https://linuxfr.org/news/publication-d-evqueue-sous-licence-libre.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/105130/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/publication-d-evqueue-sous-licence-libre#comments">ouvrir dans le navigateur</a>
</p>
njeanZeroHeurehttps://linuxfr.org/nodes/105130/comments.atomtag:linuxfr.org,2005:Diary/354392014-12-02T13:44:37+01:002014-12-02T13:44:37+01:00Git workflow, rebase, conflits et rôle d'intégrateurLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<p>'jour 'nal</p>
<p>Depuis quelques temps, à l'occasion d'un nouveau projet (au boulot) avec mes collègues j'ai mis en place un nouveau workflow git.<br>
Vous savez, un truc qui défini comment on gère les branches, les rebases, les fusions, le nommage des branches, etc.</p>
<p>En gros, le workflow est le suivant :</p>
<ul>
<li> tout est réalisé dans des branches
<ul>
<li> les branches sont préfixées (exemple <code>refactor/copter_param</code>, <code>feature/fences</code>, <code>bug/landing</code>) pour les retrouver facilement</li>
<li> aucun commit directement dans master</li>
<li> pas de branches de prod, maintenance, etc</li>
</ul>
</li>
<li> <code>master</code> est la branche stable depuis laquelle on crée les versions</li>
<li> une branche d'intégration existe pour faciliter les tests (j'y reviens)</li>
<li> les branches sont toujours rebasées depuis <code>integ</code> puis fusionnées en <em>"no fast forward"</em>
</li>
<li> une fois les tests validés dans integ, on merge dans master (soit en <em>fast forward</em> si tout est bon à prendre, soit en réintégrant branche par branche)</li>
</ul><p>En gros tout ceci a pour objectif principal d'avoir un historique toujours très lisible. L'ensemble des modifications liées à une fonctionnalité est très lisible. Il est "facile" (autant que possible) de supprimer une fonctionnalité (il suffit d'inverser un commit de merge). (Si vous voulez plus de détails sur le pourquoi du comment c'est <a href="http://blog.sogilis.com/post/104148375576/notre-workflow-git-pourquoi-comment" title="Notre workflow Git, pourquoi, comment">par ici</a>)</p>
<p>Dans un monde idéal c'est super. Franchement. Avant on avait un historique, comment dire… horrible, des merges dans tous les sens, etc. Aujourd'hui on a un truc lisible :</p>
<p><img src="//img.linuxfr.org/img/687474703a2f2f6d656469612e74756d626c722e636f6d2f66636135363161323737623833306163336335666163343066313062646134342f74756d626c725f696e6c696e655f6e666c6f316b68537945317376366d75682e706e67/tumblr_inline_nflo1khSyE1sv6muh.png" alt="Avant - Après" title="Source : http://media.tumblr.com/fca561a277b830ac3c5fac40f10bda44/tumblr_inline_nflo1khSyE1sv6muh.png"></p>
<blockquote>
<p>Bon c'est bien joli tout ça, mais pourquoi tu nous racontes ça alors ?</p>
</blockquote>
<p>Le problème c'est qu'on est pas toujours dans un monde idéal.</p>
<p>En premier lieu, je bosse dans un secteur spécial : c'est du code embarqué pour des 'ti nappareils avec des hélices qui peuvent voler dans le ciel. L'une des conséquences (associée à une base de code, comment dire poliment…, genre si j'attrape le gars qui l'a écrit je lui fais réécrire le noyau linux en <a href="http://fr.wikipedia.org/wiki/Whitespace">whitespace</a> avec un écran monochrome) c'est que parfois nos tests unitaires (et autres) passent sur notre intégration continue, et pour autant les essais en vol ne sont pas concluant. Ça introduit une certaine latence entre le moment où on développe, le moment où on passe en CI et le moment où on valide réellement un développement. D'où la notion de branche d'intégration. La branche d'intégration est une version "à tester" qui, si tout se passe bien, peut devenir stable (master). Mais qui si ça ne se passe pas bien peut être supprimée et refaite suivant les résultats. Evidemment si on pouvait jouer des tests sur toutes les branches et être certains du résultat, il n'y aurait pas de problème ;-)</p>
<p>Le problème résultant c'est que parfois il faut "rouvrir" les branches (enlever le commit de fusion), modifier la branche (corriger), re-fusionner. Et c'est quand même assez fastidieux.</p>
<p>Et l'autre problème est que, pour des questions de lisibilité, on utilise beaucoup le rebase. Oui mais ça veut parfois dire des conflits un peu compliqués et surtout fastidieux. Même avec git rerere.</p>
<p>Pour ce genre de raisons, une personne est aujourd'hui dédiée à la fusion dans les branches d'intégration et <code>master</code>. Tous les autres bossent dans leurs branches. Ça simplifie un peu le boulot global, mais c'est pas terrible.</p>
<p>Alors j'en viens à vous questionner, chers linuxfriens adeptes de Git (mais ça marche aussi avec Mercurial).</p>
<p>Vous arrive-t-il de bosser avec des rôles d'intégrateurs / fusionneurs Git ?<br>
Comment éviter ce type de situation ? Abandonner le rebase au prix d'un historique moins lisible ?<br>
Est-il encore temps de retourner sous svn ?</p><div><a href="https://linuxfr.org/users/crev/journaux/git-workflow-rebase-conflits-et-role-d-integrateur.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/104134/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/crev/journaux/git-workflow-rebase-conflits-et-role-d-integrateur#comments">ouvrir dans le navigateur</a>
</p>
CrEvhttps://linuxfr.org/nodes/104134/comments.atom