Github, Packagist & Composer

par Julien

En plus, leurs logos sont mignons.

Pour débuter l’année en douceur, nous allons présenter 3 services recommandés pour faire du développement informatique et comprendre leur relation. Ces services sont Github, Packagist & Composer (Nos 3 mousquetaires numériques).

Pour les introduire brièvement : Github est un service fournissant un support et une interface accessible à l’utilisation de Git, un système de versionning de fichiers. Packagist est une sorte de répertoire public de packages PHP utilisables via Composer. Et enfin, Composer est un gestionnaire de dépendances pour votre projet informatique.

Ensemble, ils offrent une architecture fiable pour la création et la maintenance d’un projet informatique et nous permettent de gagner en productivité.

Je sais, je sais, il n’y a pas que PHP dans la vie, mais entre Symfony, Laravel, Wordpress et les autres, il faut bien admettre qu’une grosse partie du web est basée sur ce langage de programmation.

Github

GIT est un des systèmes de versionning de fichiers les plus connus et utilisés dans le monde du développement. En guise d’alternatives, vous avez peut-être entendu parler de SVN, Fossil, Codeville ou encore Perforce.

Par dessus GIT, il existe des hébergeurs de dépôts comme Github, Bitbucket ou Gitlab. Ils peuvent être gratuits ou payants, selon les services qu’ils proposent.

Chez Web ex Machina, on utilise Github, après avoir utilisé la solution auto-hébergée Gitlab. Nous sommes passés chez Github suite à un changement de structure informatique, car nous ne gérons plus directement de serveurs.

A chaque fois que l’on développe, on fait ce que l’on appelle un package. Cela peut-être tout un site, un module ou bien une simple interface. En gros, tout système pouvant être retravaillé sur le long terme et valant le coup d’être versionné peut être un package.

Une fois le dépôt créé, on va le manipuler, soit en ligne de commandes, soit via un logiciel comme SourceTree. On ne va toutefois pas rentrer dans les détails de la manipulation d’un dépôt GIT dans cet article car il y a beaucoup à dire et ça mérite un article intégral dessus.

L’avantage de ces systèmes est qu’il vous permet de créer des versions de package. Avec une nomenclature précise pour pouvoir les récupérer ensuite.

Exemple d'une branche d'un dépôt Git

Il est très important de définir une nomenclature claire pour les versions d’un dépôt. Une des plus communes (et la plus efficace selon nous), c’est l’appellation x.y.z où :

  • x est réservé aux modifications globales
  • y est réservé aux fonctionnalités
  • z est réservé aux patchs et corrections de bugs

Une fonctionnalité créée à la version 3.5 ne sera pas compatible avec la version 4 du système par exemple, il faudra l’ajuster à la nouvelle structure.

C’est tout pour l’instant pour Github !

Packagist

Packagist est le répertoire de packages PHP développé par & pour Composer. Les développeurs envoient leurs packages via l’URL de leur dépôt GIT et ils deviennent alors utilisables via Composer.

L’interface récapitule tout ce que fait le package et toutes ses dépendances, ainsi que la liste des versions disponibles. On dispose également d’un code (token) qui peut-être utilisé pour déclencher des webhooks sur les services comme Github.

Installer un webhook sur Github

Tout l’intérêt d’un répertoire de packages est d’être maintenu le plus à jour possible. Pour cela, vous pouvez installer un webhook sur votre dépôt Github pour déclencher l’update de votre dépôt Packagist sur une action GIT.

Dans Github, sur la page du dépôt, rendez-vous dans “Settings”, puis dans “Webhooks”, une fois la page affichée, cliquez sur “Add Webhook” et saisissez les entrées suivantes :

Payload URL : https://packagist.org/api/github?username=<USERNAME_PACKAGIST>
Content type : application/json
Secret : <TOKEN_PACKAGIST>
Avec le bouton “Just the push event” actif, c’est suffisant pour update notre dépôt Packagist.

Une fois actif, le webhook devrait être vert, avec un entête de réponse 20X, dans le cas contraire, vérifiez vos paramètres et réessayez en cliquant sur “Redeliver”.

Composer

