Si vous êtes un client fidèle vous avez dû remarquer qu'à chaque communication concernant un changement (bugfix, amélioration, ...) nous indiquons le numéro de version, n'est-ce pas ? Hé bien ce n'est pas un hasard !
En effet, cela vient de notre approche CI/CD (pour intégration continue et déploiement continu), méthode de travail dîtes "Agile" que nous utilisons. Cette méthode, par sa simplicité et sa complétude, implique la mise en place d'un certain nombre de bonnes pratiques.
L’un des prérequis à l’intégration continue est que le gestionnaire des sources soit unique et versionné. Pour ce faire nous utilisons un logiciel très connu de gestion de versions. J'ai nommé : Git.
Tenir à jour son "Changelog" et donc les changements entre chaque version permet de tracer toute modification et donc d'éviter un maximum qu'une version ne génère des erreurs, régressions ou anomalies. A défaut d'éviter toute erreur, cela permettra de remonter facilement sur les changements et donc la version ayant eu un impact sur le bout de code en cause.
Il faut donc indiquer tout ce qui est intégré dans la version qui sera mise en production. N'oubliez pas que trop de changements peuvent également "noyer" l'information importante en cas d'analyse d'une root cause. Un principe du CI/DC est donc d'intégrer régulièrement les modifications quitte à multiplier les versions.
Livrer régulièrement vous permettra également de faciliter les tests car les changements, sauf pour une version majeure, seront limités. Les tests peuvent donc être ciblés plus facilement. De même, vous identifierez facilement le lien entre un bug et la version ainsi que le risque de conflits dans le code. En effet, celui-ci sera diminué et surtout il sera décelé plus rapidement car les commits ne seront pas beaucoup espacés.
Une fois que vous avez compris cela, il devient donc important de bien gérer son "Versioning". Chez nous, nous utilisons un principe simple de numérotation selon l'apport de la version. En effet, si celle-ci est majeure, mineure ou simplement là pour fixer une erreur, sa numérotation sera différente.
Tracer vos changements grâce à un outil centralisé tel que Git vous permettra, notamment si l'équipe en charge est conséquente, de faciliter la gestion de votre produit et son cycle de vie.
En utilisant à minima deux environnements (Test & Prod), vos équipes (Testeurs, développeurs, ..) pourront facilement faire avancer leurs changements d'une branche à l'autre jusqu'à validation complète et mise en production.
Votre environnement de test devra bien entendu être proche de la production. En effet, effectuer une modification dans les conditions “réelles” de l’environnement final permettra d'être plus serein quand les modifications seront livrées en production. Un grand nombre de mauvaises surprises seront évitées.
Git vous permet d'ailleurs facilement de gérer plusieurs "branches" parallèles (Qualif, test, pré-prod, prod, ..) et d'effectuer des actions sur celles-ci tels que d'appliquer des changements d'une branche à une autre.
