Le DevOps est une tendance inévitable dans les systèmes d'informations. Une tendance qui apporte une touche distinguée d'exotisme à la production de services. Si peu exotiquement distinguée puisse paraitre cette entreprise. Elle reste l'activité favorite de nombreuses directions, éditeurs et acteurs glorieux, des technologies de l'information. C'est surprenant comme innover, revient souvent à faire exactement comme tout le monde, mais d'une manière nouvelle. Alors en quoi le DevOps est-il une innovation si éblouissante ? Et bien aussi trivial cela puisse-t-il apparaitre, le plus grand apport du DevOps est de faire en sorte que. Roulement de tambours : les développeurs développent. Je l'ai laissé entendre, l'innovation n'épouse pas toujours l'extravagance. De temps à autres, elle apparait d'une manière des plus naturelles, et se diffuse.
Mais alors, mais, que faisaient ils, avant, ces développeurs, s'ils ne développaient pas ? Du tricot... du squash pourquoi pas... de la doc, que dis-je des spécifications ! Et à n'en plus finir ! Et puis des réunions, des comités, des cadrages, des validations... Et quand enfin nos chers développeurs arrivaient à écrire quelques lignes de code, la demande imminente se faisait sentir d'y joindre un mode opératoire. Et d'y détailler ainsi, le déploiement de ce morceau d'application quelque part. Sans bien sûr qu'ils ne sachent où, nos développeurs. S'eût été trop simple.
Louée soit l'Histoire, qui condamne parfois certains comportements douteux. Hop ! Poubelle ! Et la lumière fût. Le DevOps, et avec lui, les développeurs développent, et la définition même de la vélocité, si précieuse à l'agilité, prend tout sont sens. Cette vélocité, composée jusqu'à présent de lueurs mystiques, devient si nette, et précieusement égale : à la somme des jours où les développeurs bossent en paix ; ni plus, ni moins. Et de là, les applications s'avancent. Elles tournent, comme qui dirait, et se retournent, crénom de nom, elles se compilent !
De là vient une nouvelle organisation, un nouvel ordre. Où les services requièrent toujours d'être déployés. Mais dans une fantastique envolée aux couleurs révolutionnaires, presque anarchiques. Une livraison sans mode opératoire. Une installation ne nécessitant pas, qu'aucun agent de l'infrastructure, ne vienne la dépiler. Aucun représentant légal de, feux, ces modes opératoire, MODOP, MOOP, MANIP, PROC, et je ne sais quoi. Qui rappelons le nous, et aimons nous en souvenir, méritaient de disparaitre, à jamais, et depuis longtemps.
A vrai dire, nul ne peut certifier que c'est à cet emplacement que nous devions atterrir. Mais laissez moi vous rassurer : lancer un débat sur le DevOps, ou encore sur l'Innovation dépasse largement le périmètre de cet article, qui, ça me revient, se focalise sur une humble brique du vaste mur qu'est le DevOps. J'ai nommé : les mécanismes d'automatisation. Les fameuses pipelines, qui ont comme seul défaut de ne pas avoir de traduction cohérente, et viennent réduire tous vos efforts visant à ne pas sombrer dans le franglais des plus totaux quand nous nous mettons à causer d'Haïti, ou plutôt d'IT, comme on aime à le prononcer dans le Bouchonnois. J'ai bien essayé, et pas plus tard que cette année, d'introduire une variante plus franchouillarde au sein de mon équipe. En ce mot oléoduc, j'avais placé beaucoup d'espoirs de gloire et de fortune. Mais j'ai fait un flop, un double flop. Et l'actualité, à sa grande habitude, ne m'a aider en rien. Me rendant à une évidence double : traduire ce mot n'a pas plus de sens que de se bâfrer un fish and chips dans une brasserie Corse. Et, tenter d'éviter de l'écrire sous sa forme originelle, me mène inlassablement à utiliser à nouveau des mots issus du dictionnaire anglais, ce qui semble contredire mes engagements initiaux. Piètre amateur de cuisine anglaise, que je suis, je vais pourtant vous servir de la pipeline à toute les sauces ! Et au féminin, qui plus est ! Puisse le grand Cric me pardonné de cet accroc, et ne pas me croquer.
Bon alors, je refais le topo, j'étais censé écrire une simple introduction, genre, voilà je m'appelle Julien et je vais parler de pipeline. Crotte ! Faut croire que mes tendances dilettantes sont toujours aussi solidement encrées au plancher océanique de ma divagation. Tristement, il vous faudra vous en accoutumer pour assister à la fin de cette tragédie. Et pire, je préfère vous prévenir... que mon sponsor aime à vous savoir mijoter dans cette sauce hollywoodienne, cette décoction, à base de coupures aux instants les plus critiques à la compréhension fine de cette histoire. Ce, dans l'unique intérêt de cultiver chez vous, une douce envie de venir, et revenir, parcourir la suite de cette folle aventure, qui vous en percevez désormais les raisons, s'intitule corps et âmes : une Pipeline sans queue ni tête.
Comment en suis-je arriver là ?
C'est une longue histoire… Et si la perplexité qu'elle inspire est proportionnelle à la taille de son introduction, croyez-moi, vous ne voulez simplement pas l'entendre. Ce que vous voulez peut être savoir, en revanche, c'est comment composer à votre tour une pipeline qui fera dire à votre patron, que vous embaucher dans cet exercice est la meilleure idée qu'il ait eut depuis un bail ! Et là, tout laisse à croire que je peux faire quelque chose pour vous. Toutefois, et ne vous en déplaise... se contenter d'un simple copier-coller, faisant apparaitre d'un coup d'un seul cette précieuse Pipeline, qui une fois étendue permet de compiler, comme de déployer, la totalité des projets de votre entreprise… n'est pas le mode retenu pour partager les connaissances et les vertus, qui ont permis à un tel joyau de voir le jour. C'est donc en toute conscience et en toute lucidité, que j'ai trouver une autre manière de partager le chemin qui mène à cette réalisation, à défaut d'en partager le contenu. Puissiez vous me pardonner, fidèles lecteurs sauce hollywoodienne. Et si cela peut vous convaincre de rester, je suis même prêt à faire un effort pour écrire des phrases plus courtes… et pourquoi pas un peu plus de YAML.
Où refusais-je de vous conduire ?
C'est fondamental de se poser la question ! Cette saga ne s'abaisse nullement à commenter une pipeline ordinaire, semblable à celle qui se ballade ici et là, entre les sections de ce premier article. Cette aventure vous laisse caresser l'espoir d'entrevoir, comme projetées sur l'écran de vos esprits, de plus attractives lignes. Elle ne s'attardera que brièvement sur les formes de ce spécimen, qu'un sadique semble avoir pris soin de découper à la tronçonneuse, pour mieux le répandre le long de ce scénario hollywoodien, qui se révèle progressivement à vos yeux frétillants. Dans qu'elle intention tartiner ainsi le démarrage de cette saga avec des morceaux de pipeline ? Pourquoi découper cette pauvre pipeline, dont l'ordinaire ne dépasse guère la présence de beurre demi-sel sur la table d'un petit-déjeuner vendéen ? Sans doute dans l'optique de m’empêcher de progresser dans le déroulement de cette histoire, troublé que je suis, par ce spectacle désolant. Vous vous en doutez à présent. Je connais cette pipeline de manière intime. L'impact de ces images sur mon vocabulaire m'a sans doute trahi. Ma plume, devant tant de désarrois, a fourché. Je dois l'avouer, je ne puis ne pas reconnaitre les morceaux de cette pipeline, fussent-ils mélangés à des millions d'autres tranches, toutes aussi ordinairement massacrées. Et pour cause : nous avons passé de longues heures ensemble, au détour de nombreuses formations, et je dois l'avouée, cette pipeline je l'apprécie comme Georges apprécie Hélène, en dépit de ses sabots crottés, et de son âme en peine.
resources:
repositories:
- repository: web
type: git
name: super-projet/super-app
ref: main
trigger:
branches:
include:
- main
trigger:
- none
La première strophe de cette poésie exsangue, référence une ressource externes. Une super-app contenu dans un super-projet, tous deux inclus dans Azure DevOps, fabuleux site qui vient bercer le quotidien de tant de confrères ambulanciers. Contrairement aux apparences, cette référence ne concerne pas n'importe quelle ressource externe, mais une ressource de choix : un contrôleur de source. Un contrôleur fourni par l'immense Linus, en personne, et dédié à la composition de jolis services. Les sources de cette application rocambolesque, sont accompagnées d'une gâchette frénétique, qui se déclenche à chaque opération de fusion ciblant la branche main. Appréciez au passage, cher public venu du grand ouest, que cette branche à laquelle nous nous accrochons possède une appellation moderne, et toute aussi distinguée que vous l'êtes ; une appellation sans connotation aucune. Nommer cette branche master, ou même pied, ne se fait plus. Ah ça non, ça pue ! Toutes ces branches ont été revisitées d'un nom, qui nous rappelle chaque jour que sur ce long chemin qui est le nôtre, il est sans doute préférable que nous marchions main dans la main.
pool:
name: super-bac-a-agents
Par la suite, cette pipeline pointe vers un groupe d'agents nommé super-bac-a-agents. Un bac constitué d'agents super spéciaux… et zut ! Il me faut éviter à l'avenir tout autre abus de superlatif, qui pourrait laisser croire à notre audience que le cinéma vend du super, alors que personne n'est dupe : le Super, à Hollywood, il n'y en a plus ! Pas plus que du sans-plomb et du diesel d'ailleurs, mais ne remuons pas le couteau dans la plaie, et roulons à l'électrique, dans un élan de Musk. D'autant plus qu'en réalité, ces agents n'ont rien de spécial. Ils ont simplement été installés dans l'exercice précédent par les tristes participants, qui condamnés ils le resteront, à passer cinq jours en ma compagnie. Forcés d'apprécier comme il se doit les conseils pragmatiques d'un formateur excentrique, qui à l'image de cette simple astuce, évite la création d'un embouteillage dans la file d'attente des traitements déclenchés tout au long de cette joyeuse et frénétique parodie. Je vous rassure, la plupart du temps les participants y survivent. A l'inverse de nos agents peu spéciaux, qui trépassent inlassablement en fin de script. Partageant ainsi le dramatique sort de tant de vilains incapables d'échapper à l'intransigeante justice du Bois-Bénit, qui leur mène la vie dure sur tant de bobines.
stages:
- stage: artifact
displayName: "Build"
jobs:
- job: publish
displayName: "Publish artifact"
steps:
- checkout: web
- task: UseDotNet@2
displayName: 'Use framework 6.x'
inputs:
packageType: 'sdk'
version: '6.x'
- task: DotNetCoreCLI@2
displayName: 'Restore dependencies'
inputs:
command: 'restore'
projects: '**/Web.csproj'
feedsToUse: 'select'
- task: DotNetCoreCLI@2
displayName: 'Build project'
inputs:
command: 'build'
projects: '**/Web.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI@2
displayName: 'Run all tests'
inputs:
command: 'test'
projects: '**/*[Tt]ests/*.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI@2
displayName: 'Create artifact'
inputs:
command: 'publish'
publishWebProjects: false
projects: '$(WebProject)'
arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
displayName: 'Publish artifact'
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
Cinq jours c'est long. Mais bien moins long que la peine encourue pour exposer en public un mécanisme de compilation .net Core aussi trivial qu'affligeant ! Passons donc à la suite, avant que les forces de l'ordre ne sorte les menottes. Grands coquins !
- stage: dev
displayName: "DEV"
dependsOn: artifact
condition: succeeded('artifact')
jobs:
- deployment: azure
displayName: "Publish on Azure"
environment: DEV
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
patterns: "**/*.zip"
- task: AzureRmWebAppDeployment@4
displayName: 'Deploy to dev slot'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'formation-azure-devops'
appType: 'webApp'
WebAppName: 'webapp-25'
deployToSlotOrASE: true
ResourceGroupName: 'super-group'
SlotName: 'dev'
packageForLinux: '$(Pipeline.Workspace)/drop/Web.zip'
ConfigurationSettings: '-APP_ENV DEV -APP_DEFAULT_CONTEXT TEAM'
Plus raisonnable, voici une illustration de téléchargement d'artéfact réalisée en bonne et due forme ! Mais la perfection ne se situe-t-elle point aux antipodes de la pédagogie ? C'est pourquoi, afin d'entretenir le mythe de la complexité technique du métier de l'information tout entier, je vais y introduire quelques variations ambigües.
- stage: staging
displayName: "STAGING"
dependsOn: dev
condition: succeeded('dev')
jobs:
- deployment: azure
displayName: "Publish on Azure"
environment: STAGING
strategy:
runOnce:
deploy:
steps:
- download: none
- task: DownloadPipelineArtifact@2
displayName: "Download artifact"
inputs:
artifact: drop
patterns: "**/*.zip"
path: "$(Pipeline.Workspace)"
- task: AzureRmWebAppDeployment@4
displayName: 'Deploy to dev slot'
inputs:
ConnectionType: 'AzureRM'
azureSubscription: 'formation-azure-devops'
appType: 'webApp'
WebAppName: 'webapp-25'
deployToSlotOrASE: true
ResourceGroupName: 'super-group'
SlotName: 'staging'
packageForLinux: '$(Pipeline.Workspace)/Web.zip'
ConfigurationSettings: '-APP_ENV STAGING -APP_DEFAULT_CONTEXT TEAM'
Première variation farfelue, cet abstrait download: none, qui permet d'inhiber un comportement automatique implémenté sournoisement par l'éditeur : qui évite aux jeunes recrues fougueuses du FBI d'oublier de télécharger leur artéfact avant de procéder à une étape de déploiement ! Rassurez-vous, fatigué lui aussi par toutes ces allusions grotesques, notre éditeur averti a finalement enterré cette sournoiserie au fin fond d'une documentation.
Cette abstraite illustration est d'ailleurs suivi de déclinaisons, toutes plus passionnantes les unes que les autres, du code initialement exécuté dans l'environnement de développement. Ces déclinaisons de code, viennent illustrer les différentes options qui s'offrent à nous pour gérer les dossiers de téléchargement des artéfact dans une pipeline. Me contentant de passer directement à la conclusion, j'écrirai simplement que le conseil associé à cette démonstration est : de ne pas permettre ce genre de liberté superflue ! Il est préférable de composer vos pipelines avec des templates, ce qui évite d'avoir à écrire une même étape de plusieurs façons.
- stage: prod
displayName: "PROD"
dependsOn: staging
condition: succeeded('staging')
jobs:
- deployment: azure
displayName: "Publish on Azure"
environment: PROD
strategy:
runOnce:
deploy:
steps:
- download: none
- task: DownloadPipelineArtifact@2
displayName: "Download artifact"
inputs:
artifact: drop
patterns: '**/*.zip'
path: $(Pipeline.Workspace)/drop
- task: AzureRmWebAppDeployment@4
displayName: Deploy to production
inputs:
ConnectionType: AzureRM
azureSubscription: formation-azure-devops
appType: webApp
WebAppName: webapp-25
ResourceGroupName: 'super-group'
packageForLinux: $(Pipeline.Workspace)/drop/Web.zip
ConfigurationSettings: -APP_ENV PROD -APP_DEFAULT_CONTEXT TEAM
Aussi humble soient ses ambitions, cette pipeline possède l'attrait de respecter rigoureusement l'état de l'art. Ce qui cela dit en passant parait approprié pour un spécimen de formation. Cet attrait majeur est : de compiler un unique artéfact, avant de le catapulter dans de multiples environnements. Voici une vérité qui s'applique à tant de processus issus du monde des technologies de l'information. Aussi dérisoire semble cette directive : il est fortement conseiller de déployer le même code dans tous les environnements. D'après les experts, c'est la condition si ne qua non, nul ne peut garantir la pertinence des opération effectuées. Mais pouvons-nous avoir confiance en une telle expertise ? Rappelons que ces experts semblent tolérer qu'un même objet soit catapulté en plusieurs destinations distinctes ? Tout laisse à croire qu'une telle prouesse nécessite de se dérouler dans un contexte spécifique. Mêmes de solides élastiques ne semblent pouvoir garantir un tel exploit physique. D'ailleurs existe-il des matières assez solide pour effectuer deux voyages consécutifs en catapulte ? Mais chaque chose en son temps. Veillons à dérailler en douceur, à lâcher les élastiques avec précaution, à déraper avec prudence...
A propos de dérapage, je regarde le tempo associé à de cette histoire et me voilà inquiet : nous sommes sur le bon plateau, mais un brin en retard sur son déroulement. Tel le lapin blanc, je propose alors de prendre un raccourci. Épargnons dès à présent à ces yeux avides de savoirs extraordinaires que sont les vôtres, la lecture de fragments de pipeline aussi quelconques que ceux rencontrés aujourd'hui. Certes, ils constituent un bon point de départ pour percevoir les mécanismes et objectifs fondamentaux des processus d'automatisation. Mais vous n'avez sans doute pas fait le déplacement depuis Hollywood, pour vous attardez à ce scénario diaphane. Conviés que vous êtes à une cérémonie des plus colorées, qui aussi surprenant cela puisse paraitre, n'a pas encore commencée. Si appréciables soit ces morceaux de pipeline, ils ne ressemblent en rien à ceux d'une réelle pipeline professionnelle, du genre de celles qui font rêver les décideurs !
Vous l'avez bien compris, et il est totalement inutile de le préciser... je vais toutefois le faire par pure acquis de conscience pédagogue : la pipeline illustrée dans cet article, n'a ni le gout, ni l'apparence, ni la forme, ni l'odeur et encore moins la texture, de la Pipeline sans queue ni tête, qui vous sera contée par la suite de cette saga !
> T'es sérieux ! Vieux sphinx ramolli par les années que tu es ! Tu vas nous laisser le bec dans l'eau ? Avant même de commencer ton histoire ! Sous prétexte qu'un lapin blanc s'est trompé de wagon ? Tu me dégoutes autant que ce pauvre type... qui avant même que le hip-hop ne berce le neuf-trois de ses douces vibrations, semblait inspiré par le nom du groupe phare de la Seine-Saint-Denis. Alors à l'exemple de ce bouffon, toi aussi, va ...
> Un peu de tenue ! Je vous prie ! Mesdames et Messieurs le moment tant attendu est enfin arrivé. Silence. Prenez place. La lumière s'efface doucement...
Julien
Commentaires :
Aucun commentaires pour le moment
Laissez un commentaire :