Déployer un projet interne

Commencer par déposer votre projet sur Gitlab-forge

Que vous développiez en interne ou sous-traitiez la réalisation de votre application, le source doit de toute façon être sécurisé en le déposant sur le Gitlab-Forge du Ministère. Il bénéfieciera :

  • d'une sauvegarde des sources
  • d'une historisation par commit avec retour arrière
  • d'une gestion de branche permettant la parallélisation des développements, une branche main contenant la production, la création de branche pour la résolution de bugs ou de fonctionnalités indépendantes
  • de la gestion des conflits et des fusions de branche pour éviter les régressions
  • de l'intégration continue avec qualification du code SONARQUBE, génération de la documentation technique sur des pages, tests unitaires,...
  • du déploiement continu, avec les solutions EcoCompose ou ConteneursFaciles

Organisation

Vous devez avoir plusieurs profils pour prendre en charges les différentes phases du projet, qu'il soit en V ou en mode agile, en mode projet ou mode produit :

  • spécifications, à stocker dans le Wiki du projet
  • sources, à stocker dans une ou plusieures branches du dépôt
  • recette technique, à stocker dans les tickets
  • recette métier, à stocker dans les tickets
  • documentation utilisateur, à stocker dans un projet doc à part, à créer depuis ConteneursFaciles et à éditer depuis le wiki de Gitlab

Si les sources sont réalisées par un prestataire, il existe 2 façons possibles et combinables de leur donner accès au projet créer par vos soins :

  • les agents du prestataire sont peu nombreux, ils obtiennent une adresse en i-carre.net et peuvent accéder à Gitlab-forge, il faut leur donner des droits de mainteneurs sur le projet
  • les agents du prestataire sont nombreux, il est possible d'utiliser leur outil de gestion de version interne (Gitlab, Github, Bitbucket, ...) et faire du mirror push d'une branche (la main en général) sur le gitlab-forge du ministère. Il suffit de leur donner un token projet à créer sur Gitlab-forge

Créer une pile de service sur ConteneursFaciles

Contraintes

Cette manipulation nécessite d'avoir accès au VPN.

Nécessaire qu'une seule fois, via la console de Preprod, le projet bénéficiera alors d'un token lui permettant de déployer ses images docker sur ConteneursFaciles. Ce token est unique et est propre au projet. Il est sauvegardé dans la variable CI/CD du projet Gitlab.

Plus d'information sur le cas d'usage créer la pile de service d'un projet

Déploiement de version en Preprod

Responsabilité

Cette opération ne nécessite pas d'accès VPN et peut être confié au prestataire: il s'agit d'une livraison.

Cette opération peut être déclenchée depuis Gitlab en créant un Tag ou étiquette de type `P_[0-9]+.[0-9.]* sur la branche ou commit souhaitée. L'étiquette va créer un pipeline, dont 2 jobs en particuliers :

  • la création des images dockers des services nécessaires à l'application WEB à partir de fichier Dockerfile sur le contexte du build, et leur dépot sur la registry Gitlab avec l'étiquette sans le P_.
  • le déploiement des ces images sur ConteneursFaciles selon les directives contenues dans le fichier docker-compose.yml passé en paramètre

Déploiement en production

Responsabilité

Cette opération nécessite un accès VPN et ne peut pas être confié au prestataire: il s'agit d'un changement pouvant gêner l'activité du service.

Depuis la console ConteneursFaciles de production, l'option du menu "Mes projets" doit lister les projets déployés sur la Preprod de ConteneursFaciles. Si aucun déploiement en Production n'a été fait, un formulaire demande l'exposition (RIE ou Internet) et le nom de domaine. Un fiche va être générée pour la création du reverse-proxy qui publiera vos services sur l'exposition choisit. Dès sa mise en place, vous pourrez relancer la montée de version du projet au même niveau que la Preprod.

Plus d'informations sur le cas d'usage Premier déploiement en Production


Paramètres d’affichage

Choisissez un thème pour personnaliser l’apparence du site.