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.
