+
+ 
](../assets/TLSExpiration/NSD.png)
-
-* Dans le champ “Service Request Details” spécifiez:
- * Si votre application est Intranet ou Internet
- * La date d’expiration de votre certificat TLS.
- * L’URL de votre site de production.
- * La liste des noms de serveur web de production associés.
-
-Voici un modèle que vous pouvez utiliser pour soumettre votre ticket NSD. Remplacez simplement dans ce modèle les %_variables_% par la valeur pertinente dans votre cas.
-
->Bonjour,
->
->Notre application est: %_intranet_or_internet_%
->
->Le certificat TLS pour %_production_url_% expire le %_expiration_date_%.
->
->SVP renouveller le certificats sur les serveurs suivants:
->
->%_server_name_1_%, %_server_name_2_%, %_server_name_3_%, %_server_name_4_%.
+*Le texte français est donné à la suite.*
## For solutions hosted in Shared Services Canada (SSC) the following practice should be implemented.
@@ -154,14 +76,98 @@ To open a Ticket:
* Your production URL.
* List of Producton web server names.
-Here is a template you can use to submit your NSD ticket. Simply replace the %_variables_% with your own values.
+Here is a template you can use to submit your NSD ticket. Simply replace the %*variables*% with your own values.
>Hello,
>
->Our application is: %_intranet_or_internet_%.
+>Our application is: %*intranet_or_internet*%.
>
->Our TLS Certificates for the %_production_url_% will expire on %expiration_date%.
+>Our TLS Certificates for the %*production_url*% will expire on %expiration_date%.
>
>Please renew our TLS certificates for the following web servers:
>
->%_server_name_1_%, %_server_name_2_%, %_server_name_3_%, %_server_name_4_%
+>%*server_name_1*%, %*server_name_2*%, %*server_name_3*%, %*server_name_4*%
+
+---
+
+*Texte français:*
+
+### Pour les solutions hébergées par Services Partagés Canada (SPC), les pratiques suivantes devraient être mises en oeuvre.
+
+Les licences TLS sont renouvelées par SPC automatiquement, sans que l’utilisateur ait à poser une action quelconque. SPC a mis en place une procédure interne pour le renouvellement des licences TLS. Toutefois, il peut se produire exceptionnellement que SPC omette de renouveler une licence TLS, et que cela ait pour effet de provoquer une panne de serveur.
+
+Veuillez ouvrir un ticket NSD si votre certificat TLS expire dans les 14 jours ou moins.
+
+#### Obtenir la date d’expiration de votre certificat TLS
+
+Voici quelques moyens vous permettant de vérifier la date d’expiration de votre certificat TLS.
+
+##### À l’aide d’un navigateur Web:
+
+###### Pour Edge et Chrome:
+
+* Ouvrez le navigateur, afficher une page de votre site web.
+* Ouvrez les outils de développement (généralement en appuyant sur F12), puis sélectionnez l'onglet « Privacy and Security ».
+* Dans la section « Connection », vous trouverez la version du protocole TLS utilisée.
+* Cliquer sur « View certificate » pour obtenir des informations plus détaillées sur le certificat.
+* Assurez-vous que le certificat client a une correspondance avec l'autorité de certification principale de la chaîne de confiance.
+
+
+
+* Relever la date d’expiration du Certificat.
+
+
+
+###### Pour FireFox:
+
+* Ouvrir le navigateur, afficher une page de votre site web.
+* Cliquer sur l’icône représentant un cadenas, et sélectionner la flèche à droite de la fenêtre d’informations.
+
+
+
+* Cliquer sur l’onglet « Plus d’informations ».
+
+
+
+* Relever la date d’expiration du Certificat.
+
+
+
+**Lorsque la date d’expiration du certificat TLS est connue, créer un rappel 14 jours avant cette date d’expiration dans le calendrier d’Outlook. Inclure les développeurs, les conseillers techniques et l’équipe de support 24-7.**
+
+##### À l’aide du code source:
+
+Vous pouvez implémenter une procédure de surveillance de la date d’expiration d’un certificat TLS avec quelques lignes de code. Votre équipe peut inclure cette vérification dans votre solution personnalisée effectuant la surveillance des certificats TLS.
+
+SDS propose plusieurs exemples de code que vous pouvez utiliser dans votre solution (Java, C# & .Net). La fonction utilisée dans ces exemples requiert l’URL qui doit être vérifiée, représentée par une chaîne, et retourne le nombre de jours restants avant l’expiration du certificat TLS. Dans votre solution de surveillance, vous pouvez notamment utiliser l’exemple que vous préférez pour afficher un message, ou encore envoyer une notification lorsque le nombre de jours avant expiration est inférieur à 14.
+
+Voici le lien vers les [exemples de code](https://gccode.ssc-spc.gc.ca/iitb-dgiit/sds/devcop-code-snippets/-/snippets "exemples de code").
+
+#### Ticket NSD pour le renouvellement d’un certificat TLS
+
+**REMARQUE: Ouvrez un ticket NSD seulement si votre certificat TLS expire dans 14 jours ou moins. Vérifiez toujours que le certificat n’a pas déjà été renouvelé avant de soumettre un ticket NSD.**
+
+Pour soumettre un Ticket:
+
+* Aller dans [NSD](https://iservice.prv/eng/imit/nsd/index.shtml "NSD")
+* Entrer ‘Submit a Service Request or Report an Incident to Shared Services Canada (SSC)” dans la première zone de texte, et sélectionner les options comme dans l'image ci-dessous.
+
+[](../assets/TLSExpiration/NSD.png)
+
+* Dans le champ “Service Request Details” spécifiez:
+ * Si votre application est Intranet ou Internet
+ * La date d’expiration de votre certificat TLS.
+ * L’URL de votre site de production.
+ * La liste des noms de serveur web de production associés.
+
+Voici un modèle que vous pouvez utiliser pour soumettre votre ticket NSD. Remplacez simplement dans ce modèle les %*variables*% par la valeur pertinente dans votre cas.
+
+>Bonjour,
+>
+>Notre application est: %*intranet_or_internet*%
+>
+>Le certificat TLS pour %*production_url*% expire le %*expiration_date*%.
+>
+>SVP renouveller le certificats sur les serveurs suivants:
+>
+>%*server_name_1*%, %*server_name_2*%, %*server_name_3*%, %*server_name_4*%.
diff --git a/docs/_guides/a11y-web-extensions.md b/docs/_guides/a11y-web-extensions.md
index bcd51c6..27b5d35 100644
--- a/docs/_guides/a11y-web-extensions.md
+++ b/docs/_guides/a11y-web-extensions.md
@@ -6,6 +6,8 @@ summary: How to download Accessibility web browser extensions
date: 2026-01-15
---
+*Le texte français est donné à la suite.*
+
## Links for Accessibility testing Browser extensions
### Accessibility Insights
@@ -55,3 +57,63 @@ Add the [Axe DevTools Browser Extension](https://www.deque.com/axe/devtools/exte
Add your HTML source code directly to the **Validate by Direct Input** field in the [W3C Markup Validation Service](https://validator.w3.org/#validate_by_input "W3C Markup Validation Service"), to validate HTML compliance:
[
](../assets/a11y-web-extensions/W3C-html-validator.png)
+
+---
+
+*Texte français:*
+
+### Liens pour les extensions de navigateur de test d'accessibilité
+
+
+#### Accessibility Insights
+
+
+Pour demander l'installation d'Insights pour **Windows** sur votre poste de travail à partir du catalogue d'applications NSD :
+
+- Accédez à [NSD](https://iservice.prv/eng/imit/nsd/index.shtml "NSD")
+- Dans le **Catalogue d'applications**, cliquez sur l'onglet **Logiciels commerciaux**, puis sélectionnez le lien *Accessibility Insights for Windows* et cliquez sur *Installer*.
+- L'installation devrait prendre environ 2 jours.
+
+Ajoutez l'[extension de navigateur Accessibility Insights](https://accessibilityinsights.io/downloads/ "Extension de navigateur Accessibility Insights") directement dans votre navigateur (pour Chrome et Edge) :
+
+[
](../assets/a11y-web-extensions/Insights_1.png)
+
+[
](../assets/a11y-web-extensions/Insights_2.png)
+
+[
](../assets/a11y-web-extensions/Insights_3.png)
+
+[
](../assets/a11y-web-extensions/Insights_4.png)
+
+
+#### WAVE
+
+
+Ajoutez l'[extension de navigateur WAVE](https://wave.webaim.org/extension/ "Extension de navigateur WAVE") directement dans votre navigateur (pour Chrome, Edge, Firefox) :
+
+[
](../assets/a11y-web-extensions/WAVE_2.png)
+
+[
](../assets/a11y-web-extensions/WAVE_3.png)
+
+[
](../assets/a11y-web-extensions/WAVE_4.png)
+
+[
](../assets/a11y-web-extensions/WAVE_5.png)
+
+
+#### Axe Dev Tools
+
+
+Ajoutez l'[extension de navigateur Axe DevTools](https://www.deque.com/axe/devtools/extension/ "Extension de navigateur Axe DevTools") directement dans votre navigateur (pour Chrome, Edge, Firefox) :
+
+[
](../assets/a11y-web-extensions/Axe_1_Note_ScrollToBottomOfPage.png)
+
+[
](../assets/a11y-web-extensions/Axe_2.png)
+
+[
](../assets/a11y-web-extensions/Axe_3.png)
+
+[
](../assets/a11y-web-extensions/Axe_4.png)
+
+#### Validation HTML du W3C
+
+Ajoutez votre code source HTML directement dans le champ **Validate by Direct Input** du [service de validation du balisage du W3C](https://validator.w3.org/#validate_by_input "Service de validation du balisage du W3C"), pour valider la conformité HTML :
+
+[](../assets/a11y-web-extensions/W3C-html-validator.png)
diff --git a/docs/_guides/application-logging.md b/docs/_guides/application-logging.md
index 8ae0e18..f2dac9b 100644
--- a/docs/_guides/application-logging.md
+++ b/docs/_guides/application-logging.md
@@ -6,6 +6,8 @@ summary: Defining the best practices of what, when and where to log in an applic
date: 2011-01-01
---
+*Le texte français est donné à la suite.*
+
## Recommendation
**Scope of the recommendation:** Application Logging
@@ -123,3 +125,125 @@ For apps hosted in OPS or DMZ (Internet), the accessibility of the log files is
* Open a ticket with the National Service Desk (NSD), to be processed by iNET, requesting a copy of the specific log file. This will provide a copy of the current file (up to the minute)).
* It is also possible to request a regular transfer (daily, twice daily, weekly, ...). This process must be configured with the EDS, in collaboration with iNET. This will provide log files from the previous day.
+
+---
+
+*Texte français:*
+
+### Recommandation
+
+**Portée de la recommandation :** Journalisation des applications
+**Hors portée :** Journalisation IIS, Audit
+**Définition :** Un journal d'application est un fichier d'événements enregistrés par une application logicielle. Il contient des erreurs, des événements d'information et des avertissements. Le format et le contenu d'un journal d'application sont déterminés par le développeur du logiciel plutôt que par le système d'exploitation.
+**Utilisation :** Journaliser/enregistrer les événements d'application pour faciliter le dépannage, fournir l'état de santé (de l'application) ou éviter qu'un incident ne s'aggrave.
+**Autre utilisation :** Alerter les groupes techniques lorsqu'un événement spécifique survient.
+
+### 5 meilleures pratiques
+
+* Utilisez un cadriciel de journalisation standard et facilement configurable.
+[NLog](https://nlog-project.org/), [log4j 2](https://logging.apache.org/log4j/2.x/), [log4net](https://logging.apache.org/log4net/), [ELMAH](https://elmah.github.io/), etc., permettent des modifications de configuration plus rapides que les cadriciels codés en dur ou propriétaires.
+* Utilisez un cadriciel de journalisation avec des options de sortie flexibles.
+Affichez les journaux dans la console en développement et centralisez les journaux de production sans modules d'extension ou agents supplémentaires.
+* Ne laissez pas la journalisation bloquer votre application.
+Écrivez les journaux de manière asynchrone avec une mémoire tampon ou une file d'attente afin que l'application continue de fonctionner.
+* Offrez une configuration de journalisation standard pour toutes les équipes.
+Évitez le désordre au fur et à mesure que l'organisation grandit. Commencez par une bonne pratique et laissez les équipes s'en écarter au besoin.
+* N'oubliez pas les journaux des applications patrimoniales.
+Trouvez un moyen de transmettre les journaux des applications existantes, qui sont fréquemment la cause de problèmes opérationnels.
+
+### Quoi journaliser
+
+Les journaux de débogage rapportent généralement des événements d'application utiles pour diagnostiquer un problème. Les enquêtes sur les défaillances d'application nécessitent de répondre aux questions : Qui, Quoi, Quand, Où et Pourquoi :
+
+* Qui utilisait le système lorsqu'il est tombé en panne ?
+* Où dans le code l'application a-t-elle échoué ?
+* Que faisait le système lorsqu'il est tombé en panne ?
+* Quand la défaillance s'est-elle produite ?
+* Pourquoi l'application a-t-elle échoué ?
+
+#### Types de journaux suggérés
+
+* **Fatal (Critique) :** Une erreur/exception inattendue qui compromet la capacité de l'application à fonctionner correctement pour les requêtes subséquentes. (par exemple : « Une exception s'est produite lors du chargement des données d'initialisation, l'application ne sera pas disponible »)
+* **Error (Erreur) :** Une erreur/exception dans l'exécution qui, bien qu'elle ait pu être signalée à l'utilisateur et/ou être bénigne, doit figurer dans le journal à des fins de dépannage. Également utile si le développeur souhaite spécifiquement enregistrer une erreur pour suivre des situations inhabituelles. Les erreurs de validation ou de saisie de données n'en font normalement pas partie. (par exemple : « Échec de la connexion au serveur de secours, enregistrement de la transaction en attente »)
+* **Warning (Avertissement) :** Pas nécessairement une erreur pour l'utilisateur final, mais une situation ou condition inhabituelle s'est produite (par exemple, « Échec de la connexion au serveur principal, tentative de connexion au serveur de secours »)
+* **Information :** Une situation ou condition normale qu'il est utile de consigner dans le journal (par exemple : « Données de référence chargées dans la mémoire cache, expiration dans 12 heures »)
+* **Debug (Débogage) :** Détaille les grandes lignes de l'exécution des fonctions. Comme son nom l'indique, c'est utile à des fins de débogage (par exemple, « Données trouvées dans la mémoire cache, omission du chargement depuis le fichier »)
+* **Trace :** Semblable au débogage, mais à un niveau de détail beaucoup plus fin. Les messages au niveau Trace correspondent souvent aux étapes réelles du pseudo-code de l'algorithme (par exemple : « Vérification si l'utilisateur est du type approprié », « Configuration de l'appel au service utilisateur »)
+
+### Comment journaliser
+
+Évitez d'implémenter des mécanismes de journalisation maison. Les bibliothèques existantes sont très matures et offrent une grande variété de granularités et d'options de configuration. Nous recommandons l'utilisation de bibliothèques de journalisation existantes :
+
+* [NLog](https://nlog-project.org/) pour les environnements de développement .NET
+* [SLF4J API](https://www.slf4j.org/) et [Log4j 2](https://logging.apache.org/log4j/2.x/) pour l'environnement de développement Java
+* [Elmah](https://elmah.github.io/) (Error Logging Module and Handlers for ASP.NET) - Source ouverte
+
+### Quand journaliser
+
+Dans toutes les branches applicatives en utilisant des niveaux de journalisation appropriés selon les besoins d'analyse :
+
+* Dev, INT, UAT, PRF : Granularité plus élevée des journaux
+* Production - situation normale : Granularité plus faible
+* Production - analyse d'un problème : Augmenter progressivement la granularité jusqu'à ce que le problème soit compris.
+
+### Où envoyer les données de journalisation
+
+**Pour le moment, aucune infrastructure n'est disponible pour centraliser nos journaux. Nous pensons que cela pourrait être une excellente initiative pour la DGIIT.**
+
+Les bases de données relationnelles ne sont pas le meilleur endroit pour envoyer des données de journaux. Les bases de données de séries temporelles (TSDB) sont beaucoup plus efficaces pour stocker ces données. Les TSDB à code source ouvert telles qu'[InfluxDB](https://www.influxdata.com/) sont bien mieux adaptées au stockage de données de journaux que les bases de données relationnelles.
+
+La [suite ELK](https://www.elastic.co/products) est une solution populaire pour l'agrégation de journaux. ELK est un acronyme signifiant Elasticsearch, Logstash et Kibana.
+[Elasticsearch](https://www.elastic.co/products/elasticsearch) est un moteur de recherche rapide utilisé pour trouver des données dans de grands ensembles de données.
+[Logstash](https://www.elastic.co/products/logstash) est une plateforme de pipeline de données qui recueille des données de journaux provenant de nombreuses sources et les transmet à une cible de persistance unique.
+[Kibana](https://www.elastic.co/products/kibana) est un outil de visualisation de données et un moteur de recherche web qui s'intègre à Elasticsearch.
+
+#### Emplacement des fichiers journaux
+
+Les emplacements suivants sont définis par la SADE et constituent la norme ministérielle :
+
+* Pour toutes les applications hors production :
+
+```cmd
+ E:\\WebLogs\[SADE-Vertical]\[abréviation application]\[sous-dossiers application au besoin]
+```
+
+* Pour toutes les applications en production :
+
+```cmd
+ E:\\WebLogs\\[abréviation application]\[sous-dossiers application au besoin]
+```
+
+**Note de la SADE :** « Si la structure de répertoires des journaux n'existe pas telle qu'indiquée ci-dessus, l'application doit prendre l'initiative de la créer (à la volée). Il est entendu que le nom et la structure du répertoire doivent être définis dans le Web.Config »
+
+### Contenu du fichier journal
+
+#### Nom de fichier
+
+* 1 fichier par jour : - Plus facile à archiver; - La taille reste réduite (plus facile à charger, donne un aperçu rapide si vous avez reçu plus d'erreurs un jour précis)
+* Le nom de fichier doit inclure : le nom des composants de l'application, la date et le nom du serveur (facilite l'identification lors du rapatriement sur votre poste local)
+
+Ex : APP_NAME_20190930_MLWB200.log
+
+#### Les données du contenu seront déterminées selon les exigences et les besoins. Nous recommandons d'inclure les éléments de données suivants pour chaque enregistrement de journal :
+
+* Date/Heure
+* Nom du service Web
+* Nom du serveur
+* Nom complet
+* AppDomainName
+* Nom du fil d'exécution (Thread)
+* Appelant
+* Message
+* « plus de détails »
+
+#### Contenu sensible
+
+* Les éléments de données de niveau Protégé B ne doivent pas faire partie de l'enregistrement de journal. Au besoin, les données de niveau Protégé B doivent être chiffrées.
+
+### Comment accéder aux journaux ?
+
+Pour les applications hébergées sur l'Intranet, utilisez les dossiers partagés vers l'emplacement des fichiers journaux défini par la SADE.
+Pour les applications hébergées en OPS ou en DMZ (Internet), l'accès aux fichiers journaux se fait uniquement sur demande. 2 options existent :
+
+* Ouvrir un billet auprès du Centre de services national (NSD), qui sera traité par iNET, demandant une copie du fichier journal spécifique. Cela fournira une copie du fichier actuel (à la minute près).
+* Il est également possible de demander un transfert régulier (quotidien, deux fois par jour, hebdomadaire, ...). Ce processus doit être configuré avec les EDS, en collaboration avec iNET. Cela fournira les fichiers journaux de la veille.
diff --git a/docs/_guides/artifactory.md b/docs/_guides/artifactory.md
index 570ed68..f7bc64a 100644
--- a/docs/_guides/artifactory.md
+++ b/docs/_guides/artifactory.md
@@ -6,6 +6,8 @@ summary: Demonstrating rational for the use of Artifactory to improve security a
date: 2019-01-01
---
+*Le texte français est donné à la suite.*
+
SADE has made available the community version of [Artifactory](https://jfrog.com/artifactory/) as a binary management tool for Java applications and libraries. Artifactory is a service that hosts our in house software libraries, as well as acts as a proxy in front of various software library (Maven) repositories.
## Recommendation
@@ -15,10 +17,31 @@ Note that the current version of Artifactory currently does not support Nuget pa
## Benefits
-## Reduce Network Traffic Outside of our Network
+### Reduce Network Traffic Outside of our Network
Another big benefit of this is that since it acts as a proxy between these external binary repositories and our internal build and developer machines we should have less traffic going outside of our network.
-## Integrates into CI/CD Pipelines
+### Integrates into CI/CD Pipelines
Artifactory also integrates into most major build automation tool and will help drive us towards DevSecOps in the department.
+
+---
+
+*Texte français:*
+
+La SADE a mis à disposition la version communautaire d'[Artifactory](https://jfrog.com/artifactory/) comme outil de gestion des binaires pour les applications et bibliothèques Java. Artifactory est un service qui héberge nos bibliothèques logicielles internes et agit comme un mandataire (proxy) devant divers référentiels de bibliothèques logicielles (Maven).
+
+### Recommandation
+
+Il est recommandé aux équipes de développement Java/Maven disposant d'environnements de développement et de compilation sur place (sur site) d'utiliser l'installation SADE d'Artifactory. Artifactory agira également comme proxy pour les référentiels de paquets officiels tels qu'Oracle et Maven Central, gardant la configuration Maven relativement simple sur chaque environnement de développement.
+Veuillez noter que la version actuelle d'Artifactory ne prend pas en charge les paquets Nuget pour le développement .NET Framework/Core. Pour le développement .NET, la recommandation est d'utiliser le flux Nuget d'ADO ou, après s'être assuré que les binaires ne contiennent aucune information sensible comme des clés de chiffrement ou des mots de passe, ils peuvent être hébergés sur nuget.org. Pour plus d'informations : [Guide d'utilisation Nuget d'EDSC](nugetuserguide.html)
+
+### Avantages
+
+#### Réduire le trafic réseau à l'extérieur de notre réseau
+
+Un autre avantage majeur est que, puisqu'il agit comme intermédiaire entre ces référentiels binaires externes et nos machines internes de compilation et de développement, nous réduisons le volume de trafic sortant de notre réseau.
+
+#### S'intègre aux pipelines CI/CD
+
+Artifactory s'intègre également à la plupart des principaux outils d'automatisation de compilation et nous aidera à progresser vers le DevSecOps au sein du ministère.
diff --git a/docs/_guides/broken-links.md b/docs/_guides/broken-links.md
index 0f33e14..42d0f25 100644
--- a/docs/_guides/broken-links.md
+++ b/docs/_guides/broken-links.md
@@ -6,6 +6,8 @@ summary: Best Practices on how to prevent and detect broken links.
date: 2022-10-21
---
+*Le texte français est donné à la suite.*
+
## Background
Broken links on your website can create a bad user experience and can also lower the ranking of your web site in search engine optimization (SEO).
@@ -48,3 +50,50 @@ You can validate your internal and external links manually by using an online li
You can add an existing library to your project to check for broken links on your site automatically, either from Nuget(.NET) or NPM(Javascript).
You can also refactor your code to automatically check your website for broken links.
+
+---
+
+*Texte français:*
+
+### Contexte
+
+Les liens rompus sur votre site web peuvent créer une mauvaise expérience utilisateur et réduire le classement de votre site dans l'optimisation pour les moteurs de recherche (SEO).
+Vous pouvez éviter cela grâce à la prévention et à la détection.
+
+### Qu'est-ce qu'un lien rompu ?
+
+Voici quelques exemples de liens rompus :
+
+* un site web ou une page qui n'existe plus
+* un site web ou une page dont l'URL a été déplacée sans redirection
+* un site web dont certains éléments de page sont brisés
+
+### Comment y remédier
+
+#### Prévention
+
+Vous pouvez améliorer la qualité de votre site web en choisissant des références réputées et bien établies.
+
+##### Liens externes :
+
+Il s'agit de liens pointant vers un site web externe. En tant que propriétaire, vous devriez choisir des liens fiables et informatifs pour améliorer la qualité et le classement de votre site web.
+
+##### Rétroliens (Backlinks) :
+
+Il s'agit de sites web externes qui pointent vers votre site. Vous n'avez que peu de contrôle sur la manière dont ils créent ces liens. Cependant, en publiant du contenu utile sur votre site, vous pouvez améliorer votre visibilité dans les résultats de recherche.
+
+##### Créer une page 404 personnalisée pour votre site :
+
+Une bonne page d'erreur 404 personnalisée peut réduire la frustration de l'utilisateur en lui expliquant la situation avec tact et en l'aidant à retourner sur votre page d'accueil ou à signaler facilement le problème. Ajouter un peu de créativité et d'humour est également bénéfique.
+
+* indiquer clairement que la page n'est pas disponible (**Erreur 404 : Page introuvable**)
+* ajouter des instructions claires sur la façon de revenir à votre site web (ex. : page d'accueil, page de contact)
+* si votre site ne dispose pas d'une fonctionnalité intégrée pour les pages d'erreur 404, vous devez configurer votre serveur web pour afficher le contenu de la page d'erreur personnalisée
+
+#### Détection
+
+Vous pouvez valider vos liens internes et externes manuellement en utilisant un vérificateur de liens en ligne, tel que le [vérificateur de liens W3C](https://dev.w3.org/perl/modules/W3C/LinkChecker/docs/checklink).
+
+Vous pouvez ajouter une bibliothèque existante à votre projet pour vérifier automatiquement les liens rompus sur votre site, à partir de Nuget (.NET) ou de NPM (Javascript).
+
+Vous pouvez également adapter votre code pour vérifier automatiquement la présence de liens rompus sur votre site web.
diff --git a/docs/_guides/change-logs.md b/docs/_guides/change-logs.md
index 3e4069e..fb11470 100644
--- a/docs/_guides/change-logs.md
+++ b/docs/_guides/change-logs.md
@@ -6,6 +6,8 @@ summary: A layout for how to write consistent and informative change logs that a
date: 2020-03-04
---
+*Le texte français est donné à la suite.*
+
{{ page.summary }}
## Background
@@ -20,12 +22,12 @@ Notes should be easy to read and convey a clear message to the reader.
The change log should be a list of changes made for each release of a product.
The log should be stored in the root of the products sourcecode and called `CHANGELOG.md`.
-All changes that are listed should indicate the _public_ property, function, or feature name that is changing in clear and to-the-point detail providing a link (issue number, documentation, commit) for more details on the change.
-By _public_ it mean the name that the users of the solution would know or recognize.
+All changes that are listed should indicate the *public* property, function, or feature name that is changing in clear and to-the-point detail providing a link (issue number, documentation, commit) for more details on the change.
+By *public* it mean the name that the users of the solution would know or recognize.
## API logs
-APIs should follow this logging template as they generally require strict versioning schemes to identify _breaking_ changes.
+APIs should follow this logging template as they generally require strict versioning schemes to identify *breaking* changes.
[Semantic Versioning](https://semver.org/ ) is the most common and recommend approach to versioning, so this templates assumes that it is being used.
> ### 0.0.0 - Release Name
@@ -50,12 +52,12 @@ It could optionally include the `- Release Name` indicating a release name.
If you are adding to this section you should be updating the major version number (**0**.0.0) in your version.
**`New features and improvements`:** This section lists all new features that have been added and any improvements made to existing features.
-Changes listed here should not cause the an implementer to make manual changes when updating; if they do it should be moved to _Breaking changes_.
+Changes listed here should not cause the an implementer to make manual changes when updating; if they do it should be moved to *Breaking changes*.
If you are adding to this section you should be updating the minor version number (0.**0**.0) in your version.
If there are no new features, that should still be indicated in this section.
**`Fixes`:** This section lists any changes made to fix issues, improving back end operations, or patching other dependencies .
-Changes listed here should not cause the an implementer to make manual changes when updating; if they do it should be moved to _Breaking changes_.
+Changes listed here should not cause the an implementer to make manual changes when updating; if they do it should be moved to *Breaking changes*.
If you are adding to this section you should be updating the patch version number (0.0.**0**) in your version.
## Application Logs
@@ -63,7 +65,7 @@ If you are adding to this section you should be updating the patch version numbe
Application Logs are different from API logs because they speak to a different audience, the users of the application (not developers).
They should avoid making references to details of code, like property names and instead make references to field names the user would see.
Each listed change should be a link to documentation about the change.
-What you are describing in the change should be tailored to help _sell_ the product.
+What you are describing in the change should be tailored to help *sell* the product.
> ### Release Name - February 15, 2020
>
@@ -92,7 +94,7 @@ It could optionally include the `- February 15, 2020` (a date stamp) to indicate
**`New Features`:** This section includes new features added to the application.
There should be a link to the detailed documentation of how the features works.
-_The whole list item could be the link._
+*The whole list item could be the link.*
**`Improvements`:** The improvement section will tell users about the changes made to improve the existing features of the application.
This section will help users understand why they should look for the new and improved features.
@@ -103,3 +105,105 @@ These fixes may not be part of the latest deployment, as they were patched previ
**`Operations`:** These are any changes made related to the service of the application.
These changes wouldn't impact users directly.
+
+---
+
+*Texte français:*
+
+Une mise en page pour rédiger des journaux de modifications cohérents et informatifs, significatifs pour ceux qui les lisent.
+
+### Contexte
+
+Avoir un bon journal des modifications (changelog) peut être essentiel pour les personnes utilisant vos applications et services.
+Il leur permet de savoir ce qui a changé et ce qu'elles doivent adapter.
+Veiller à ce qu'il reste cohérent et clair aide à mieux comprendre les changements apportés.
+Les notes doivent être faciles à lire et transmettre un message clair au lecteur.
+
+### Journaux généraux
+
+Le journal des modifications doit être une liste des changements apportés à chaque version d'un produit.
+Le fichier doit être conservé à la racine du code source du produit et s'appeler `CHANGELOG.md`.
+
+Tous les changements répertoriés doivent indiquer le nom de la propriété, fonction ou fonctionnalité *publique* modifiée de manière claire et concise, en fournissant un lien (numéro d'élément, documentation, commit) pour plus de détails sur le changement.
+Par *publique*, on entend le nom que les utilisateurs de la solution connaissent ou reconnaissent.
+
+### Journaux d'API
+
+Les API devraient suivre ce modèle de journalisation, car elles requièrent généralement des schémas de gestion sémantique de version stricts pour identifier les changements majeurs ou incompatibles (*breaking changes*).
+La [gestion sémantique de version (SemVer)](https://semver.org/) est l'approche la plus courante et recommandée, ce modèle suppose donc son utilisation.
+
+> #### 0.0.0 - Nom de la version
+>
+> ##### Changements incompatibles (Breaking changes)
+>
+> - `PropertyX` dans `FunctionG` retourne maintenant des caractères alphanumériques - corrige #00
+>
+> ##### Nouvelles fonctionnalités et améliorations
+>
+> - Ajout de `FunctionT` pour simplifier les appels vers la base de données - complète #00
+>
+> ##### Correctifs
+>
+> - `PropertyJ` dans `FunctionB` est analysé correctement - corrige #00
+>
+
+**Nom de la version `0.0.0`** indique la version publiée.
+Il peut éventuellement inclure `- Nom de la version` pour préciser le nom de la version.
+
+**`Changements incompatibles (Breaking changes)` :** Cette section répertorie tous les changements nécessitant une intervention de l'intégrateur de votre solution pour effectuer la mise à jour.
+Si vous ajoutez un élément à cette section, vous devez incrémenter le numéro de version majeure (**0**.0.0).
+
+**`Nouvelles fonctionnalités et améliorations` :** Cette section répertorie toutes les nouvelles fonctionnalités ajoutées ainsi que les améliorations apportées aux fonctionnalités existantes.
+Les changements listés ici ne devraient pas obliger l'intégrateur à effectuer des modifications manuelles lors de la mise à jour; si c'est le cas, ils doivent être déplacés vers *Changements incompatibles*.
+Si vous ajoutez un élément à cette section, vous devez incrémenter le numéro de version mineure (0.**0**.0).
+S'il n'y a pas de nouvelle fonctionnalité, cela doit quand même être indiqué dans cette section.
+
+**`Correctifs (Fixes)` :** Cette section répertorie les correctifs apportés à des bogues, les améliorations des opérations d'arrière-plan ou les mises à niveau de dépendances.
+Les changements indiqués ici ne doivent pas forcer l'intégrateur à des modifications manuelles; si c'est le cas, ils doivent être déplacés vers *Changements incompatibles*.
+Si vous ajoutez un élément à cette section, vous devez incrémenter le numéro de correctif (0.0.**0**).
+
+### Journaux d'application
+
+Les journaux d'application diffèrent des journaux d'API car ils s'adressent à un public différent : les utilisateurs de l'application (et non les développeurs).
+Ils doivent éviter de faire référence à des détails de code comme des noms de propriétés, et plutôt faire référence aux noms de champs visibles par l'utilisateur.
+Chaque changement listé devrait contenir un lien vers la documentation associée.
+La description doit être formulée de manière à valoriser et promouvoir le produit.
+
+> #### Nom de la version - 15 février 2020
+>
+> ##### Nouvelles fonctionnalités
+>
+> - Vous pouvez désormais vous abonner aux services
+>
+> ##### Améliorations
+>
+> - Vous pouvez désormais modifier votre nom d'utilisateur
+>
+
+
+> ##### Correctifs
+
+>
+> - Les liens disposent désormais d'un contraste accessible en mode sombre
+>
+> ##### Opérations
+>
+> - Optimisation du suivi des erreurs pour une vitesse accrue
+>
+
+**L'en-tête `Nom de la version`** doit être un nom identifiable, une courte description pour la version.
+Il peut éventuellement inclure `- 15 février 2020` (un horodatage) pour indiquer la date de livraison.
+
+**`Nouvelles fonctionnalités` :** Cette section comprend les nouvelles fonctionnalités ajoutées à l'application.
+Un lien vers la documentation détaillée expliquant le fonctionnement de la fonctionnalité devrait être fourni.
+*L'élément de liste en entier peut servir de lien.*
+
+**`Améliorations` :** La section des améliorations informe les utilisateurs des améliorations apportées aux fonctionnalités existantes de l'application.
+Cette section aide les utilisateurs à comprendre pourquoi explorer les fonctionnalités optimisées.
+
+**`Correctifs` :** Cette section détaille les anomalies corrigées depuis la version précédente.
+Elle indique aux utilisateurs le bon fonctionnement des éléments qui présentaient des défaillances.
+Ces correctifs peuvent avoir été déployés préalablement, mais doivent être mentionnés ici dans le cadre de la version.
+
+**`Opérations` :** Il s'agit des changements relatifs au service et à l'infrastructure de l'application.
+Ces modifications n'ont pas d'impact direct sur les utilisateurs finaux.
diff --git a/docs/_guides/cicd.md b/docs/_guides/cicd.md
index fb252fb..afa5abe 100644
--- a/docs/_guides/cicd.md
+++ b/docs/_guides/cicd.md
@@ -6,6 +6,8 @@ summary: Demonstrate at a high level the steps involved in a CI/CD pipeline.
date: 2019-01-01
---
+*Le texte français est donné à la suite.*
+
## What is Continuous Integration and Continuous Delivery
The diagram is meant to show at a high level the flow of a CI (Continuous Integration) / CD (Continuous Deployment) pipeline and provide guidance for your implementation.
@@ -39,7 +41,7 @@ The success of your pipeline will depend on the implementation and maturity of e
* Any change to code should be done in isolation in a separate branch from your "Master" branch
* Branches should be short lived and merged back into your "Master" branch as early as possible
-* _Notes:_
+* *Notes:*
* "Master" branch refers to your main branch where your latest committed code is stored. In a mature CI/CD implementation the code in this branch would be the same as being executed in production.
* This document is not meant to provide branching strategies, but to enforce that all code changes need to be performed on a branch other then "Master" and that a build should only be done from the "Master" branch, forcing your changes to be merged to the "Master" branch.
@@ -136,7 +138,7 @@ The success of your pipeline will depend on the implementation and maturity of e
* The deployment can include installing the artifact, dependencies and configuration to the environment
* The deployment process is defined by your team and could target 1 environment or multiple environments sequentially (INT, TST, UAT, PERF, Staging...)
-### Execute Tests (_Again_)
+### Execute Tests (*Again*)
* The successful deployment triggers the execution of the tests
* Tests ensure the deployed artifact is behaving as expected
@@ -162,3 +164,164 @@ If required, the notification is triggered by the successful deployment and exec
[Continuous Integration vs Delivery vs Deployment](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)
[Introduction to GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/)
+
+---
+
+*Texte français:*
+
+### Qu'est-ce que l'intégration continue et la livraison continue
+
+Le diagramme vise à présenter à un niveau général le déroulement d'un pipeline CI (Intégration continue) / CD (Déploiement continu) et à guider votre mise en œuvre.
+
+
+
+**L'intégration continue** établit une méthode cohérente et automatisée pour appliquer les modifications au code, tester et packager les applications. Les équipes qui pratiquent l'intégration continue fusionnent leurs modifications dans la branche principale le plus souvent possible, et les changements sont validés par l'exécution de tests automatisés lors de la compilation. Grâce à l'automatisation et à la cohérence du processus, les équipes publient des modifications de code plus fréquemment, ce qui améliore la collaboration, la qualité logicielle et évite les problèmes d'intégration. L'intégration continue met un accent particulier sur l'automatisation des tests pour s'assurer que l'application ne subit pas de régression lors de l'intégration de nouveaux commits dans la branche principale.
+
+**La livraison continue** est une extension de l'intégration continue qui garantit la mise à disposition rapide et durable de nouveaux changements (c'est-à-dire l'artefact produit lors de la CI) aux utilisateurs. Cela signifie qu'en plus d'avoir automatisé vos tests, vous avez également automatisé votre processus de publication, et vous pouvez déployer votre application à tout moment en cliquant sur un bouton vers vos environnements, y compris la production.
+
+**Le déploiement continu** va un cran plus loin que la livraison continue en supprimant toute intervention humaine du processus. Avec cette pratique, chaque modification réussissant toutes les étapes de votre pipeline de production est automatiquement mise à la disposition de vos utilisateurs; sa mise en œuvre exige donc maturité, rigueur et discipline.
+
+Les outils modernes tels qu'Azure DevOps et GitLab prennent en charge les pipelines CI/CD avec de légères variations dans leur mise en œuvre et leur terminologie, et peuvent combiner certaines des étapes décrites dans ce document. Ces outils vous aident à implémenter et gérer votre pipeline ainsi qu'à automatiser nombre de ces étapes. Le pipeline est exécuté de manière séquentielle; chaque étape doit donc être validée avant de passer à la suivante.
+
+Le diagramme illustre 3 occasions de tests qui peuvent inclure (sans s'y limiter) les types suivants : • Qualité du code • Tests unitaires • Intégration • Régression • Tests de bout en bout • Accessibilité • Sécurité • Performance • Normes de formatage • Analyse statique de code (Linting) • Portée des variables • Gestion des secrets • Vulnérabilités courantes (CVE) • Conformité des licences • Connectivité
+
+Le pipeline comprend 2 étapes d'approbation définies par votre équipe et vos partenaires.
+
+Le succès de votre pipeline dépendra de la mise en œuvre et de la maturité de chacune de ces étapes. Chaque étape devrait être une occasion pour votre équipe de réévaluer les pratiques courantes, de les optimiser et de privilégier l'automatisation.
+
+### Étapes du pipeline
+
+#### Créer un élément de travail
+
+* Première étape de la CI
+* Toute modification du code doit débuter par un élément de travail (work item)
+* Les éléments de travail peuvent représenter une anomalie ou une demande d'amélioration
+* Avoir une justification pour chaque modification informe le reste de l'équipe, clarifie l'objectif et permet de restreindre la portée du changement
+
+#### Créer une branche
+
+* Toute modification de code doit être effectuée de manière isolée dans une branche distincte de votre branche « Master »
+* Les branches doivent être de courte durée et fusionnées dans la branche « Master » le plus tôt possible
+* *Notes :*
+ * La branche « Master » fait référence à votre branche principale où réside le code validé le plus récent. Dans une mise en œuvre mature de CI/CD, le code de cette branche est identique à celui exécuté en production.
+ * Ce document n'a pas pour but de prescrire des stratégies de branches, mais de souligner que toute modification doit être réalisée sur une branche autre que « Master » et qu'une compilation ne doit être effectuée qu'à partir de la branche « Master », obligeant ainsi la fusion vers celle-ci.
+
+#### Modifier les tests
+
+* Tous les tests doivent être automatisés
+* Toute modification de code doit s'accompagner d'une mise à jour des tests existants et éventuellement de la création de nouveaux tests
+* Les données de test et les simulations (mocks) peuvent devoir être adaptées ou créées
+* En suivant le développement piloté par les tests (TDD), les tests sont créés en premier (initialement en échec) pour valider le résultat attendu. Des modifications minimales de code sont ensuite apportées pour satisfaire les tests.
+* Les tests à modifier ou créer comprennent notamment : tests unitaires, tests de sécurité, tests d'intégration, etc.
+
+#### Modifier le code
+
+* Les modifications apportées au code source visent à produire le résultat escompté
+* Les modifications doivent respecter vos meilleures pratiques
+* La création d'objets simulés (mocks) peut faire partie de cette étape
+
+#### Exécuter les tests
+
+* Les tests s'exécutent automatiquement lors de chaque commit
+* Tous les tests modifiés ou créés sont exécutés
+* Tous les autres tests jugés nécessaires sont exécutés
+* Les ajustements au code ou aux tests peuvent être apportés à ce moment
+* Les tests à cette étape se concentrent entre autres sur :
+ * La qualité du code
+ * La fonctionnalité (existante et nouvellement introduite)
+ * La sécurité
+
+#### Révision de code
+
+* Étape d'assurance qualité où un ou plusieurs pairs examinent les modifications
+* L'auteur des modifications ne doit pas être un réviseur, mais le destinataire des commentaires/rétroactions afin d'apprendre et de s'améliorer
+* Toute modification suggérée peut être effectuée soit par l'auteur, soit par les réviseurs
+
+#### Approuver les changements
+
+* Point de contrôle pour garantir la qualité de chaque étape avant que les modifications ne soient intégrées à la branche « Master »
+* Le processus d'approbation est défini par votre équipe
+
+#### Fusionner
+
+* La fusion est déclenchée par l'approbation des changements
+* Une fois tous les points de contrôle satisfaits, les modifications de code sont fusionnées dans la branche « Master » en vue de la compilation
+* La branche créée pour réaliser les modifications peut être supprimée
+* Tout conflit de fusion est résolu à cette étape
+
+#### Fermer l'élément de travail
+
+* L'élément de travail créé au début du pipeline peut désormais être fermé
+* Assurez-vous d'inclure les informations et commentaires nécessaires
+
+#### Compiler (Build)
+
+* La compilation est déclenchée par la fusion dans la branche « Master »
+* Les compilations doivent uniquement être effectuées à partir de la branche principale
+* Le processus récupère la version la plus récente du code source depuis la branche principale et le compile
+* Le résultat est un artefact
+
+#### Compiler - Exécuter les tests
+
+* La création réussie de l'artefact déclenche l'exécution des tests
+* Tous les tests requis doivent être exécutés
+* L'étape est terminée dès que tous les tests réussissent
+* Les tests à cette étape ciblent notamment :
+ * La fonctionnalité (existante et nouvellement introduite)
+ * La sécurité
+ * L'intégration
+* Les ajustements au code ou aux tests peuvent être effectués à cette étape au besoin
+
+#### Compiler - Étiqueter / Versionner le code source
+
+* L'exécution réussie des tests déclenche l'étiquetage (tagging/labeling) pour figer un instantané du code source à un moment précis
+* Cela permet de :
+ * Comparer les versions antérieures
+ * Revenir à un état précis du code source
+
+#### Compiler - Publier dans le référentiel d'artefacts
+
+* Dernière étape de la CI
+* Après l'étiquetage, l'artefact compilé est publié dans le référentiel d'artefacts
+* Le résultat est un artefact prêt pour le déploiement
+
+#### Approuver le déploiement (Optionnel)
+
+* Première étape de la CD
+* Ce point de contrôle est facultatif et offre une flexibilité aux équipes pour décider si une approbation est requise pour un environnement donné. Par exemple : les environnements hors production peuvent ne pas exiger d'approbation, tandis que la production peut nécessiter l'approbation du partenaire d'affaires.
+* Le processus d'approbation est défini par votre équipe et votre partenaire d'affaires
+
+#### Déployer
+
+* En livraison continue, le déploiement est déclenché soit par le processus d'approbation optionnel, soit par intervention humaine. En déploiement continu, le déploiement est déclenché automatiquement dès la fin de la compilation.
+* Une fois lancé, le déploiement doit être automatisé sans nécessiter d'intervention humaine
+* Cette étape consiste à récupérer un artefact du référentiel et à le déployer sur un environnement précis
+* Le déploiement peut comprendre l'installation de l'artefact, de ses dépendances et de la configuration requise
+* Le processus de déploiement est défini par votre équipe et peut viser 1 environnement ou plusieurs environnements séquentiellement (INT, TST, UAT, PERF, Staging...)
+
+#### Exécuter les tests (*de nouveau*)
+
+* Le déploiement réussi déclenche l'exécution des tests
+* Les tests vérifient que l'artefact déployé fonctionne comme prévu
+* Les tests à cette étape ciblent principalement :
+ * La sécurité
+ * L'intégration
+ * La connectivité
+
+#### Informer les parties prenantes
+
+Au besoin, une notification est transmise automatiquement à la suite du déploiement et de l'exécution réussie des tests.
+
+#### Surveillance et soutien
+
+* Dernière étape de la CD
+* Surveiller l'état de santé de la solution
+* Fournir le soutien nécessaire
+
+### Références
+
+[Continuous Integration and Continuous Delivery Explained (en anglais)](https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html)
+
+[Continuous Integration vs Delivery vs Deployment (en anglais)](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment)
+
+[Introduction to GitLab Flow (en anglais)](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/)
diff --git a/docs/_guides/git-branching.md b/docs/_guides/git-branching.md
index 3988e6a..ec18401 100644
--- a/docs/_guides/git-branching.md
+++ b/docs/_guides/git-branching.md
@@ -6,6 +6,8 @@ summary: Detailing the differences between branching models in Git, advising on
date: 2019-09-01
---
+*Le texte français est donné à la suite.*
+
## Branching
Managing your branching and versioning effectively for your project development is a key aspect to success when working with Git.
@@ -14,7 +16,7 @@ The Branching Model helps provide a common practice that everyone can openly kno
### Picking a Branching Model
-Picking the right branching model for your project can be difficult because there are a lot of models out there and they all advocate they are the _best_.
+Picking the right branching model for your project can be difficult because there are a lot of models out there and they all advocate they are the *best*.
When picking a model look at your project first.
Define some requirements that you need your model to meet based on your release cycles to all the different environments you support and what kind of project it is.
An API or Web Service might need a different model than a Web App.
@@ -33,12 +35,12 @@ We have extracted a few requirements from our typical ESDC release process.
#### Popular Flows Comparison
| Key Features | [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) | [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) | [Microsoft Release Flow](https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow) | [GitHub Flow](https://githubflow.github.io/) | [GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/) |
-| :--- | --- | --- | --- | --- | --- |
-| Production and Development branches segregated * | :heavy_check_mark: | :grey_question: (Optional) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
-| Manages Staging/Release branches * | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: |
+| :--- | --- | --- | --- | --- | --- | --- |
+| Production and Development branches segregated *| :heavy_check_mark: | :grey_question: (Optional) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
+| Manages Staging/Release branches* | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: |
| ER branching similar to "regular" * | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
-| Easy to follow history ** | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
-| Easy to learn when new to Git ** | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Easy to follow history **| :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Easy to learn when new to Git** | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
| Maintains all main branches (reduced chances of code loss) | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: |
| Designed for Continuous Deployment | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
| Designed for Continuous Delivery | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
@@ -53,12 +55,73 @@ We have extracted a few requirements from our typical ESDC release process.
Use [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) branching model.
It is great for managing releases and parallel development in large applications.
-This model has two _primary_ branches, `master` & `dev`, that always exist.
-All other branches only exist as long as they are active (until merged into a _primary_ or _secondary_ branch).
-The _secondary_ branches include _`release`_, _`feature`_ and _`hotfix`_.
-Both the _primary_ and _secondary_ branches should be protected to only accept changes via a pull or merge request.
-The last branch is a _`working`_ branch.
+This model has two *primary* branches, `master` & `dev`, that always exist.
+All other branches only exist as long as they are active (until merged into a *primary* or *secondary* branch).
+The *secondary* branches include *`release`*, *`feature`* and *`hotfix`*.
+Both the *primary* and *secondary* branches should be protected to only accept changes via a pull or merge request.
+The last branch is a *`working`* branch.
This branch is the only place you should be committing code against.
GitFlow can be fairly simplistic but also get very complex.
We recommend you try to keep it as simple as possible, but don't shy away from getting complex if that is what the project requires.
+
+---
+
+*Texte français:*
+
+### Ramification (Branching)
+
+Gérer efficacement vos branches et vos versions pour le développement de vos projets est un facteur clé de réussite lors de l'utilisation de Git.
+La plupart des projets Git s'appuient sur un modèle de ramification (*Branching Model*) qui définit les règles et les attentes des développeurs pour gérer leurs branches.
+Ce modèle fournit une pratique commune, partagée et accessible à tous.
+
+#### Choisir un modèle de ramification
+
+Choisir le bon modèle de ramification pour votre projet peut s'avérer difficile en raison de la multitude de modèles existants, chacun prétendant être le *meilleur*.
+Pour choisir un modèle, examinez d'abord les besoins de votre projet.
+Définissez les exigences auxquelles votre modèle doit répondre en fonction de vos cycles de livraison vers les différents environnements pris en charge et du type de projet.
+Une API ou un service Web peut nécessiter un modèle différent de celui d'une application Web.
+
+##### Exigences des projets d'EDSC
+
+Nous avons dégagé quelques exigences issues du processus de livraison typique d'EDSC.
+
+- Pouvoir gérer une branche équivalente à la production à long terme, distincte du développement quotidien.
+ > Pourquoi ? Nos livraisons en production sont parfois espacées de 6 mois ou plus.
+- Pouvoir gérer une branche de préproduction (staging) à moyen terme, distincte du développement quotidien et du code de production.
+ > Pourquoi ? Nous avons des cycles de test et d'assurance qualité qui durent environ 2 mois.
+- Pouvoir gérer les livraisons d'urgence (hotfix) sans déroger au schéma de ramification standard.
+ > Pourquoi ? Les livraisons d'urgence peuvent être stressantes; nous ne voulons pas modifier la méthode standard de transfert de code d'une branche à l'autre.
+
+##### Comparaison des flux populaires
+
+| Fonctionnalités clés | [GitFlow](https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow) | [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) | [Microsoft Release Flow](https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow) | [GitHub Flow](https://githubflow.github.io/) | [GitLab Flow](https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/) |
+| :--- | --- | --- | --- | --- | --- | --- |
+| Branches de production et de développement séparées *| :heavy_check_mark: | :grey_question: (Optionnel) | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
+| Gestion des branches de staging / release* | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: |
+| Ramification d'urgence similaire au flux régulier * | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Historique facile à suivre **| :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Facile à apprendre pour les débutants Git** | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Maintient toutes les branches principales (risque réduit de perte de code) | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: |
+| Conçu pour le déploiement continu | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
+| Conçu pour la livraison continue | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
+| Prend en charge la livraison continue | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Prend en charge l'intégration continue | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Déploie en production depuis la branche « Main/Master/Default » | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
+
+> Légende : `*` tiré des **Exigences des projets d'EDSC**; `**` Analyse subjective.
+
+#### Notre recommandation
+
+Utilisez le modèle de ramification [GitFlow](https://www.atlassian.com/fr/git/tutorials/comparing-workflows/gitflow-workflow).
+Il est idéal pour la gestion des livraisons et le développement parallèle dans les grandes applications.
+
+Ce modèle comporte deux branches *principales*, `master` et `dev`, qui existent en permanence.
+Toutes les autres branches n'existent que le temps de leur utilisation active (jusqu'à ce qu'elles soient fusionnées dans une branche *principale* ou *secondaire*).
+Les branches *secondaires* comprennent *`release`*, *`feature`* et *`hotfix`*.
+Les branches principales et secondaires doivent toutes être protégées afin de n'accepter des modifications que par le biais d'une pull/merge request.
+La dernière branche est une branche de *`travail`* (working branch).
+C'est sur cette branche uniquement que vous devez valider votre code.
+
+GitFlow peut paraître simple au départ mais peut également devenir très élaboré.
+Nous vous recommandons de le garder aussi simple que possible, sans hésiter à ajouter de la complexité si le projet le requiert.
diff --git a/docs/_guides/merging-review.md b/docs/_guides/merging-review.md
index 70784b9..540da12 100644
--- a/docs/_guides/merging-review.md
+++ b/docs/_guides/merging-review.md
@@ -6,6 +6,8 @@ summary: Describing the best methods to manage code reviews and merges.
date: 2019-09-01
---
+*Le texte français est donné à la suite.*
+
## Overall best practices
- Be kind.
@@ -21,7 +23,7 @@ date: 2019-09-01
- Consider one-on-one chats or video calls if there are too many “I didn’t understand” or “Alternative solution:” comments. Post a follow-up comment summarizing one-on-one discussion.
- If you ask a question to a specific person, always start the comment by mentioning them; this will ensure they see it if their notification level is set to “mentioned” and other people will understand they don’t have to respond.
-## Responsibility of the _author_
+## Responsibility of the *author*
- Keep your changes small with a clear scope.
- Describe the changes in the Pull Request. Link it to a task.
@@ -43,7 +45,7 @@ Please keep in mind that code review is a process that can take multiple iterati
- Push commits based on earlier rounds of feedback as isolated commits to the branch. Do not squash until the branch is ready to merge. - Reviewers should be able to read individual updates based on their earlier feedback.
- Assign the merge request back to the reviewer once you are ready for another round of review. If you do not have the ability to assign merge requests, @ mention the reviewer instead.
-## Responsibility of the _reviewer_
+## Responsibility of the *reviewer*
- When approving a merge, you are just as responsible for the changes as the person who made them. So you should understand them just as well.
- Only review changed lines.
@@ -85,14 +87,110 @@ Later when going though history trying to identify issues, the smaller changes w
### Why do code reviews matter?
The primary goal of a code reivew should be collaberation.
-The collaberation allows the _reivewer_ and _author_ of the code change to learn more about the project, enabling them both to make better changes to the project in the moment and in the future.
+The collaberation allows the *reivewer* and *author* of the code change to learn more about the project, enabling them both to make better changes to the project in the moment and in the future.
### How do I keep reviews from taking up all my time?
- **Keep the changes small!** If the change is too large and could have been broken appart, reject it.
-- **Don't validate the code** in your reivew. Let the pipeline do that work for you. Focus on learning what it is the _author_ is trying to do, and check that what they did makes sense.
+- **Don't validate the code** in your reivew. Let the pipeline do that work for you. Focus on learning what it is the *author* is trying to do, and check that what they did makes sense.
- If you don't understand the change, **ask for more details**. Don't spend time trying to figgure it out, it should be simple enough (or explained in comments) to understand in a minute or two.
## Attribution
Some content copied from [GitLab Code Review Guidelines](https://docs.gitlab.com/ee/development/code_review.html#the-responsibility-of-the-merge-request-author)
+
+---
+
+*Texte français:*
+
+### Bonnes pratiques générales
+
+- Soyez bienveillant.
+- Acceptez que de nombreuses décisions de programmation relèvent d'opinions. Discutez des compromis et trouvez rapidement une solution.
+- Posez des questions au lieu d'imposer des exigences. (« Que penses-tu de nommer ceci :user_id ? »)
+- Demandez des éclaircissements. (« Je n'ai pas compris. Peux-tu préciser ? »)
+- Évitez le sentiment d'appropriation exclusive du code. (« mon code », « ton code »)
+- Évitez les termes pouvant être perçus comme visant des traits personnels (« idiot », « stupide »). Partez du principe que tout le monde est compétent et bien intentionné.
+- Soyez explicite. N'oubliez pas que vos intentions ne sont pas toujours évidentes par écrit.
+- Restez humble. (« Je n'en suis pas certain - vérifions ensemble. »)
+- Évitez les hyperboles (« toujours », « jamais », « rien »).
+- Soyez prudent avec le sarcasme. Nos échanges sont publics; une plaisanterie amicale envers un collègue de longue date peut paraître blessante pour un nouveau venu.
+- Envisagez un échange direct ou un appel vidéo s'il y a trop de commentaires d'incompréhension. Publiez ensuite un commentaire résumant la discussion.
+- Si vous posez une question à une personne précise, mentionnez-la au début du commentaire afin qu'elle reçoive la notification et que les autres sachent qu'ils n'ont pas à répondre.
+
+### Responsabilités de l'*auteur*
+
+- Gardez vos changements de taille réduite avec une portée bien définie.
+- Décrivez les modifications dans la Pull Request / Merge Request. Liez-la à une tâche.
+- Les nouvelles fonctions et conditions doivent s'accompagner de nouveaux tests unitaires. Les fonctions modifiées ne doivent pas briser les tests existants.
+- Les sections de code complexes doivent être commentées.
+
+#### Faire réviser son code
+
+Gardez à l'esprit que la révision de code est un processus itératif et que les réviseurs peuvent relever des éléments plus tard qu'ils n'avaient pas vus au premier abord.
+
+- Vous êtes le premier réviseur de votre code. Avant de pousser votre nouvelle branche, examinez l'ensemble du diff. Est-ce cohérent ? Y a-t-il du code superflu ou du code de débogage oublié ?
+- Accueillez favorablement les suggestions des réviseurs. (« Bonne remarque, je fais la modification. »)
+- Ne prenez pas les remarques personnellement. La révision porte sur le code, pas sur votre personne.
+- Expliquez la raison d'être du code. (« C'est ainsi pour telle raison. Serait-ce plus clair si je renomme cette classe/méthode/variable ? »)
+- Isolez les changements non reliés et les refactorisations dans de futures demandes de fusion ou tickets.
+- Cherchez à comprendre la perspective du réviseur.
+- Efforcez-vous de répondre à chaque commentaire.
+- L'auteur ne résout que les fils de discussion qu'il a entièrement traités. En cas de question ou suggestion ouverte, le fil doit être laissé à la résolution du réviseur.
+- Poussez les commits de rétroaction de manière isolée sans les écraser (squash) immédiatement, afin que les réviseurs puissent voir l'évolution.
+- Réassignez la demande de fusion au réviseur lorsque vous êtes prêt pour un nouvel examen, ou mentionnez-le (@mention).
+
+### Responsabilités du *réviseur*
+
+- En approuvant une fusion, vous partagez la responsabilité du code avec son auteur. Vous devez donc le comprendre tout aussi bien.
+- Ne révisez que les lignes modifiées.
+- Tout intervenant du projet peut soulever des points bloquants sur une PR/MR, même s'il n'y est pas formellement assigné.
+- L'objectif ultime d'une PR/MR doit être le transfert de connaissances.
+
+#### Réviser le code
+
+Comprenez pourquoi le changement est nécessaire (correction de bogue, amélioration UX, refactorisation). Ensuite :
+
+- Soyez rigoureux pour limiter le nombre d'itérations.
+- Exprimez clairement les points qui vous tiennent à cœur et ceux qui sont secondaires.
+- Cherchez à simplifier le code tout en répondant au besoin.
+- Proposez des implémentations alternatives avec bienveillance.
+- Tentez de comprendre le point de vue de l'auteur.
+- Si un extrait de code vous paraît obscur, dites-le.
+- Préfixez vos remarques non bloquantes par « Non bloquant : » pour indiquer qu'il s'agit d'une suggestion facultative.
+- Après vos commentaires détaillés, publiez une note de synthèse comme « LGTM :thumbsup: » ou « Juste quelques points à revoir ».
+- Réassignez la demande à l'auteur si des corrections sont requises.
+- Utilisez l'option d'écrasement de commits (*Squash and merge*) si l'historique de la branche est chargé et désordonné.
+
+#### Trouver le juste équilibre
+
+L'un des aspects les plus délicats de la révision de code consiste à doser le niveau d'intervention sur le travail d'autrui.
+
+- Détecter les bogues et soigner le style est crucial, mais concevoir une architecture propre l'est tout autant. Les bonnes abstractions facilitent les évolutions futures.
+- Demander une refonte de conception peut signifier réécrire le code soumis. Discutez-en au préalable avec un autre pair, mais ayez le courage de le proposer si c'est pertinent.
+- Faire les choses parfaitement et répondre à l'urgence sont deux impératifs distincts. Pour un correctif de sécurité urgent, évitez d'exiger une refactorisation majeure.
+- Une solution satisfaisante livrée aujourd'hui vaut souvent mieux qu'une solution parfaite livrée trop tard. En cas de doute, sollicitez l'avis de vos pairs.
+
+
+### FAQ
+
+
+#### En quoi les petits changements aident-ils mon projet ?
+
+Les petites modifications permettent d'évaluer et de valider chaque changement de manière isolée. Elles accélèrent considérablement le travail de révision et l'intégration continue. Lors de l'analyse rétrospective de l'historique Git, les commits ciblés facilitent grandement la compréhension des intentions passées.
+
+#### Pourquoi la révision de code est-elle essentielle ?
+
+Le but premier de la révision de code est la collaboration et le partage de connaissances au sein de l'équipe, assurant ainsi une qualité logicielle durable.
+
+#### Comment éviter que les révisions ne monopolisent tout mon temps ?
+
+- **Gardez les changements petits !** Si une PR est trop volumineuse et divisible, demandez à la scinder.
+- **Ne validez pas l'exécution manuellement.** Laissez le pipeline de tests automatisés faire son travail. Concentrez-vous sur la logique et la cohérence métier.
+- Si le code n'est pas clair, **demandez des explications**. Ne perdez pas de temps à deviner; le code ou les commentaires doivent être compréhensibles en quelques minutes.
+
+
+### Attribution
+
+
+Certains éléments sont adaptés des [GitLab Code Review Guidelines](https://docs.gitlab.com/ee/development/code_review.html#the-responsibility-of-the-merge-request-author).
diff --git a/docs/_guides/nsd-application-cataloque.md b/docs/_guides/nsd-application-cataloque.md
index eebc52f..973bfcd 100644
--- a/docs/_guides/nsd-application-cataloque.md
+++ b/docs/_guides/nsd-application-cataloque.md
@@ -6,6 +6,7 @@ summary: How to request a Git installation from the NSD Application catalogue
date: 2023-02-03
---
+*Le texte français est donné à la suite.*
## Background
@@ -38,3 +39,41 @@ This will bypass proxy as long as your Git session stays open. Once you close yo
`git config --global http.proxy