Gérer le code source

Pensez à l’architecture de l’outil

Les principaux outils de gestion de code source (Git, Mercurial par exemple) sont décentralisés : ils n’ont pas besoin de serveur central pour fonctionner.

Cependant, la grande majorité des développeurs utilise des solutions centralisées pour gérer leur code source : un outil tel que Github, Gitlab, Framagit ou Bitbucket offre à la fois l’accès à des dépôts Git, mais aussi à une interface web et à des outils annexes (gestion des bugs, wiki pour votre documentation, etc.)

Pour ce type d’outil offrant une interface web, il existe plusieurs architectures : il est soit obligatoire d’utiliser une solution accessible uniquement par internet, soit possible d’installer directement l’outil en interne dans vos serveurs.

Ainsi, avant de choisir une solution de gestion de code source, vous devez envisager l’utilisation que vous aurez de l’outil : par exemple, une solution accessible en ligne est plus facilement administrable, mais une solution installable sur vos serveurs pourrait être une solution plus pérenne pour votre code source.

Attention : si vous choisissez d’installer une solution dans vos serveurs, il faudra bien sûr penser à mettre en place des sauvegardes de vos dépôts de code source.

Gérez les paramètres de visibilité de vos dépôts

Si vous utilisez un outil de gestion de code source accessible librement sur internet, il vous faut paramétrer les différents dépôts dans lesquels vous allez « versionner » votre code source.

Durant la procédure de création d’un dépôt, il est souvent possible de modifier sa visibilité. Ainsi, un dépôt « public » sera visible par n’importe quel internaute, alors qu’un dépôt « privé » ne sera visible que par les membres de votre entreprise ou organisation.

Vérifiez donc que vos dépôts qui ne doivent pas être accessibles à tout le monde ont bien une visibilité « privée ».

Gérez les permissions d’accès et de commit

Il est important de bien configurer les permissions de « check out » ou « pull » (c’est-à-dire de récupération du code source) et de « commit » ou « push » (c’est-à-dire d’enregistrement d’une nouvelle version de votre code) dans vos dépôts.

Bien sûr, seules des personnes préalablement habilitées devraient pouvoir « committer » du code source dans vos dépôts.

Pour ce qui est de la récupération du code source, vous pouvez configurer votre dépôt afin de spécifier qui peut récupérer le code source. Si vous développez un projet libre ou open source, vous pouvez également laisser un accès  « checkout » totalement libre sans authentification requise, mais avec une traçabilité des connexions.

Les restrictions d’accès que vous mettez en place doivent passer par une authentification de vos développeurs et utilisateurs. Si vous choisissez d’utiliser des mots de passe, vous pouvez consulter la recommandation CNIL sur ce sujet.

Il est souvent possible d’améliorer encore la robustesse de cette authentification en utilisant des clés publiques et privées, voire des certificats.

Ne pas enregistrer de données personnelles ni de « secrets » dans votre code source

C’est une très mauvaise idée de coder en dur ou de « committer » des fichiers de configuration contenant des données personnelles ou des secrets tels que des mots de passe d’administration.

Ces données et secrets peuvent par exemple être utilisés par des personnes malveillantes pour accéder illégalement aux données de vos utilisateurs.

Dans tous les cas, pour assurer la sécurité du système lors de sa mise en production, il est très fortement recommandé de :

• Utiliser des données fictives tout au long de la phase de test et de développement ;
• Changer les secrets qui auraient pu être enregistrés.

Afin de se prémunir contre un « commit » malchanceux, vous pouvez ajouter un « hook » dans votre outil de code source. Lors de chaque commit, le « hook » exécutera un script qui utilisera des expressions régulières pour vérifier que des secrets ou données personnelles ne sont pas « committés » par erreur.

Utiliser les fonctionnalités conçues pour faciliter le développement

L’utilisation de branches, qui est une fonctionnalité permettant de faire évoluer plusieurs versions du code source en  parallèle, est une bonne pratique permettant de séparer vos développements.

Vous pouvez ainsi utiliser des branches différentes pour séparer le code correctement sécurisé, destiné à être mis en production, du code en cours de développement.