Design and deployment of software factory CI/CD tools and delivery chain environments

[olivierlemee]

scope of tools defined by https://github.com/cybnity/foundation/tree/main/docs

• open source repository and tools dockerised infrastructure deployable/reusable by the community

• [x] Add Terraform tool into the documentation

• [x] Ajouter le Terraform comme outil de création d’infrastructure cible (architecture isolée constituant le cluster kubernetes) qui permet de construire des helm manifest utilisable pour instanciation dans kubernetes. Au lieu de manager des valeurs de services dans helm, terraform aide à designer et valoriser une infra cible (comme l’archi d’environnement de production, une infra de test…) déployable comme un cluster kubernetes sur un cloud.

[olivierlemee]

• [x] créer le système de branches dans github respectant la stratégie (staging, intégration), et normaliser le nommage (complément de doc dans la stratégie) des noms de branches de features

• [x] ouvrir un repo pour artefacts de projets open source (+ compte api key en secrets côté github)

• [x] sur la branche staging, implémenter le stage commit en charge de détecter les commits de révision sur branche, tester la compilation et packaging (fin d'étape maven maxi sans publication) des projets pom (pour le parent) et les sous-projets java (conformité correspondant aux étapes sous maven et inclus dans le stage commit) = renommer le workflow comme "ci commit stage" qui se joue sur détection des modifs de pom ou ressources autres que les sous-projets java = sync et montée en staging des docs, pom etc... .hors composants java

  • [x] deploy en repo du pom parent seul + auto-versioning selon la révision git en cours
  • [x] builds indépendants des sous projets de composants java pour la révision git en cours
  • [x] finir le publish_snapshot_version_to_remote_repository pour déployer en remote uniquement si a fait l'objet d'une revue en succès merged
  • [x] support du tag reviewed ou alpha (saisie manuelle par developer/reviewer sous git) pour publish en remote repo snapshot (ok pour les version de dev tagguées)
  • [x] modifier la préparation du nom de version pour qu'en cas de tag (et non de release tag) existant, cela créé non pas un snapshot mais une version release dans le commitid (actuellement en 0-0-6-alpha.4d59d0ad-SNAPSHOT alors que devrait être 0-0-6-feature133-alpha)

• [x] initier la structure et le processus/workflow Technical Quality Stage de CI exécutant la chaîne de contrôle qualité statique

[olivierlemee]

• le workflow java-project-quality-check.yml fonctionne avec délégation vers le workflow de publish vers repo cybnity
• ce workflow de "unit testing & quality verification" se réalise sur détection de push ou pull_request sur multiples branches
• La détection du push a été testée avec filtrage du path (pom.xml ou sous-répertoires de projets java)
• RESTE À TESTER:
  • [x] vérifier le lancement uniquement sur les changements en pom ou projet java activant le scénario: provoquer un échec dans le pom parent (normalement doit stopper le build et ne pas déclencher la délégation de deploy contraint par la condition success() dans le workflow "unit testing..."
  • [x] tester un pull request sur staging pour voir si le workflow se réalise sur staging également
  • [x] enlever l'appel automatique au deploy puisque sera utilisé par un autre sous-workflow détectant un retour valide de pullrequest acceptée qui dans ce cas déclenchera une actualisation du remote repo
  • [x] gérer le problème de changement de version du pom lors de la promotion en repo pour éviter des départs de snapshot mais plutôt baser ces version alpha sur un nom de version intégrant le sha du commit de révision

[olivierlemee]

RESTE À FAIRE

• [ ] compléter "check-java-project-technical-quality.yml" : implémenter des plugins maven et règles de contrôles qualité statiques sur source codes

  • [ ] règles conformité des exigences d'architecture
  • [ ] règles de conformité des exigences de sécurité
  • [ ] plan d'assurance qualité avec génération de rapport
    • [ ] Docker image templates (link job checks the dockerfile syntax)
    • [ ] Build docker image
    • [ ] Test against the image to ensure it contains the expected components
    • [ ] security scans about known vulnerabilities...

• [ ] enrichir le workflow "software-project-aat.yml" entrant sur staging si pull_request demandée

  • [x] entrée par défaut lors de pull_request merged
  • [ ] pour qu'en situation de contrôle qualité sur la branche staging, ce soit forcément une version release (détection sur tag existant alpha* qui soit publiée vers le repo maven comme tag alpha précédemment déjà existant car déjà approuvé par reviewer, avec contrôle qualité ok) et jamais une version en snapshot; et que ce soit par défaut sans paramètre release si autres branche... ce workflow porte l'exécution du AAT stage qui finit par un upload repo en "release" si tout validé conforme
  • [ ] détecter les sources taggée alpha pour lancement du contrôle qualité dans un flux permettant de déterminer si éligible à devenir beta (tagging en sources) et publication des artefacts en repo d'artefacts taggé release
  • [ ] création du workflow interne à "aat stage" nommé "integration quality stage" pilotant la préparation d'env QA et l'exécution de la campagne de contrôle qualité automatisée en collaboration avec spinnaker ou les envt github" jusqu'à la fin en succès avec tagging des sources comme beta en staging ou échec pour rejet de pull_request (avant approbation de revue du reviewer demandé)

• [ ] créer workflow "cd betarelease" qui détecte les codes sources taggées beta (saisie manuelle sous git par project leader) et les transforme de branche intégration jusqu'à branche master comme "valide merge" de codes source (considérées comme déployé en production car les projets open source en repo ne font par l'objet d'un deploy en infra, mais deviennent "head de production" une fois délivrée en repo d'artefacts sous nouvelle version". La CD de projet open source considère qu'une livraison valide en beta sous repo d'artefacts est une mise en production publique

[olivierlemee]

release notes and changes added into implementation projects (via .md files)