Suppression des jobs de déploiement

.gitlab-ci.yml

@@ -19,7 +19,6 @@ stages:
   - analysis
   - package
   - publish
-  - deploy
 
 # Définition des variables
 variables:
@@ -223,36 +222,6 @@ publish-container:
     - if: $CI_COMMIT_TAG != null
     - if: $CI_PIPELINE_SOURCE == "merge_request_event"   
 
-#======================================
-# Déploiement
-#======================================
-deploy-services:
-  image: docker.io/bitnami/kubectl
-  stage: deploy
-  script:
-    - kubectl apply -f deploy/service.yaml
-  rules:
-    # Lancement de l'étape lors de la création d'un tag ET quand le fichier services.yaml a été modifié
-    - if: $CI_COMMIT_TAG == null
-      when: never
-    - changes:
-        - deploy/service.yaml
-  # On souhaite utiliser la configuration du runner-externe pour déployer
-  tags:
-    - runner-externe
-
-deploy-app:
-  image: docker.io/bitnami/kubectl
-  stage: deploy
-  script:
-    - sed -i 's%<IMAGE_PATH>:<VERSION>%'${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}'%g' deploy/deployment.yaml
-    - kubectl apply -f deploy/deployment.yaml
-  rules:
-    # Lancement de l'étape lors de la création d'un tag, d'une merge request ou d'un pipeline programmé
-    - if: $CI_COMMIT_TAG != null
-  # On souhaite utiliser la configuration du runner-externe pour déployer
-  tags:
-    - runner-externe
 # Fin
 #======================================
 

README.md

@@ -29,7 +29,6 @@ La stratégie de développement, d'intégration et de déploiement choisie sur c
 - Dès qu'on a un ensemble fonctionnel cohérent :
   - Envoi des livrables sur les dépôts de gitlab (jar, image Docker)
   - Génération de rapport sur la sécurité et l'obsolescence des composants
-  - Déploiement automatique sur un hébergement externe
  
 ## Git flow (stratégie d'utilisation de git)
 
@@ -94,17 +93,6 @@ Le schéma ci-dessous illustre le fonctionnement de la publication.
 
 ![alt text](docs/img/publish-workflow.png "Workflow de publication")
 
-### Déploiement de l'application
-
-Suite à la création du tag, l'application est automatiquement déployée. Dans l'exemple présent, il n'existe qu'un environnement sur lequel l'application est déployée automatiquement.
-En pratique, le déploiement peut se faire sur des environnements différents, à des fréquences différentes, avec des déclencheurs différents.
-
-L'environnement sur lequel est déployé une application, n'est pas lié à Gitlab : on peut citer l'hébergement sec, eco ou le C3 comme des cibles potentielles.
-
-Le schéma ci-dessous illustre un exemple de flux de déploiement.
-
-![alt text](docs/img/deploy-workflow.png "Workflow de déploiement")
-
 ## Chaîne d'intégration continue
 
 La chaîne d'intégration du projet est divisée en plusieurs phases (`stages`), dans lesquelles sont executées différentes tâches (`jobs`) :
@@ -125,8 +113,5 @@ La chaîne d'intégration du projet est divisée en plusieurs phases (`stages`),
 |         |pages                  |envoi des rapports sur gitlab pages                                                       |
 |         |publish-artefact       |envoi de l'artefact sur un dépôt d'archive                                                |
 |         |publish-docker-image   |création et publication d'une image docker permettant d'éxecuter le projet                |
-|deploy   |                       |                                                                                          |
-|         |deploy-services        |déploiement du service (spécifique Kubernetes)                                            |
-|         |deploy-app             |déploiement de l'application                                                              |
 
 ~ Fin ~