Devenez programmeur Open Source dans la communauté Drupal

En tant que l'une des plateformes CMS les plus populaires, Drupal a une énorme communauté bâtie autour d'elle qui travaille chaque jour à la fois sur le développement et l'amélioration du cœur du système et sur les projets étendant ses fonctionnalités. Le mot d'ordre de la communauté est : "coopération plutôt que compétition" – au lieu de proposer de nombreux modules concurrents, des solutions individuelles pour résoudre un problème donné sont créées.

Le système modulaire permet même aux développeurs Drupal moins expérimentés de contribuer au travail quotidien de programmation sur divers types de projets. Alors, comment pouvez-vous apporter votre propre contribution dans l'environnement de Drupal ?

Avant de créer mon propre projet

1. Recherche !

Avant de lancer un projet, vérifiez d'abord soigneusement si un tel projet n'a pas déjà été créé. Il se peut que, par exemple, le module que vous souhaitez créer existe déjà ou qu'il suffise de soumettre une proposition pour étendre ses fonctionnalités. Il est également bon de consulter la liste des modules proposés et d'apporter votre soutien aux travaux de développement de quelqu'un.

2. Votre profil sur le portail web drupal.org

Si vous n'avez pas encore de compte sur le portail drupal.org, nous vous encourageons vivement à en créer un. Grâce à cela, vous pourrez créer de nouveaux projets ainsi que signaler des problèmes et des correctifs concernant les projets existants.

3. Un projet sandbox ou un projet complet ?

Le portail web drupal.org vous permet de créer deux types de projets. Le premier est un projet sandbox. C'est essentiellement un terrain de test pour les modules nouvellement développés. Habituellement, ses créateurs ne prennent aucune responsabilité pour son code jusqu'à ce qu'ils terminent de travailler sur une version qui répond au moins aux exigences de base en matière de fonctionnalité et de stabilité. À ce stade, un projet sandbox est généralement promu en projet complet dans lequel il est possible de créer des versions, des sorties, des notifications, etc.

Créer un projet

Le processus de création d'un projet n'est pas particulièrement compliqué. Au début, seules quelques informations de base sont nécessaires – vous n'avez même pas besoin d'avoir un code effectivement existant.

Vous pouvez ajouter votre propre projet depuis le niveau de votre profil en allant à l'onglet Vos projets, ou directement depuis la page web Ajouter un nouveau projet.

Vous choisissez le type de projet. Dans notre cas, il s'agira d'un module.
Vous remplissez le champ avec le nom du module, le nom machine (nom court) et le type de projet (sandbox/complet).
En outre, il est bon de fournir le nom de l'organisation soutenant le développement du projet (c'est une forme de promotion supplémentaire pour l'entreprise) et les personnes supplémentaires qui coopéreront à la maintenance du projet.

Travail sur le code

1. Git

Au début, vous devez obtenir l'accès aux référentiels basés sur le système de contrôle de version Git. Le portail web Drupal.org utilise la plateforme GitLab, qui est partiellement intégrée au portail web lui-même. Vous devez ajouter votre clé SSH lors de l'édition du profil.

Pour les systèmes Linux, la commande la plus courante pour télécharger le contenu de votre clé publique SSH est :

cat ~/.ssh/id_rsa.pub

Ensuite, dans la section d'accès Git, vous devez d'abord donner quelques consentements nécessaires, ainsi que configurer le nom d'utilisateur et l'adresse e-mail s'ils ne sont pas les données par défaut du profil.

Après avoir obtenu l'accès au système de contrôle de version, lorsque vous travaillez sur des référentiels sélectionnés, vos modifications peuvent être approuvées à la fois en utilisant une adresse email publique ou une adresse anonymisée fournie par le portail web drupal.org, par exemple [email protected].

2. Branche développeur

Tous les projets de contrib, ainsi que le cœur de Drupal, adhèrent à une convention de numérotation version fixe.
Pour le cœur, c'est par exemple (8.8.5), selon le schéma :

