L'architecture, et l'urbanisation des systèmes informatiques existent depuis que l'informatique existe. Mais les différents rôles du métier d'architecture sont devenus cruciaux aujourd'hui, en raison de la diversité, et de la complexité des plateformes. Je partage ici mes lectures, et mes réflexions sur les technologies, mais également sur les méthodes (TOGAF® notamment)
Un architecte dispose d’un certain nombre d’outils pour structurer ses études. Les concepts de style d’architecture (architecture styles), de modèle d’architecture (architecture pattern), et de modèle de conception (design pattern) y tiennent une place prépondérante. Ils constituent, à la fois des outils techniques, en proposant des solutions éprouvées, mais également des outils de communication, en fournissant une base de travail, et un vocabulaire commun.
J’ai travaillé sur le dossier sur GIT lorsque j’ai démarré la migration de ce site vers Hugo, et son hébergement sur Netlify. Après la théorie exposée dans le dossier, passons à un cas d’usage, avec la gestion d’une site « Hugo » avec les outils GIT / GitHub / Netlify. Comment gérer le contenu, et le thème ? Quels flows peut-on utiliser pour maintenir et développer un site Hugo ? Coment utiliser les sous-modules ?
Dans un langage de modélisation comme Archimate, les relations contribuent en grande partie à donner un sens au modèle. Après avoir aborder la structure du langage Archimate®, nous allons maintenant parler des 11 relations que propose Archimate.
Avec les cinq premiers épisodes, nous avons abordés les fonctionnalités les plus courantes de GIT: les dépôts locaux, les commandes de base, les branches, ainsi que les dépôts distants. Nous allons maintenant décrire des fonctionnalités un peu moins courantes. L’utiisation des sous-modules ne répond qu’à des besoins particuliers, lorsque la taille du projet devient importante, ou tout simplement lorsque l’application développée le nécessite.
Avec le précédent article, j’ai parcouru très rapidement les différents éléments qui composent Archimate®, sans entrer dans les détails, ni donner une sémantique à ce langage. Dans cet article, nous allons entrer dans le vif du sujet, en expliquant la syntaxe du langage, comment sont structurés les éléments, et comment ils interfèrent entre eux. Nous enchaînerons ensuite avec les relations.
J’ai terminé l’article précédent avec quelques questionnements sur la méthodologie. En effet, si gérer son code reste relativement simple pour un développeur isolé, les choses se compliquent un peu dans le cadre d’un travail en équipe. Il s’agit, d’une part, de ne pas perdre de temps dans la gestion des fusions (git merge), et d’autre part, de ne pas perdre de code, ou de ne pas pousser en production du code buggé. Afin d’éviter les multiples écueils possibles, il existe plusieurs méthodes de travail avec GIT, que l’on appelle flux de travail (workflow). Je vais vous présenter quelques-unes de ces méthodes.
Les 3 premiers épisodes de notre série, se focalisaient sur les dépôts locaux, dont chaque développeur dispose sur sa machine. Nous allons découvrir maintenant les dépôts centraux / distants (central / remote repositories), comprendre ce que l’on peut en attendre, et voir les quelques commandes supplémentaires qu’il faut connaître.
Après avoir passé en revue les bases de GIT, ainsi que les commandes de base, ce troisième épisode va traiter des branches. Cette fonctionnalité est probablement l’une des plus importante de GIT car, en permettant une « parallélisation » des développements, elles facilitent le travail en équipe.
Liste des sources (sites / livres / …) cités en référence dans les articles de la section « Architecture ».
Dans l’article précédent, nous avons vu les grands principes de GIT, en décrivant les différentes étapes dans l’utilisation de ce produit. Nous allons, dans cet épisode 2, rentrer un peu plus dans le détail, en suivant un flux de développement, et en parcourant les commandes GIT les plus répandues. Nous resterons, pour l’instant, au niveau des dépôts locaux, et dans une branche unique.
Avec des outils comme Hugo , et son écosystème, une bonne connaissance de git devient vite indispensable. Il se trouve que ce sujet est également apparu côté professionnel. J’avais quelques lacunes sur le sujet : j’en ai donc profité pour me remettre à niveau. J’entame une série d’articles sur cet outil, en démarrant par quelques concepts, et un exemple.
J’ai publié, il y a quelques mois, un article sur les éléments de motivation de Archimate. Je n’ai pas fait de présentation détaillée de ce langage de modélisation. Je profite de ma mise à niveau sur la version 3.1 pour vous présenter ce langage.
Résumée très grossièrement, une étude d’architecture consiste principalement à décrire et comprendre un cahier des charges, ainsi que son environnement, proposer des alternatives, comparer ses alternatives, et conclure. Même si l’étude est détaillée, il est parfois difficile de fournir une conclusion claire, une explication des choix, réellement exhaustive et complète. Les explications sont données, l’étude contient bien une comparaison des différentes alternatives, des tableaux pour/contre, des estimations financières … mais lorsque nous relisons la conclusion quelques semaines, ou quelques mois après, nous avons du mal à comprendre les décisions prises, il manque des éléments.