@@ -492,7 +492,7 @@
* Être interrompus et relancés (**atomicité**)
* [Cohabiter avec d'autres](annexe/iac-cohabitation.html) (~orthogonalité)
* Être testés par exemple avec des environnements de qualification et de pré-production.
-* Permettre à la fois la mise à jour du système et sa reconstruction.
+* Permettre à la fois la mise à jour du système et sa reconstruction
Nous privilégierons **une approche déclarative** à une approche impérative pour faciliter la mise en oeuvre de ces principes.
@@ -502,7 +502,7 @@
### Quels pré-requis sur l'infrastructure?
-L'approche IaC laissera une grande liberté de choix dans les outils du cadre technique dès lors qu'ils sont **compatibles avec l'automatisation**. Il conviendra principalement d'**être attentif aux méthodes de configuration disponibles** (1) :
+L'approche IaC laissera une grande liberté de choix dans les **outils du cadre technique** dès lors qu'ils sont **compatibles avec l'automatisation**. Il conviendra principalement d'**être attentif aux méthodes de configuration disponibles** (1) :
* La configuration est basée sur des **variables d'environnements**?
* La configuration est basée sur des **fichiers de configuration**?
@@ -521,7 +521,7 @@
En fonction des possibilités offertes par l'infrastructure et de la politique de l'entreprise, l'**automatisation pourra être partielle** mais il faudra **être conscient des conséquences**.
-A titre d'exemple, **si la configuration du reverse proxy/load balancer n'est pas automatisée** :
+En particulier, **si la configuration du reverse proxy/load balancer n'est pas automatisée** :
* Comment pourrez vous **avoir un système qui s'adapte à la charge**?
* Comment pourrez vous **éviter les indisponibilités pendant les déploiements de nouvelles versions**?
@@ -558,7 +558,7 @@
* Les rôles habilités à valider les *pull request*
* Résoudre des problématiques de **traçabilité des déploiements** :
* Qui a lancé quelle version du script de déploiement?
- * Qui a proposé/validé la configuration?
+ * Qui a proposé/validé la modification?
GitOps est ainsi une illustration de l'utilisation du concept de **pull request** en lieu et place d'un processus de validation plus traditionnel.
@@ -612,7 +612,10 @@
Nous remarquerons par exemple :
* Des **schemas as code** avec des outils tels [Diagrams](https://diagrams.mingrammer.com/docs/getting-started/examples)
-* Des **standards as code** (ex : [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs))
+* Des **standards as code** :
+ * [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs)
+ * [opengeospatial/ogcapi-features](https://github.com/opengeospatial/ogcapi-features?tab=readme-ov-file#ogc-api---features)
+ * ...
* Des **référentiels as code** quand la volumétrie le permet :
* [BaseAdresseNationale/codes-postaux](https://github.com/BaseAdresseNationale/codes-postaux#codes-postaux)
* [gregoiredavid/france-geojson](https://github.com/gregoiredavid/france-geojson#france-geojson)
diff --git a/docs/vm.html b/docs/vm.html
index 98f519a..e5570cd 100644
--- a/docs/vm.html
+++ b/docs/vm.html
@@ -29,7 +29,7 @@
* [PostgreSQL](https://www.postgresql.org/) avec l'extension [PostGIS](https://postgis.net/) pour stocker des données géographiques.
* [GeoServer](https://geoserver.org/) pour diffuser ces données en WMS et WFS.
-Nous appellerons le système résultant **GeoStack** (afin d'avoir un nom de base pour le dépôt dédié au déploiement : `geostack-deploy`)
+Nous appellerons le système résultant **GeoStack** (afin d'avoir un nompour le dépôt dédié au déploiement : `geostack-deploy`).
---
@@ -82,14 +82,16 @@
Dans le cas où il convient de créer un livrable pour sa propre application, nous remarquerons que :
-* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
+* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et de l'OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
* Packager des applications telles PostgreSQL est un métier (construire et maintenir des .deb ou .rpm dans les règles de l'art n'est pas trivial).
* Dans le cas des **langages interprétés** (NodeJS, PHP...) :
* Nous pourrons nous contenter en guise de livrable d'une simple archive (**.zip avec le code de la version + les dépendances**)
- * Nous pourrons aussi facilement produire des .deb ou .rpm avec des outils tels [FPM](https://fpm.readthedocs.io)
+ * Nous pourrons aussi facilement produire des .deb avec des outils tels [FPM](https://fpm.readthedocs.io) (1)
Nous n'entrerons pas trop dans le détail (*spoiler* : nous verrons comment l'utilisation de conteneurs solutionne ce problème)
+> (1) Voir [github.com - IGNF/validator - build-deb.sh](https://github.com/IGNF/validator/blob/master/build-deb.sh) pour un exemple trivial (sans script pré/post-installation).
+
---
## La création d'un livrable (4/4)
diff --git a/src/slides/principes.md b/src/slides/principes.md
index a903407..73b869a 100644
--- a/src/slides/principes.md
+++ b/src/slides/principes.md
@@ -547,7 +547,7 @@ Cette approche permettra de :
* Les rôles habilités à valider les *pull request*
* Résoudre des problématiques de **traçabilité des déploiements** :
* Qui a lancé quelle version du script de déploiement?
- * Qui a proposé/validé la configuration?
+ * Qui a proposé/validé la modification?
GitOps est ainsi une illustration de l'utilisation du concept de **pull request** en lieu et place d'un processus de validation plus traditionnel.
@@ -601,7 +601,10 @@ Au final, il sera très vite tentant de gérer un maximum d'élément à l'aide
Nous remarquerons par exemple :
* Des **schemas as code** avec des outils tels [Diagrams](https://diagrams.mingrammer.com/docs/getting-started/examples)
-* Des **standards as code** (ex : [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs))
+* Des **standards as code** :
+ * [cnigfr - PCRS](https://github.com/cnigfr/PCRS#pcrs)
+ * [opengeospatial/ogcapi-features](https://github.com/opengeospatial/ogcapi-features?tab=readme-ov-file#ogc-api---features)
+ * ...
* Des **référentiels as code** quand la volumétrie le permet :
* [BaseAdresseNationale/codes-postaux](https://github.com/BaseAdresseNationale/codes-postaux#codes-postaux)
* [gregoiredavid/france-geojson](https://github.com/gregoiredavid/france-geojson#france-geojson)
diff --git a/src/slides/vm.md b/src/slides/vm.md
index a37a425..a85a18b 100644
--- a/src/slides/vm.md
+++ b/src/slides/vm.md
@@ -18,7 +18,7 @@ Nous allons voir en pratique comment se passe le déploiement d'une application
* [PostgreSQL](https://www.postgresql.org/) avec l'extension [PostGIS](https://postgis.net/) pour stocker des données géographiques.
* [GeoServer](https://geoserver.org/) pour diffuser ces données en WMS et WFS.
-Nous appellerons le système résultant **GeoStack** (afin d'avoir un nom de base pour le dépôt dédié au déploiement : `geostack-deploy`)
+Nous appellerons le système résultant **GeoStack** (afin d'avoir un nompour le dépôt dédié au déploiement : `geostack-deploy`).
---
@@ -71,14 +71,16 @@ Pour le déploiement d'une application en PRODUCTION, il est important de :
Dans le cas où il convient de créer un livrable pour sa propre application, nous remarquerons que :
-* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
+* Il existe une **grande variété de formats de livrables possibles** en fonction des technologies et de l'OS cible (c.f. [format supportés par Nexus qui permet de créer différents types de dépôt](https://help.sonatype.com/repomanager3/nexus-repository-administration/formats) )
* Packager des applications telles PostgreSQL est un métier (construire et maintenir des .deb ou .rpm dans les règles de l'art n'est pas trivial).
* Dans le cas des **langages interprétés** (NodeJS, PHP...) :
* Nous pourrons nous contenter en guise de livrable d'une simple archive (**.zip avec le code de la version + les dépendances**)
- * Nous pourrons aussi facilement produire des .deb ou .rpm avec des outils tels [FPM](https://fpm.readthedocs.io)
+ * Nous pourrons aussi facilement produire des .deb avec des outils tels [FPM](https://fpm.readthedocs.io) (1)
Nous n'entrerons pas trop dans le détail (*spoiler* : nous verrons comment l'utilisation de conteneurs solutionne ce problème)
+> (1) Voir [github.com - IGNF/validator - build-deb.sh](https://github.com/IGNF/validator/blob/master/build-deb.sh) pour un exemple trivial (sans script pré/post-installation).
+
---
## La création d'un livrable (4/4)