[VERSION MAJEURE].[VERSION MINEURE].[CORRECTIF]

Pour les projets de contrib, c'est par exemple (8.x-2.x), selon le schéma :

[VERSION MAJEURE DU CŒUR].x-[VERSION DU MODULE].x

Si vous travaillez actuellement sur la version 1.15 du module, alors la branche principale de la version, et aussi la branche de développement, est la branche : 8.x-1.x
Les branches développeur ne nécessitent pas de suffixe additionnel '-dev' ni l'ajout d'une étiquette. Cependant, pour qu'une branche de développement soit visible sur la page web du projet, une nouvelle version doit être créée.

3. Création de pré-versions et de versions completions

Lorsque vous sentez que le projet sur lequel vous travaillez commence à prendre forme, et que de plus en plus de fonctionnalités atteignent vos objectifs, il est bon de créer une pré-version, qui est en fait une version instable.
Conformément à la convention adoptée, ces versions doivent être suivies du suffixe -[type][numéro]. À votre disposition, ces types sont :

• alpha,
• bêta,
• rc (release candidate)

qui définissent très simplement à quel point votre projet est proche d'atteindre sa stabilité. Vous pouvez trouver plus d'informations sur ce sujet dans l'article Conventions de nommage des versions.
Cependant, si vous êtes convaincu que votre module est entièrement stable et bien testé, vous pouvez créer une version stable (sans suffixe), par exemple 8.x-2.5.
Quel que soit le chemin que vous décidez de prendre, vous devez d'abord ajouter une étiquette git sur la base de laquelle votre version sera créée. Vous pouvez le faire en utilisant la commande :

git tag 8.x-1.1-alpha1

Ensuite, vous devez envoyer au référentiel les modifications que vous avez introduites :

git push origin 8.x-1.1-alpha1 - tag unique
git push origin --tags - tous les tags

L'étiquette envoyée de cette manière peut maintenant être utilisée pour créer une nouvelle version (dans l'édition du projet – Versions/Ajouter une nouvelle version).

Veuillez noter que chaque étiquette ne peut être utilisée qu'une seule fois, et que les étiquettes déjà utilisées ne peuvent jamais être supprimées du référentiel (elles sont bloquées).

Maintenir le projet

1. File d'attente des problèmes

C'est ici que le projet est vraiment vivant. Toute erreur, suggestion d'amélioration, nouvelle fonctionnalité, etc. est émise ici (une file d'attente d'exemples pour le projet Droopler). Tout utilisateur connecté du portail web peut ajouter de nouveaux problèmes, commenter, ainsi que émettre des correctifs.

Chaque problème a un statut dont la valeur par défaut est "Actif". La liste complète des statuts peut être trouvée dans l'article Paramètres de statut des problèmes.

2. Émettre et accepter des correctifs

Les correctifs peuvent être ajoutés à un problème en tant que pièce jointe dans un commentaire ou ajoutés à un problème nouvellement créé. La liste des correctifs émis peut être trouvée dans le résumé, sous le premier post dans un problème donné.
Si un correctif a été émis pour votre projet, alors en tant qu'auteur, vous devriez le vérifier et modifier le statut du problème en conséquence. Si le correctif proposé fonctionne correctement, vous devriez le valider, honorant l'auteur du correctif en ajoutant le paramètre --author, par exemple.
 

git commit 
-m 'Problème #[numéro du problème] par [nom d'utilisateur] : [titre du problème]'
--author="Sayco <[email protected]>"

Dans le cas où vous trouvez une erreur dans la fonctionnalité de l'un des projets, ou le cœur même de Drupal, vous pouvez également émettre votre propre correctif. Pour commencer à travailler sur un tel correctif, vous devez suivre plusieurs étapes :

Vous clonez le référentiel du projet (la page web du projet  – Parcourir le référentiel de code).

git clone [email protected]:project/paragraph_view_mode.git

Vous passez à la branche où l'erreur a été trouvée, par exemple.

git checkout 8.x-1.x

