par Jeff Tickner & Olenka Van Schendel<\/h3>\n<\/div><\/div><\/div>Auparavant, le d\u00e9ploiement des applications s’effectuait g\u00e9n\u00e9ralement \u00e0 partir d’un serveur central connect\u00e9 \u00e0 tous les syst\u00e8mes concern\u00e9s. Cependant, dans le contexte actuel de s\u00e9curit\u00e9 accrue, il existe une demande croissante de d\u00e9ploiement dans des environnements de production enti\u00e8rement s\u00e9par\u00e9s du d\u00e9veloppement, fonctionnant ind\u00e9pendamment sur un r\u00e9seau isol\u00e9.<\/b> Cette pratique est devenue fondamentale en mati\u00e8re de s\u00e9curit\u00e9 et vise \u00e0 prot\u00e9ger les syst\u00e8mes critiques et \u00e0 maintenir l’int\u00e9grit\u00e9 des activit\u00e9s de l’entreprise.<\/p>\n
Cependant, peu importe o\u00f9 vous en \u00eates dans votre parcours DevOps, le d\u00e9ploiement d’applications dans des environnements ” isol\u00e9s ” pose des d\u00e9fis sp\u00e9cifiques, en particulier pour les plates-formes IBM i.<\/b> Historiquement, cette t\u00e2che \u00e9tait accomplie \u00e0 l’aide de supports physiques tels que des bandes et des DVD, dans une sorte de ” slow motion “. Cependant, dans un environnement num\u00e9rique contemporain au rythme acc\u00e9l\u00e9r\u00e9, de nouvelles options sont apparues, comblant le foss\u00e9 entre les m\u00e9thodes de d\u00e9ploiement traditionnelles et modernes.<\/p>\n<\/div>Sommaire<\/h2>\n\n- Les d\u00e9fis propres au d\u00e9ploiement d’applications sur IBM i<\/a><\/li>\n
- Tirer parti de la technologie du monde des syst\u00e8mes ouverts<\/a><\/li>\n
- Travailler avec des environnements “isol\u00e9s” de haute s\u00e9curit\u00e9<\/a><\/li>\n
- Exploiter les syst\u00e8mes g\u00e9n\u00e9riques de gestion des artefacts sur IBM i<\/a><\/li>\n
- Conclusion<\/a><\/li>\n<\/ol>\n<\/div><\/div>\n
1. Les d\u00e9fis propres au d\u00e9ploiement d’applications sur IBM i<\/h2>\n
Le d\u00e9ploiement d’applications sur la plate-forme IBM i requiert une attention particuli\u00e8re en raison de son architecture et de son environnement d’exploitation uniques.<\/b> Par ailleurs, \u00e9tant donn\u00e9 que de nombreuses applications IBM i sont essentielles aux activit\u00e9s de l’entreprise, les mises \u00e0 jour de production n\u00e9cessitent souvent des processus adapt\u00e9s et optimis\u00e9s sp\u00e9cifiques \u00e0 l’IBM i.<\/p>\n
Ceux qui d\u00e9couvrent la plate-forme IBM i seront peut-\u00eatre surpris de l’apprendre :<\/b><\/p>\n\n- Les applications IBM i sont g\u00e9n\u00e9ralement volumineuses<\/b> et sont invariablement d\u00e9ploy\u00e9es en mode “delta”<\/b> (compte tenu du volume, il n’est pas possible de remplacer l’ensemble des objets).<\/li>\n<\/ul>\n
\n- Les applications IBM i superposent g\u00e9n\u00e9ralement des bases de donn\u00e9es massives<\/b> qui ont un impact sur le processus de mise \u00e0 niveau et peuvent n\u00e9cessiter une gestion sp\u00e9cifique telle qu’une promotion “tant qu’elle est active” afin d’\u00e9viter des temps d’arr\u00eat excessifs pour les utilisateurs finaux.<\/li>\n<\/ul>\n
\n- Les applications IBM i sont souvent critiques pour l’entreprise<\/b> et exigent un niveau de s\u00e9curit\u00e9 \u00e9lev\u00e9 qui limite l’acc\u00e8s et la disponibilit\u00e9 lors de la mise \u00e0 jour.<\/li>\n<\/ul>\n
\n- Le syst\u00e8me d’exploitation IBM i est orient\u00e9 objet<\/b>, ce qui signifie que chaque type d’objet poss\u00e8de des propri\u00e9t\u00e9s sp\u00e9cifiques d\u00e9finissant (entre autres) la mani\u00e8re dont il doit \u00eatre d\u00e9ploy\u00e9 et les actions sp\u00e9cifiques qui doivent \u00eatre invoqu\u00e9es (le d\u00e9ploiement d’IBM i exige bien plus que le simple placement d’un fichier dans un r\u00e9pertoire !)<\/li>\n<\/ul>\n
\n- Gr\u00e2ce \u00e0 cette orientation objet, la s\u00e9curit\u00e9 est int\u00e9gr\u00e9e au syst\u00e8me d’exploitation <\/b>(un programme n’est pas un fichier, c’est un objet programme. Un simple fichier ne peut pas \u00eatre transform\u00e9 en objet ex\u00e9cutable).<\/li>\n<\/ul>\n
\n- Invariablement, les applications IBM i d\u00e9pendent fortement des applications middleware\/frontend<\/b>, ce qui signifie que le d\u00e9ploiement doit \u00eatre \u00e9troitement synchronis\u00e9 pour \u00e9viter les incoh\u00e9rences dans la production<\/li>\n<\/ul>\n
De plus, le d\u00e9ploiement des artefacts IBM i peut \u00eatre complexe et n\u00e9cessiter des instructions sp\u00e9ciales<\/b> qui peuvent s’appliquer \u00e0 tous les d\u00e9ploiements ou \u00eatre propres \u00e0 des d\u00e9ploiements sp\u00e9cifiques. Un exemple courant de d\u00e9ploiement concerne l’initialisation de nouvelles colonnes ajout\u00e9es \u00e0 une table ; il s’agit \u00e9videmment d’une action unique lorsque la modification de la table est d\u00e9ploy\u00e9e, et cette action est \u00e9galement contenue et g\u00e9r\u00e9e dans le module sp\u00e9cifique.<\/p>\n
Tout compte fait, l’objectif principal \u00e0 atteindre sur IBM i en ce qui concerne l’automatisation du d\u00e9ploiement est de r\u00e9concilier deux objectifs apparemment oppos\u00e9s : d’une part, comment assurer un environnement de production hautement s\u00e9curis\u00e9 et stable, et d’autre part, fournir en permanence des services \u00e0 l’entreprise, avec tous les avantages qu’apporte une v\u00e9ritable approche DevOps !<\/p>\n<\/div>
<\/div>\n2. Tirer parti de la technologie du monde des syst\u00e8mes ouverts<\/h2>\n
Sur les syst\u00e8mes distribu\u00e9s, les r\u00e9f\u00e9rentiels d’artefacts tels que JFrog Artifactory ou Azure Artifacts sont largement utilis\u00e9s<\/b> pour rem\u00e9dier \u00e0 la “d\u00e9connexion de l’environnement”. Cependant, comme de nombreux outils DevOps standards, ces r\u00e9f\u00e9rentiels d’artefacts ne peuvent pas \u00eatre utilis\u00e9s directement \u00e0 partir d’IBM i dans leur forme brute. Ils exigent que la pr\u00e9sentation du contenu r\u00e9el \u00e0 d\u00e9ployer soit dans un format compatible avec IBM i et contienne des m\u00e9tadonn\u00e9es propri\u00e9taires n\u00e9cessaires.<\/p>\n
Dans le monde de l’IBM i, un package commun est un SAVF contenant des objets \u00e0 d\u00e9ployer. Pour une gestion s\u00e9curis\u00e9e du cycle de vie, il doit \u00e9galement y avoir des identificateurs et un manifeste pour permettre la validation du contenu avant le d\u00e9ploiement.<\/p>\n
L’accessibilit\u00e9 des outils standards de gestion d’artefacts \u00e0 partir d’IBM i est devenue une condition essentielle pour DROPS, la solution multiplateforme de gestion des versions d’ARCAD.<\/a><\/b><\/p>\nL’ouverture de la solution DROPS<\/a><\/b> a \u00e9t\u00e9 le facteur cl\u00e9 qui a permis l\u2019int\u00e9gration des processus de pipeline et des outils CI\/CD. Cette ouverture, par le biais d’extensions, de plugins, de CLI et d’API, a permis de b\u00e9n\u00e9ficier \u00e9galement d’outils de gestion d’artefacts. De plus, la solution DROPS \u00e9tant librement param\u00e9trable<\/b>, il est facile de l\u2019adapter aux flux de travail DevOps sp\u00e9cifiques des clients.<\/p>\n<\/div><\/div><\/div>![\"Diagram](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2024\/06\/diagram-drops-i-environment.png\" "\\"diagram-drops-i-environment\\"")
<\/span><\/div>Exemple : Configuration de DROPS<\/a> dans des environnements IBM i isol\u00e9s (avec ARCAD\/Azure DevOps)<\/em><\/p>\n<\/div>
Auparavant, le d\u00e9ploiement des applications s’effectuait g\u00e9n\u00e9ralement \u00e0 partir d’un serveur central connect\u00e9 \u00e0 tous les syst\u00e8mes concern\u00e9s. Cependant, dans le contexte actuel de s\u00e9curit\u00e9 accrue, il existe une demande croissante de d\u00e9ploiement dans des environnements de production enti\u00e8rement s\u00e9par\u00e9s du d\u00e9veloppement, fonctionnant ind\u00e9pendamment sur un r\u00e9seau isol\u00e9.<\/b> Cette pratique est devenue fondamentale en mati\u00e8re de s\u00e9curit\u00e9 et vise \u00e0 prot\u00e9ger les syst\u00e8mes critiques et \u00e0 maintenir l’int\u00e9grit\u00e9 des activit\u00e9s de l’entreprise.<\/p>\n
Cependant, peu importe o\u00f9 vous en \u00eates dans votre parcours DevOps, le d\u00e9ploiement d’applications dans des environnements ” isol\u00e9s ” pose des d\u00e9fis sp\u00e9cifiques, en particulier pour les plates-formes IBM i.<\/b> Historiquement, cette t\u00e2che \u00e9tait accomplie \u00e0 l’aide de supports physiques tels que des bandes et des DVD, dans une sorte de ” slow motion “. Cependant, dans un environnement num\u00e9rique contemporain au rythme acc\u00e9l\u00e9r\u00e9, de nouvelles options sont apparues, comblant le foss\u00e9 entre les m\u00e9thodes de d\u00e9ploiement traditionnelles et modernes.<\/p>\n<\/div> Le d\u00e9ploiement d’applications sur la plate-forme IBM i requiert une attention particuli\u00e8re en raison de son architecture et de son environnement d’exploitation uniques.<\/b> Par ailleurs, \u00e9tant donn\u00e9 que de nombreuses applications IBM i sont essentielles aux activit\u00e9s de l’entreprise, les mises \u00e0 jour de production n\u00e9cessitent souvent des processus adapt\u00e9s et optimis\u00e9s sp\u00e9cifiques \u00e0 l’IBM i.<\/p>\n Ceux qui d\u00e9couvrent la plate-forme IBM i seront peut-\u00eatre surpris de l’apprendre :<\/b><\/p>\n De plus, le d\u00e9ploiement des artefacts IBM i peut \u00eatre complexe et n\u00e9cessiter des instructions sp\u00e9ciales<\/b> qui peuvent s’appliquer \u00e0 tous les d\u00e9ploiements ou \u00eatre propres \u00e0 des d\u00e9ploiements sp\u00e9cifiques. Un exemple courant de d\u00e9ploiement concerne l’initialisation de nouvelles colonnes ajout\u00e9es \u00e0 une table ; il s’agit \u00e9videmment d’une action unique lorsque la modification de la table est d\u00e9ploy\u00e9e, et cette action est \u00e9galement contenue et g\u00e9r\u00e9e dans le module sp\u00e9cifique.<\/p>\n Tout compte fait, l’objectif principal \u00e0 atteindre sur IBM i en ce qui concerne l’automatisation du d\u00e9ploiement est de r\u00e9concilier deux objectifs apparemment oppos\u00e9s : d’une part, comment assurer un environnement de production hautement s\u00e9curis\u00e9 et stable, et d’autre part, fournir en permanence des services \u00e0 l’entreprise, avec tous les avantages qu’apporte une v\u00e9ritable approche DevOps !<\/p>\n<\/div> Sur les syst\u00e8mes distribu\u00e9s, les r\u00e9f\u00e9rentiels d’artefacts tels que JFrog Artifactory ou Azure Artifacts sont largement utilis\u00e9s<\/b> pour rem\u00e9dier \u00e0 la “d\u00e9connexion de l’environnement”. Cependant, comme de nombreux outils DevOps standards, ces r\u00e9f\u00e9rentiels d’artefacts ne peuvent pas \u00eatre utilis\u00e9s directement \u00e0 partir d’IBM i dans leur forme brute. Ils exigent que la pr\u00e9sentation du contenu r\u00e9el \u00e0 d\u00e9ployer soit dans un format compatible avec IBM i et contienne des m\u00e9tadonn\u00e9es propri\u00e9taires n\u00e9cessaires.<\/p>\n Dans le monde de l’IBM i, un package commun est un SAVF contenant des objets \u00e0 d\u00e9ployer. Pour une gestion s\u00e9curis\u00e9e du cycle de vie, il doit \u00e9galement y avoir des identificateurs et un manifeste pour permettre la validation du contenu avant le d\u00e9ploiement.<\/p>\n L’accessibilit\u00e9 des outils standards de gestion d’artefacts \u00e0 partir d’IBM i est devenue une condition essentielle pour DROPS, la solution multiplateforme de gestion des versions d’ARCAD.<\/a><\/b><\/p>\n L’ouverture de la solution DROPS<\/a><\/b> a \u00e9t\u00e9 le facteur cl\u00e9 qui a permis l\u2019int\u00e9gration des processus de pipeline et des outils CI\/CD. Cette ouverture, par le biais d’extensions, de plugins, de CLI et d’API, a permis de b\u00e9n\u00e9ficier \u00e9galement d’outils de gestion d’artefacts. De plus, la solution DROPS \u00e9tant librement param\u00e9trable<\/b>, il est facile de l\u2019adapter aux flux de travail DevOps sp\u00e9cifiques des clients.<\/p>\n<\/div><\/div><\/div> Exemple : Configuration de DROPS<\/a> dans des environnements IBM i isol\u00e9s (avec ARCAD\/Azure DevOps)<\/em><\/p>\n<\/div>Sommaire<\/h2>\n
\n
1. Les d\u00e9fis propres au d\u00e9ploiement d’applications sur IBM i<\/h2>\n
\n
\n
\n
\n
\n
\n
2. Tirer parti de la technologie du monde des syst\u00e8mes ouverts<\/h2>\n
<\/span><\/div>