Versionner correctement un projet initialisé avec composer

Une fois que vous aurez pris en main composer, il se posera rapidement la question de la manière de versionner correctement votre projet pour le partager entre les différents membres de votre équipe 🥰.

Avant d’aller plus loin, je précise que les 2 outils que je vais présenter ici n’ont pas besoin de composer pour fonctionner. On pourrait parfaitement utiliser ces outils sans avoir initialisé notre projet sous composer. En somme, ils se complètent pour former un tout.

Les outils Git & Gitlab

Globalement, je vous conseillerais d’adopter la même approche que vous soyez seul, cinq, ou même beaucoup plus. Comme on dit souvent, qui peut le plus peut le moins, alors autant garder les bonnes habitudes quelle que soit la typologie de vos projets.

Versionner vos projets sous Git

Je vous recommande de versionner vos projets sous Git et d’utiliser un flow identique pour chaque membre de l’équipe. Et pourquoi pas directement passer par git-flow, très bien expliqué ici.

A noter, rien ne vous empêchera d’adopter votre propre « git-flow ». Néanmoins, vous devrez respecter certaines règles de base pour éviter les problèmes, en exploitant au maximum la notion de branche par exemple. Je ne les aborderai pas ici, car elles nécessitent des explications longues et dédiées.

Héberger vos projets sur une plateforme en SAAS

Dans mon cas, et pour un grand nombre de raisons que j’aurai l’occasion d’aborder progressivement sur mon blog, ce sera Gitlab.

Gitlab repose entièrement sur Git, donc pour le coup, ces deux outils fonctionnent de paire.

En hébergeant vos sources sur ce type d’outil en SAAS, vous l’ouvrirez rapidement aux membres de votre équipe, tout en gardant le dépôt de votre projet privé pour que son code source ne soit pas exposé ! La version gratuite vous permettra d’utiliser bon nombre de ses fonctionnalités et je pense qu’elles pourront répondre à la quasi totalité de vos besoins.

Sachez que vous avez aussi la possibilité de l’installer sur votre propre serveur, si tant est qu’il soit assez robuste et que vous soyez suffisamment à l’aise avec la ligne de commande. Avec cette méthode, vous pourrez alors bénéficier gratuitement de 100% de ses fonctionnalités ! Si vous êtes novice, je vous déconseille fortement de le gérer par vous-même 🤒. Je vous rappelle que l’outil est dédié à héberger les sources de vos projets (et pas que). Si vous n’êtes pas en capacité de faire repartir Gitlab après une mise à jour bancale, vous risquez gros, alors autant utiliser l’outil en SAAS et vous dormirez mieux!

Mise en pratique sur un cas simple

On va partir d’un cas très simple, qu’on agrémentera au file du temps au travers d’articles, pour tendre vers une solution complète, allant jusqu’au déploiement en production.

Ici nous allons aborder ces quelques points:

  • Créer un projet et le versionner sur Gitlab (donc sous entend versionné à l’aide de Git)
  • Le projet sera initialisé avec composer, on installera un bundle qu’on utilisera

Initialisation de composer

On va commencer par se placer dans le répertoire de notre choix et lancer un composer init, comme vu précédemment. Cette commande interactive va générer un fichier composer.json.

Notre objectif : générer une chaîne aléatoirement et l’afficher à l’écran. Pour cela, nous allons utiliser le paquet paragonie/random-lib en lançant la commande ci-dessous :

composer require paragonie/random-lib

La commande va télécharger le paquet et le placer dans le répertoire vendor. Le fichier composer.lock est aussi créé.

Vous noterez la présence de quelques dépendances, elles aussi téléchargées.

Un peu de code PHP

Dans un fichier index.php qu’on placera dans un répertoire web à créer, nous allons ajouter ces quelques lignes de code :

<?php require '../vendor/autoload.php';

use RandomLib\Factory;

$factory = new Factory();
$generator = $factory->getMediumStrengthGenerator();

echo $generator->generateString(32, 'abcdef');

Rien de bien extraordinaire 🤭. On commence par charger l’autoload qui se trouve dans le répertoire vendor et ensuite on utilise les fonctionnalités offertes par le bundle pour générer une chaîne aléatoire de 32 caractères avant de l’afficher.

Création du dépôt sur Gitlab

On s’empresse de créer le projet sur Gitlab et ensuite on suit les instructions proposées par l’outil et qui correspondent à notre cas : versionner un projet existant.

Avant toute chose, nous allons devoir indiquer à Git que nous ne souhaitons pas versionner le répertoire vendor ! Nous allons donc créer un fichier .gitignore à la racine du projet, au même niveau que les fichiers composer.json et composer.lock, et nous y ajoutons une seule ligne contenant vendor.

Ensuite, on lance les commandes ci-dessous communiquées par Gitlab :

git init
git remote add origin [email protected]:ruiadr/test.git
git add .
git commit -m "Initial commit"
git push -u origin master

Durant ce processus, nous avons donc versionné uniquement 4 fichiers, c’est léger, et même bon pour la planète !

  • web/index.php
  • composer.json
  • composer.lock
  • .gitignore

Pour améliorer la lisibilité et la prise en main de notre dépôt, on se force à mettre en place un fichier README.MD. Pour m’aider dans cette tâche, j’utilise l’outil https://stackedit.io/.

Une fois terminé, on le versionne et on le pousse sur le dépôt distant.

git add README.MD
git commit -m "Ajout du fichier README.MD" README.MD
git push

Vous pouvez consulter le dépôt public à cette adresse : https://gitlab.com/ruiadr/test

Utiliser ce dépôt ailleurs ou par un autre développeur

C’est tout simple et comme c’est désormais indiqué dans le fichier README.ME, il suffit de cloner le projet et de lancer un composer install, rien de plus !

git clone [email protected]:ruiadr/test.git .
composer install

Chaque développeur peut ainsi ajouter ses propres contributions, sans jamais écraser le travail des autres, et en ne versionnant que le strict nécessaire.

Visibilité améliorée, maintenabilité assurée, portabilité optimisée, bref, tout ce qu’on aime 😍 !