Après avoir apporté les modifications nécessaires, vous avez diverses options pour générer un correctif. S'il n'y a pas eu trop de modifications et que vous n'avez pas besoin de les valider, générez simplement un correctif basé sur les différences qui ont eu lieu :

git diff > [projet]-[description]-[numéro du problème]-[numéro de commentaire].patch

Cependant, s'il y a eu plus de changements alors – selon ce que vous souhaitez accomplir – vous pouvez générer un correctif en spécifiant : la plage de validations, les hachages de validation individuels, le nombre de validations pour un hachage de validation donné, par exemple.

git format-patch -<n> <SHA1>
--stdout > [projet]-[description]-[numéro du problème]-[numéro de commentaire].patch

Comme vous l'avez certainement remarqué dans les exemples ci-dessus, le nom du correctif suit une convention de nommage spécifique. Le plus souvent, vous donnez à un tel fichier le nom du projet, une courte description, le numéro de problème, et aussi le numéro de commentaire dans lequel le correctif sera émis.

Parfois, en plus du correctif lui-même, il est nécessaire d'ajouter un interdiff, c'est-à-dire un fichier montrant les différences entre votre correctif et, par exemple, un correctif signalé précédemment, sur la base duquel vous avez apporté des modifications spécifiques. Vous pouvez en savoir plus sur ce sujet dans l'article "Créer un interdiff".

3. Politique de conseil en sécurité

À un certain stade du développement du projet, vous pouvez enfin dire qu'il est suffisamment stable et sécurisé pour demander un SAP (Security Advisory Policy). C'est un système d'information ouvert et public sur les incidents au sein du cœur de Drupal et sur les projets de contrib. Les incidents détectés sont gardés secrets (si possible) jusqu'à la création d'une version avec un correctif de sécurité approprié avec le soutien de la Drupal Security Team.

Les projets couverts par SAP reçoivent une icône de bouclier sur la page web du projet et un fond vert pour toutes les versions stables.
Cela les rend visibles sur la page web tout en augmentant la valeur de ces projets aux yeux des utilisateurs potentiels.

3.1 Comment postuler ?

• Créez un nouveau problème sur la page web https://www.drupal.org/project/issues/projectapplications.
• Définissez le titre conformément au schéma [VERSION DU COEUR] [nom du module], par exemple [D8] Autotile.
• Définissez le statut du problème à "Needs review".

3.2 Quelles exigences doit respecter votre projet ?

• Il doit répondre aux fonctionnalités cibles trouvées dans la description du projet.
• Il doit réussir à passer PAReview – outil de vérification en ligne des projets Drupal.
• Il doit être approuvé par la communauté (c'est principalement une vérification de la qualité du code et de la sécurité).

Le processus de vérification est unique pour un utilisateur donné du portail. Après avoir obtenu l'approbation, l'utilisateur peut créer autant de projets couverts par SAP, sans avoir à subir le processus de vérification.

Résumé

Comme vous l'avez sûrement remarqué, il existe plusieurs façons de contribuer à la communauté Drupal. Vous pouvez à la fois soutenir les projets existants, ainsi que développer vos propres projets, contribuant ainsi au développement de logiciels libres. Un module bien fait peut être utilisé par vous et de nombreux autres utilisateurs à plusieurs reprises dans de nombreux projets.

Je pense que pour nous, en tant que programmeurs, c'est une sorte de mission ou une forme de rendre à la communauté pour la possibilité d'utiliser des logiciels gratuits pour notre propre usage. Bien sûr, c'est aussi un excellent moyen d'échanger des connaissances, des expériences et de s'auto-promouvoir. Il est bon de mentionner que de cette manière, vous pouvez promouvoir non seulement vous-même, mais aussi l'organisation ou l'entreprise pour laquelle vous travaillez, ou même les clients pour lesquels vous créez des fonctionnalités données. Je développe déjà des projets sur le portail web Drupal.org. Vous pouvez le faire aussi. Commencez dès aujourd'hui !