Si le langage le permet, il est \u00e9galement possible (et souhaitable) d’ex\u00e9cuter:<\/p>\n
- \n
- Un \u00ab\u00a0linter\u00a0\u00bb afin de valider le standard du projet;<\/li>\n
- Les syst\u00e8mes de m\u00e9triques permettant de valider le projet.<\/li>\n<\/ul>\n
Il est bien entendu possible d’en faire plus.<\/p>\n
Les logiciels d’int\u00e9gration continue<\/h2>\n
Voici une liste de service libre d’int\u00e9gration continue non exhaustive pouvant \u00eatre utilis\u00e9e dans un projet de logiciel libre.<\/p>\n
- \n
- Gitlab CI\/CD<\/li>\n
- Github Action<\/li>\n
- Jenkins<\/li>\n
- Travis CI<\/li>\n
- Azure Pipelines<\/li>\n<\/ul>\n
La proc\u00e9dure de configuration d’un logiciel d’int\u00e9gration continue<\/h2>\n
Il est important de comprendre que chaque logiciel d’int\u00e9gration continue a une proc\u00e9dure de configuration diff\u00e9rente et il est impossible de toutes les montrer ici.<\/p>\n
Par contre, ces proc\u00e9dures sont tout de m\u00eame relativement semblables. Nous allons donc utiliser le logiciel Gitlab CI\/CD pour cette pr\u00e9sentation.<\/p>\n
Afin d’utiliser Gitlab CI\/CD, il est n\u00e9cessaire d’avoir un d\u00e9p\u00f4t (ou un clone du d\u00e9p\u00f4t) du projet sur Gitlab.<\/p>\n
Cr\u00e9er le fichier de configuration<\/h3>\n
Gitlab CI\/CD utilise des fichiers Yaml afin de configurer le \u00ab\u00a0pipeline\u00a0\u00bb d’int\u00e9gration continue. Afin de cr\u00e9er un nouveau fichier de configuration Yaml, il suffit de se rendre dans la section \u00ab\u00a0CI\/CD\u00a0\u00bb dans le d\u00e9p\u00f4t Gitlab.<\/p>\n
![\"Gitlab](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2022\/02\/gitlab_ci_open.png\")
<\/p>\nEnsuite, pour g\u00e9n\u00e9rer initialement le script, vous pouvez soit utiliser un script mod\u00e8le (\u00ab\u00a0template\u00a0\u00bb) fourni par Gitlab, ou bien utiliser le bouton \u00ab\u00a0use template\u00a0\u00bb pour avoir un mod\u00e8le de base.<\/p>\n
![\"Templates](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2022\/02\/gitlab_ci_specific_template.png\")
<\/p>\n![\"Template](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2022\/02\/gitlab_ci_generic_template.png\")
<\/p>\nIl est \u00e9galement possible de cr\u00e9er manuellement le fichier Yaml \u00e0 la racine du projet. Le fichier doit s’appeler exactement \u00ab\u00a0.gitlab-ci.yml\u00a0\u00bb (ne pas oublier le \u00ab\u00a0.\u00a0\u00bb).<\/p>\n
Les configurations de bases<\/h3>\n
En fonction du type de langage \u00e0 utiliser, on utilise des configurations diff\u00e9rentes (avec ou sans compilation, linter, etc.) Nous ne les montrerons pas toutes ici. Nous n’allons que montrer la base. La documentation compl\u00e8te est accessible (en anglais seulement) ici<\/a>. Donc, la premi\u00e8re section du script est la section \u00ab\u00a0stages\u00a0\u00bb indiquant les diff\u00e9rentes \u00e9tapes \u00e0 utiliser. Par exemple, la section \u00ab\u00a0stage\u00a0\u00bb suivante a trois (3) \u00e9tapes: la compilation, les tests) et le d\u00e9ploiement:<\/p>\n
\nstages<\/span>:<\/span>\r\n -<\/span> compilation<\/span>\r\n -<\/span> test<\/span>\r\n -<\/span> deploiement<\/span>\r\n<\/pre>\n<\/div>\nEnsuite, nous pouvons cr\u00e9er autant de sections que nous souhaitons, mais pour que ces sections soient ex\u00e9cut\u00e9es, nous devons sp\u00e9cifier dans quel \u00ab\u00a0stage\u00a0\u00bb ils doivent \u00eatre utilis\u00e9s. Par exemple:<\/p>\n
\nstages<\/span>:<\/span>\r\n -<\/span> compilation<\/span>\r\n -<\/span> test<\/span>\r\n -<\/span> deploiement<\/span>\r\n\r\ncompilation-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> compilation<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Compilation<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Compilation termin\u00e9<\/span>\r\n\r\nunit-test-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> test<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Ex\u00e9cution des tests<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin des tests<\/span>\r\n\r\nlint-test-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> test<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Ex\u00e9cution du Linter<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin d'ex\u00e9cution du Linter<\/span>\r\n\r\ndeploiement-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> deploiement<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo D\u00e9ploiement<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin du d\u00e9ploiement<\/span>\r\n<\/pre>\n<\/div>\nIl est \u00e0 noter que les \u00ab\u00a0…\u00a0\u00bb dans les sections \u00ab\u00a0script\u00a0\u00bb repr\u00e9sentent les lignes de commande \u00e0 ex\u00e9cuter pour effectuer les \u00e9tapes correspondantes.<\/p>\n
Parfois, il est n\u00e9cessaire de garder certaines informations entre les \u00ab\u00a0stages\u00a0\u00bb (par exemple, des fichiers compil\u00e9s). Pour se faire, on utilise des \u00ab\u00a0artifacts\u00a0\u00bb. De plus, pour s’assurer que le \u00ab\u00a0Gitlab Runner\u00a0\u00bb ex\u00e9cute les \u00ab\u00a0stages\u00a0\u00bb dans le bon ordre, on peut utiliser des \u00ab\u00a0dependencies\u00a0\u00bb. Voici un exemple:<\/p>\n
\nstages<\/span>:<\/span>\r\n -<\/span> compilation<\/span>\r\n -<\/span> test<\/span>\r\n -<\/span> deploiement<\/span>\r\n\r\ncompilation-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> compilation<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Compilation<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Compilation termin\u00e9<\/span>\r\n artifacts<\/span>:<\/span>\r\n paths<\/span>:<\/span>\r\n -<\/span> build<\/span>\r\n\r\nunit-test-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> test<\/span>\r\n dependencies<\/span>:<\/span>\r\n -<\/span> compilation-job<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Ex\u00e9cution des tests<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin des tests<\/span>\r\n\r\nlint-test-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> test<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo Ex\u00e9cution du Linter<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin d'ex\u00e9cution du Linter<\/span>\r\n\r\ndeploiement-job<\/span>:<\/span>\r\n stage<\/span>:<\/span> deploiement<\/span>\r\n dependencies<\/span>:<\/span>\r\n -<\/span> compilation-job<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo D\u00e9ploiement<\/span>\r\n -<\/span> ...<\/span>\r\n -<\/span> echo Fin du d\u00e9ploiement<\/span>\r\n<\/pre>\n<\/div>\nUtilisation de docker<\/h3>\n
L’ex\u00e9cution de la configuration du Gitlab CI\/CD de base peut \u00eatre suffisant pour des t\u00e2ches simples ne n\u00e9cessitant pas de logiciel (compilateur, interpr\u00e9teur, etc.) ou librairie particuli\u00e8re. Par contre, si un syst\u00e8me plus pr\u00e9cis est n\u00e9cessaire, il est possible d’ex\u00e9cuter les scripts dans des \u00ab\u00a0dockers\u00a0\u00bb. Tous les \u00ab\u00a0dockers\u00a0\u00bb accessibles gratuitement sur le site de DockerHub<\/a> peuvent \u00eatre utilis\u00e9s. \u00c9galement, il est possible de fournir l’image docker directement dans le d\u00e9p\u00f4t ou bien utiliser un lien afin de t\u00e9l\u00e9charger l’image. Pour utiliser un \u00ab\u00a0docker\u00a0\u00bb, il faut utiliser une information \u00ab\u00a0image\u00a0\u00bb.<\/p>\n
Il est \u00e0 noter qu’une nouvelle image de \u00ab\u00a0docker\u00a0\u00bb sera g\u00e9n\u00e9r\u00e9e \u00e0 chaque \u00ab\u00a0stage\u00a0\u00bb du \u00ab\u00a0pipeline\u00a0\u00bb. Il est donc n\u00e9cessaire de configurer \u00e0 nouveau le \u00ab\u00a0docker\u00a0\u00bb.<\/p>\n
Voici un exemple:<\/p>\n
\nstages<\/span>:<\/span>\r\n -<\/span> compilation<\/span>\r\n -<\/span> test<\/span>\r\n\r\ncompilation-job<\/span>:<\/span>\r\n image<\/span>:<\/span> debian:latest<\/span>\r\n stage<\/span>:<\/span> compilation<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo \"Pr\u00e9paration de l'image...\"<\/span>\r\n -<\/span> apt-get update<\/span>\r\n -<\/span> apt-get install -y build-essential<\/span>\r\n -<\/span> apt-get clean<\/span>\r\n -<\/span> rm -rf \/var\/lib\/apt\/lists\/*<\/span>\r\n -<\/span> echo \"Pr\u00e9paration termin\u00e9.\"<\/span>\r\n -<\/span> echo \"Compilation de la librairie...\"<\/span>\r\n -<\/span> make clean<\/span>\r\n -<\/span> make all<\/span>\r\n -<\/span> echo \"Compilation termin\u00e9e\"<\/span>\r\n artifacts<\/span>:<\/span>\r\n paths<\/span>:<\/span>\r\n -<\/span> bin<\/span>\r\n\r\ntest-job<\/span>:<\/span>\r\n image<\/span>:<\/span> debian:latest<\/span>\r\n stage<\/span>:<\/span> test<\/span>\r\n dependencies<\/span>:<\/span>\r\n -<\/span> compilation-job<\/span>\r\n script<\/span>:<\/span>\r\n -<\/span> echo \"Pr\u00e9paration de l'image...\"<\/span>\r\n -<\/span> apt-get update<\/span>\r\n -<\/span> apt-get install -y build-essential<\/span>\r\n -<\/span> apt-get clean<\/span>\r\n -<\/span> rm -rf \/var\/lib\/apt\/lists\/*<\/span>\r\n -<\/span> echo \"Pr\u00e9paration termin\u00e9.\"<\/span>\r\n -<\/span> echo \"Compilation des tests...\"<\/span>\r\n -<\/span> cd test<\/span>\r\n -<\/span> make clean<\/span>\r\n -<\/span> make all<\/span>\r\n -<\/span> echo \"Ex\u00e9cution des tests...\"<\/span>\r\n -<\/span> bin\/Release\/test<\/span>\r\n -<\/span> echo \"Fin des tests.\"<\/span>\r\n<\/pre>\n<\/div>\nSi la m\u00eame image est utilis\u00e9e pour tous les \u00ab\u00a0stage\u00a0\u00bb, on peut sp\u00e9cifier l’image une seule fois. De plus, afin de ne pas dupliquer inutilement la pr\u00e9paration du docker, on peut utiliser l’information \u00ab\u00a0extends\u00a0\u00bb et mettre les instructions dans un \u00ab\u00a0before_script\u00a0\u00bb commun.<\/p>\n
Voici un exemple:<\/p>\n
\nimage<\/span>:<\/span> debian:latest<\/span>\r\n\r\nstages<\/span>:<\/span>\r\n -<\/span> compilation<\/span>\r\n -<\/span> test<\/span>\r\n\r\n.prepare-image<\/span>