Enfin, parlons du gestionnaire de dépendances, Composer ! Ici, rien de bien complexe, il suffit d’ajouter le chemin de notre dépôt packagist ainsi que la version dans la section “require” de notre Composer :

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "minimum-stability": "dev",
    "prefer-stable": true,
    "require": {
        "php": "^7.1",
        "contao/calendar-bundle": "^4.6",
        "contao/comments-bundle": "^4.6",
        "contao/faq-bundle": "^4.6",
        "contao/listing-bundle": "^4.6",
        "contao/manager-bundle": "^4.6",
        "contao/news-bundle": "^4.6",
        "contao/newsletter-bundle": "^4.6",
        "terminal42/notification_center": "^1.4",
        "webexmachina/contao-form-conditional-notifications": "^0.1.0",
        "webexmachina/contao-locations": "dev-master",
        "webexmachina/contao-portfolio": "^1.0",
        "webexmachina/contao-smartgear": "^0.1"
    },
    ...
}

Ce qui est bien avec Composer c’est que vous n’êtes absolument pas obligés de demander une version précise d’un dépôt.

Vous pouvez par exemple dire “user/depot”:”^2.3”, ce qui indiquera à Composer de mettre à jour automatiquement le dépôt local s’il existe une nouvelle version commençant par 2.3 et supérieure à la version locale.

L’instruction indique toutefois qu’il ne passera pas à une version 2.4. Cela nous permet de maîtriser les évolutions et de ne pas tout casser suite à une mise à jour imprévue.

A noter que vous pouvez aussi linker directement un dépôt Github, à condition que celui-ci soit public ou tout du moins accessible via un token s’il est privé. C’est pratique quand on fait du développement, ou que l’on travaille sur un package privé pour un client.

Pour cela, il faut indiquer leurs chemins dans la section “repositories” et l’utiliser comme si c’était un dépôt Packagist.

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "config": {
        "github-oauth": {
            "github.com": "<GITHUB_TOKEN>"
        }
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/Web-Ex-Machina/contao-donations"
        },
        {
            "type": "vcs",
            "url": "https://github.com/Web-Ex-Machina/contao-locations"
        }
    ],
    "require": {
        "php": "^7.1",
        "contao/calendar-bundle": "^4.6",
        "contao/comments-bundle": "^4.6",
        "contao/faq-bundle": "^4.6",
        "contao/listing-bundle": "^4.6",
        "contao/manager-bundle": "4.6.*",
        "contao/news-bundle": "^4.6",
        "contao/newsletter-bundle": "^4.6",
        "terminal42/contao-countryselect": "^1.4",
        "webexmachina/contao-donations": "dev-master", // dev-master veut dire ici que l'on récupérera la dernière version connue de contao-donations, peu importe la version
        "webexmachina/contao-smartgear": "^0.1",
        "webexmachina/contao-locations": "^0.4"
    },
    ...
}

Tout ce système peut sembler assez procédurier et lourd, surtout quand on veut agir en urgence, et ça l’est. On peut gérer des urgences très rapidement mais ce n’est pas pour autant que cela sera propre ou durable.

Même si on corrige un bug en urgence, la procédure n’est pas longue à respecter. Ce n’est qu’une question de pratique et d’habitude.

Exemple d'un dépôt GIT bien géré

Quand on parle d’un code “propre”, il s’agit d’un travail qui sera compréhensible et réutilisable facilement par un autre développeur. Cela nécessite d’avoir au préalable assimiler la logique structurelle du système sur lequel on opère et d’agir en conséquence. Ce qui prend du temps.

Par exemple, un architecte doit comprendre les contraintes de construction d’une maison avant de vouloir modifier les plans.

Si les choses sont faites ainsi, il doit y avoir une raison et travailler sans prendre en considération l’historique d’un projet, c’est foncer dans le mur.

Gérer ses développements sous forme de packages versionnés nous force à penser à créer des structures indépendantes, à compartimenter l’ensemble des fonctionnalités d’un package, et c’est une excellente chose.

Il existe une très grande quantité de dépôts qui n’ont que pour vocation à servir d’intermédiaires entre deux technologies, et c’est grâce à ça que l’on peut gagner en productivité et réduire nos coûts de développement.

Cela prend souvent plus de temps de développer un package générique respectant la structure Github-Packagist-Composer plutôt qu’une solution sur-mesure qui sera rapide à développer. Cette dernière sera toutefois de plus en plus complexe à maintenir et à faire évoluer que plusieurs packages indépendants.