BenoitAverty
commented
7 years ago Allez je me lance. Je commence par un projet tout con pour me concentrer sur la base : Une appli java Spring, un front en react. L'appli a besoin d'une base postgre pour fonctionner. Il y a un fichier docker-compose.yaml à la racine du projet qui démarre l'appli (3 conteneurs : front, back, base) et un dossier integration-tests qui contient des tests e2e avec selenium. Pas de continuous delivery.
Du coup si je pars sur l'hypothèse du yaml:
# oscip.yml
environment:
docker: '^1.13' #1.13 and above
docker-compose: '^1.11'
java: 8
maven: '^3.3'
node: 8
build:
- stage: 'build'
parallel: true
steps:
- name: front
folder: ./client
scripts:
- npm install
- npm test
- npm run build
- name: back
folder: ./server
scripts:
- gradle build
- stage: integration-tests
steps:
- name: docker-deploy
scripts:
- docker-compose up -d
- name: tests
scripts:
- npm install
- npm test
- stage: release
parallel: true
condition: manual-trigger # Déclenchement de la release à la main via l'ihm, en cliquant sur l'étape par exemple. On pourrait aussi imaginer des conditions sur le nom de branche, sur un tag, sur une PR...
steps:
- name: release-client
scripts:
- npm run release
- name: release-server
scripts:
- gradle releaseJe vous laisse imaginer le pipeline que ca pourrait donner. On 3 stages, le premier a deux étapes qui s'exécutent en parallèle, le second deux étapes séquentielles et le dernier deux étapes parallèles également.
Mon avis : c'est pas terrible. La partie "build" est trop complexe pour du yaml. C'est de l'impératif comme dit Jérémie, décrit avec un langage déclaratif. Ca peut sans doute être simplifié mais on voit déjà des limitations : le parallel: true, pas mal de verbosité parce que j'ai voulu 3 niveaux dans la modélisation du pipeline (stage, step, script). On suppose également que chaque script s'occupe lui même d'archiver ou publier ce qui doit l'être (code coverage, résultats de tests, packages...), mais ça c'est pas forcément un mal (sauf si on veut les voir direct dans l'outil !).
Une solution serait de tout faire des des scripts sur le repo, mais c'est dommage de le faire pour un cas si simple je trouve, ca disperse l'info du process de build.
Du coup j'ai décrit le même build avec un DSL groovy, fait à l'arrache sans rien vérifier donc il y a peut-être des choses invalides.
def javaEnv = [ java: '8', maven: '^3.3' ]
def nodeEnv = [ node: '8' ]
def dockerEnv = [ docker: '^1.13', 'docker-compose': '^1.11' ]
stage 'build', parallel: true {
step 'front', folder: './client', env: nodeEnv {
npm install
npm test
npm run build
}
step 'back', folder: './server', env: javaEnv {
gradle build
}
}
stage 'integration-tests', parallel: true {
// plus besoin de mettre deux steps juste pour changer de directory. Du coup, dans ce cas précis, on pourrait dire que les "steps" sont exécutées en parallèle par défaut...
withEnv dockerEnv + nodeEnv { // Addition d'environnements ! Juste pour montrer ce qu'un DSL peut permettre. Mais est-ce une bonne idée ?
docker-compose up -d
dir './integration-tests' {
npm run test
}
}
}
stage 'release', parallel: true, condition: 'manual-trigger' {
// Pas besoin d'utiliser "step" car chacune ne contiendrait qu'un seul script. On peut voir ca comme des steps "anonymes". Le parallel s'applique alors aux deux scripts, alors que plus haut il s'appliquait aux deux steps.
npm run release
gradle release
}J'ai une petite préférence pour le groovy, même si je pense que j'y ai mis plein de mauvaises idées. Et bien sûr, j'admet que c'est probablement plus difficile à appréhender au début pour des gens qui sont habitué à du travis ou circleci.
Je pense que je suis trop parti dans mon délire, non ? Qu'en pensez-vous ?
jeremiehuchet
mmouterde
Hello,
Suite au petit échange de mail, je pense qu'il est utile de définir un peu les étapes qu'il faudra valider dans un ordre pas forcément défini
Et la démarche proposée par Jérémie que je trouve intéressante : Imaginer des projets du simple au complexe, et répondre à quelques unes de ces questions dans le cadre de ces projets. On peut en discuter ci-dessous.